Practical and Secure Trust Anchor Management and Usage

1. Practical and Secure Trust Anchor Management and Usage Symposium on Identity and Trust on the Internet April 15, 2010

2. Scenario #1 • DOD is cross-certified with the Federal Bridge CA (FBCA) via the Interoperability Root CA (IRCA) • Enables optional recognition of the FBCA community, i.e., those who install the IRCA as a trust anchor (TA) can interoperate with the FBCA • In some cases, entities who do not use the IRCA need to communicate with enterprises who are cross-certified with the FBCA • For example, Department of State (DOS) • How can interoperability be enabled without using the IRCA? • Installing the DOS trust anchor results in similar (and worse) level of exposure to the FBCA community that installing the IRCA does

3. * Diagram courtesy Booz Allen Hamilton

4. Scenario #2 • Operating systems and applications are pre-loaded with a variety of default TAs • Trust graph is unknown (or at least unpublished) • Limited options for users or administrators to add constraints • How can an enterprise ensure CAs validated using a default TA are not issuing certificates that assert names or policies managed by the enterprise?

5. ? ? ? ? ? ? ? ? ? …amongst others ?

6. ? ? ? ?

7. Common problem • The challenge in both scenarios stems from an inability to constrain TAs in useful ways

8. Establishing Trust Relationships Between Enterprises Using a PKI • Direct bi-lateral cross-certification • Mechanics: Enterprise A’s root CA issues a certificate to Enterprise B’s root CA and vice versa • Constraints: Each certificate includes desired name constraints, policy constraints, path length constraint, policy mapping, etc. • Scope: enterprise-wide • Indirect bi-lateral cross-certification (i.e., Bridge CA) • Mechanics : Both Enterprise A and B root CAs issue certificates to a Bridge CA and vice versa • Constraints: Each certificate includes desired name constraints, policy constraints, path length constraint, policy mapping, etc. • Scope: enterprise-wide • Direct trust/implicit unilateral cross-certification • Mechanics : Enterprise A installs Enterprise B’s root certificate as a trust anchor and vice versa • Constraints: Unconstrained or limited by the extended key usage-like constraints options supported by the trust anchor store • Scope: local

9. Current TA constraint mechanisms

10. Emerging standards • Several specifications are progressing through the IETF to address trust anchor management and trust anchor usage issues • Trust Anchor Format (TAF) • http://tools.ietf.org/html/draft-ietf-pkix-ta-format-04 • Trust Anchor Management Protocol (TAMP) • http://tools.ietf.org/html/draft-ietf-pkix-tamp-07 • CMS Content Constraints (CCC) • http://tools.ietf.org/html/draft-housley-cms-content-constraints-extn-04 • Using Trust Anchor Constraints During Certification Path Processing (UTAC) • http://tools.ietf.org/html/draft-wallace-using-ta-constraints-02.html • Requirements for the specifications listed above are defined in an informational draft • Trust Anchor Management Requirements • http://tools.ietf.org/html/draft-ietf-pkix-ta-mgmt-reqs-05

11. Trust Anchor Format • Self-signed certificates are de facto standard for representing trust anchors • Security requires out-of-band establishment of trust • Format does not lend itself to association of constraints by relying parties • TAF defines three formats for representing a trust anchor • Certificate • Self-signed or otherwise • TBSCertificate • i.e., a Certificate structure without signature • TrustAnchorInfo • Can be as small as name and key (or name and key plus constraints) • Can wrap a certificate to add constraints

12. Trust Anchor Management Protocol • Primary aim is to reduce need for out-of-band trust decisions • Enables trust anchor stores to be initialized once (in a secure environment) and managed thereafter using TAMP • Provides support for disaster recovery • Via Apex TA with a contingency key • Management operations are subject to strict subordination rules

13. TAMP Message Types • Eleven TAMP message types • Content types, in CMS parlance • Five pairs of request/response messages plus TAMPError

14. CMS Content Constraints • Certificate or trust anchor extension that describes the types of content that can be validated using a given public key • Content is described in terms of CMS content types and CMS attributes • Can be used as an authorization mechanism with TAMP

15. Using Trust Anchor Constraints During Certification Path Processing • Describes how to use constraints expressed in a trust anchor during certification path processing • Essentially describes how to combine values from trust anchor extensions with standard user-supplied path validation inputs • Processing can be • Incorporated into an RFC 5280 compliant implementation • Implemented as pre-processing of RFC 5280 inputs and post-processing of RFC 5280 outputs

16. Using emerging standards to address Scenarios #1 and #2 • Wrap each desired self-signed root certificate in a TrustAnchorInfo structure and associate necessary constraints, i.e., permitted namespaces, excluded namespaces, policies, etc. • Uses TAF • Install new trust anchor definitions in TA store • Uses TAMP and CCC • Enforce the constraints contained in the TA during certification path processing • Uses UTAC

17. * Diagram courtesy Booz Allen Hamilton

18. CAPI Trust Anchor Guard (CAPI TAG) • Enables applications that using Microsoft CAPI for certification path processing to use trust anchor constraints • Uses secondary trust anchor store that provides constraints for trust anchors stored in native CAPI root store • Managed via CAPI TAG tools using TAMP/CCC

19. Integration with Microsoft CAPI • Several avenues were explored while searching for a means of providing support for trust anchor constraints to applications enabled using Microsoft CAPI • These efforts are described in IDTrust paper • Revocation status provider and validation policy provider interfaces were explored but not used • The certificate store API was selected for use • Serves as a point of entry for intercepting calls to the native certification path processing function • Enables support for trust anchor constraints, delegated certification path processing (SCVP), etc.

20. CAPI TAG components • CAPI TAG StoreCreator • Used to initialize a CAPI TAG trust anchor store • Store Manager • Manages local CAPI TAG trust anchor stores via local file access or HTTP • Manages remote CAPI TAG trust anchor stores via HTTP • Manages remote CAPI TAG trust anchor stores via a file containing a TAMPStatusResponse message • mod_tam • Routes TAMP messages received via a particular URI to a TA store file for processing • Periodically checks specified URIs for TAMP messages, which are downloaded and presented to a TA store file for processing • Process TAMP Message • Enables a file containing a TAMP messages to be presented to a CAPI TAG trust anchor store (via HTTP or local file access) for processing

21. CAPI TAG components • CAPI TAG • Integrates with Microsoft Windows to provide trust anchor constraints enforcement (or alternative certification path processing, e.g., SCVP) • CAPI TAG Configuration Utility • Primary means for configuring CAPI TAG for use • CAPI TAG Customization Wizard • Deployment utility used to create MST files • PKIFTAM • C++ library that provides support for TAF, TAM and CCC • UTAC support is available in base PKIF library

22. Management models • Local management • File-based • Online remote management • TAMP over HTTP • Remote pull • TAMP messages via HTTP, RSS, LDAP, FTP, etc. • Indirect remote management • TAMP over sneaker-net, email, etc. • Additional possibilities • Status quo w/ RFC 5280 inputs and/or TA constraints in certificates • Delegation via SCVP • Potential models • Interactive pull (submit response, receive update) • Remote pull (per SIA or AIA)

23. Process flow abstraction

24. Process flow abstraction

25. Process flow abstraction

26. Functional Roles • Trust anchor store manager • Controls private key corresponding to trust anchor or certificate with CCC extension authorizing generation of all TAMP request messages • TAMPUpdate, TAMPCommunityUpdate, SequenceNumberAdjust and TAMPStatusQuery messages • Trust anchor store viewer • Controls private key corresponding to trust anchor or certificate with CCC extension authorizing generation of TAMPStatusQuery messages • Trust anchor store user • Is not authorized to generate any TAMP messages but may use a CAPI TAG trust anchor store • May present a TAMP message from an authorized source to a CAPI TAG trust anchor store for processing • System administrator • Authorized to edit system registry and filesystem (i.e., to install or configure CAPI TAG)

27. Demonstration