Trust Anchor Management Requirements
draft-ietf-pkix-ta-mgmt-reqs-06

Abstract

A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor. This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and push-based protocols designed to address these problems.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on February 26, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents

1.  Introduction
    1.1.  Terminology
    1.2.  Requirements Notation
2.  Problem Statement
3.  Requirements
    3.1.  Transport independence
        3.1.1.  Functional Requirements
        3.1.2.  Rationale
    3.2.  Basic management operations
        3.2.1.  Functional Requirements
        3.2.2.  Rationale
    3.3.  Management targets
        3.3.1.  Functional Requirements
        3.3.2.  Rationale
    3.4.  Delegation of TA Manager Authority
        3.4.1.  Functional Requirements
        3.4.2.  Rationale
    3.5.  RFC 5280 Support
        3.5.1.  Functional Requirements
        3.5.2.  Rationale
    3.6.  Support Purposes Other Than Certification Path Validation
        3.6.1.  Functional Requirements
        3.6.2.  Rationale
    3.7.  Trust Anchor Format
        3.7.1.  Functional Requirements
        3.7.2.  Rationale
    3.8.  Source Authentication
        3.8.1.  Functional Requirements
        3.8.2.  Rationale
    3.9.  Reduce Reliance on Out-of-Band Trust Mechanisms
        3.9.1.  Functional Requirements
        3.9.2.  Rationale
    3.10.  Replay Detection
        3.10.1.  Functional Requirements
        3.10.2.  Rationale
    3.11.  Compromise or Disaster Recovery
        3.11.1.  Functional Requirements
        3.11.2.  Rationale
4.  Security Considerations
5.  IANA Considerations
6.  References
    6.1.  Normative References
    6.2.  Informative References
§  Authors' Addresses

1.  Introduction

Digital signatures are used in many applications. For digital signatures to provide integrity and authentication, the public key used to verify the digital signature must be "trusted", i.e., accepted by a relying party (RP) as appropriate for use in the given context. A public key used to verify a signature must be configured as a trust anchor (TA) or contained in a certificate that can be transitively verified by a certification path terminating at a trust anchor. A Trust Anchor is a public key and associated data used by a relying party to validate a signature on a signed object where the object is either:

• a public key certificate that begins a certification path terminated by a signature certificate or encryption certificate
• an object, other than a public key certificate or certificate revocation list (CRL), that cannot be validated via use of a certification path

Trust anchors have only local significance, i.e., each RP is configured with a set of trust anchors, either by the RP or by an entity that manages TAs in the context in which the RP operates. The associated data defines the scope of a trust anchor by imposing constraints on the signatures the trust anchor may be used to verify. For example, if a trust anchor is used to verify signatures on X.509 certificates, these constraints may include a combination of name spaces, certificate policies, or application/usage types.

One use of digital signatures is the verification of signatures on firmware packages loaded into hardware modules, such as cryptographic modules, cable boxes, routers, etc. Since such devices are often managed remotely, the devices must be able to authenticate the source of management interactions and can use trust anchors to perform this authentication. However, trust anchors require management as well. Other applications requiring trust anchor management include web browsers, which use trust anchors when authenticating web servers, and email clients, which use trust anchors when validating signed email and when authenticating recipients of encrypted email.

All applications that rely upon digital signatures rely upon some means of managing one or more sets of trust anchors. Each set of trust anchors is referred to in this document as a trust anchor store. Often, the means of managing trust anchor stores are application-specific and rely upon out-of-band means to establish and maintain trustworthiness. An application may use multiple trust anchor stores and a given trust anchor store may be used by multiple applications. Each trust anchor store is managed by at least one TA manager; a TA manager may manage multiple TA stores.

The requirements stated in this document were prepared prior to the publication of [RFC5914] (Housley, R., Ashmore, S., and C. Wallace, “Trust Anchor Format,” June 2010.) and [RFC5934] (Housley, R., Ashmore, S., and C. Wallace, “Trust Anchor Management Protocol (TAMP),” August 2010.). The document was not published at that time to allow for changes in requirements during the development of the associated technical specifications. The requirements described below are those that were considered during the development of [RFC5914] (Housley, R., Ashmore, S., and C. Wallace, “Trust Anchor Format,” June 2010.) and [RFC5934] (Housley, R., Ashmore, S., and C. Wallace, “Trust Anchor Management Protocol (TAMP),” August 2010.).

This section provides an introduction and defines basic terminology. Section 2 describes problems with current trust anchor management methods. Sections 3 and 4 describe requirements and security considerations for a trust anchor management solution.

1.1.  Terminology

The following terms are defined in order to provide a vocabulary for describing requirements for trust anchor management.

Trust Anchor:

A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor.

Trust Anchor Manager:

Trust anchor manager is an entity responsible for managing the contents of a trust anchor store. Throughout this document, each trust anchor manager is assumed to be represented as or delegated by a distinct trust anchor.

Trust Anchor Store:

A trust anchor store is a set of one or more trust anchors stored in a device. A trust anchor store may be managed by one or more trust anchor managers. A device may have more than one trust anchor store, each of which may be used by one or more applications.

1.2.  Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Problem Statement

Trust anchors are used to support many application scenarios. Most Internet browsers and email clients use trust anchors when authenticating TLS sessions, verifying signed email and generating encrypted email by validating a certification path to a server's certificate, an e-mail originator's certificate or an e-mail recipient's certificate, respectively. Many software distributions are digitally signed to enable authentication of the software source prior to installation. Trust anchors that support these applications are typically installed as part of the operating system (OS) or application, installed using an enterprise configuration management system, or installed directly by an OS or application user.

Trust anchors are typically stored in application-specific or operating system-specific trust anchor stores. Often, a single machine may have a number of different trust anchor stores that may not be synchronized. Reviewing the contents of a particular trust anchor store typically involves use of a proprietary tool that interacts with a particular type of trust store.

The presence of a trust anchor in a particular store often conveys implicit authorization to validate signatures for any contexts from which the store is accessed. For example, the public key of a timestamp authority (TSA) may be installed in a trust anchor store to validate signatures on timestamps [RFC3161] (Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, “Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP),” August 2001.). However, if the store containing this TA is used by multiple applications that serve different purposes, the same key may be used (inappropriately) to validate other types of objects such as certificates or OCSP responses. Prior to publication of [RFC5914] (Housley, R., Ashmore, S., and C. Wallace, “Trust Anchor Format,” June 2010.), there was no standard general purpose mechanism for limiting the applicability (scope) of a trust anchor. Placing different TAs in different stores and limiting the set of applications that access a given TA store is a common practice to address this problem.

Trust relationships between PKIs are negotiated by policy authorities. Negotiations frequently require significant time to ensure all participating parties' requirements are satisfied. These requirements are expressed, to some extent, in public key certificates via policy constraints, name constraints, etc. In order for these requirements to be enforced, trust anchor stores must be managed in accord with policy authority intentions. Otherwise, the constraints defined in a cross-certificate could be circumvented by recognizing the subject of the cross certificate as a trust anchor, which would enable path processing implementations to avoid the cross-certificate.

Trust anchors are often represented as self-signed certificates, which provide no useful means of establishing the validity of the information contained in the certificate. Confidence in the integrity of a trust anchor is typically established through out-of-band means, often by checking the "fingerprint" (one-way hash) of the self-signed certificate with an authoritative source. Routine trust anchor re-key operations typically require similar out-of-band checks, though in-band rekey of a trust anchor is supported by the Certificate Management Protocol (CMP) [RFC4210] (Adams, C., Farrell, S., Kause, T., and T. Mononen, “Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP),” September 2005.). Ideally, only the initial set of trust anchors are installed in a particular trust anchor store should require out-of-band verification, particularly when the costs of performing out-of-band checks commensurate with the security requirements of applications using the trust anchor store are high.

Despite the prevalent use of trust anchors, there is neither a standard means for discovering the set of trust anchors installed in a particular trust anchor store nor a standard means of managing those trust anchors. The remainder of this document describes requirements for a solution to this problem along with some security considerations.

3.  Requirements

This section describes the requirements for a trust anchor management protocol. Requirements are provided for trust anchor contents as well as for trust anchor store management operations.

3.1.  Transport independence

3.1.1.  Functional Requirements

A general-purpose solution for the management of trust anchors MUST be transport independent in order to apply to a range of device communications environments. It MUST work in both session-oriented and store-and-forward communications environments as well as in both push and pull distribution models. To accommodate both communication models in a uniform fashion, connectionless integrity and data origin authentication for TA transactions MUST be provided at the application layer. Confidentiality MAY be provided for such transactions.

3.1.2.  Rationale

Not all devices that use trust anchors are available for online management operations; some devices may require manual interaction for trust anchor management. Data origin authentication and integrity are required to ensure that the transaction has not been modified en route. Only connectionless integrity is required, for compatibility with store-and-forward contexts.

3.2.  Basic management operations

3.2.1.  Functional Requirements

At a minimum, a protocol used for trust anchor management MUST enable a trust anchor manager to perform the following operations:

• Determine which trust anchors are installed in a particular trust anchor store
• Add one or more trust anchors to a trust anchor store
• Remove one or more trust anchors from a trust anchor store
• Replace an entire trust anchor store

A trust anchor management protocol MUST provide support for these basic operations, however, not all implementations must support each option. For example, some implementations may support only replacement of trust anchor stores.

3.2.2.  Rationale

These requirements describe the core operations required to manage the contents of a trust anchor store. An edit operation was omitted for sake of simplicity, with consecutive remove and add operations used for this purpose. A single add or remove operation can act upon more than one trust anchor to avoid unnecessary round trips and are provided to avoid the need to always replace an entire trust anchor store. Trust anchor store replacement may be useful as a simple, higher bandwidth alternative to add and remove operations.

3.3.  Management targets

3.3.1.  Functional Requirements

A protocol for TA management MUST allow a TA management transaction to be directed to:

All TA stores for which the manager is responsible

An enumerated list of one or more named groups of trust anchor stores

An individual trust anchor store

3.3.2.  Rationale

Connections between PKIs can be accomplished using different means. Unilateral or bilateral cross-certification can be performed, or a community may simply elect to explicitly accept a trust anchor from another community. Typically, these decisions occur at the enterprise level. In some scenarios, it can be useful to establish these connections for a small community within an enterprise. Enterprise-wide mechanisms such as cross-certificates are ill-suited for this purpose since certificate revocation or expiration affects the entire enterprise.

A trust anchor management protocol can address this issue by supporting limited installation of trust anchors (i.e., installation of TAs in subsets of the enterprise user community), and by supporting expression of constraints on trust anchor use by relying parties. Limited installation requires the ability to identify the members of the community that are intended to rely upon a particular trust anchor, as well as the ability to query and report on the contents of trust anchor stores. Trust anchor constraints can be used to represent the limitations that might otherwise be expressed in a cross-certificate, and limited installation ensures the recognition of the trust anchor does not necessarily encompass an entire enterprise.

Trust anchor configurations may be uniform across an enterprise, or they may be unique to a single application or small set of applications. Many devices and some applications utilize multiple trust anchor stores. By providing means of addressing a specific store or collections of stores, a trust anchor management protocol can enable efficient management of all stores under a trust anchor manager's control.

3.4.  Delegation of TA Manager Authority

3.4.1.  Functional Requirements

A trust anchor management protocol MUST enable secure transfer of control of a trust anchor store from one trust anchor manager to another. It also SHOULD enable delegation for specific operations without requiring delegation of the overall trust anchor management capability itself.

3.4.2.  Rationale

Trust anchor manager re-key is one type of transfer that must be supported. In this case, the new key will be assigned the same privileges as the old key.

Creation of trust anchors for specific purposes, such as firmware signing, is another example of delegation. For example, a trust anchor manager may delegate only the authority to sign firmware to an entity, but disallow further delegation of that privilege, or the trust anchor manager may allow its delegate to further delegate firmware signing authority to other entities.

3.5.  RFC 5280 Support

3.5.1.  Functional Requirements

A trust anchor management protocol MUST enable management of trust anchors that will be used to validate certification paths and CRLs in accordance with [RFC5280] (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.) and [RFC5055] (Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. Polk, “Server-Based Certificate Validation Protocol (SCVP),” December 2007.). A trust anchor format MUST enable the representation of constraints that influence certification path validation or otherwise establish the scope of usage of the trust anchor public key. Examples of such constraints are name constraints, certificate policies, and key usage.

3.5.2.  Rationale

Certification path validation is one of the most common applications of trust anchors. The rules for using trust anchors for path validation are established in [RFC5280] (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.). [RFC5055] (Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. Polk, “Server-Based Certificate Validation Protocol (SCVP),” December 2007.) describes the use of trust anchors for delegated path validation. Trust anchors used to validate certification paths are responsible for providing, possibly through a delegate, the revocation status information of certificates it issues; this is often accomplished by signing a CRL.

3.6.  Support Purposes Other Than Certification Path Validation

3.6.1.  Functional Requirements

A trust anchor management protocol MUST enable management of trust anchors that can be used for purposes other than certification path validation, including trust anchors that cannot be used for certification path validation. It SHOULD be possible to authorize a trust anchor to delegate authority (to other TAs or certificate holders) and to prevent a trust anchor from delegating authority.

3.6.2.  Rationale

Trust anchors are used to validate a variety of signed objects, not just public key certificates and CRLs. For example, a trust anchor may be used to verify firmware packages [RFC4108] (Housley, R., “Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages,” August 2005.), OCSP responses [RFC2560] (Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP,” June 1999.), SCVP responses [RFC5055] (Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. Polk, “Server-Based Certificate Validation Protocol (SCVP),” December 2007.) or timestamps [RFC3161] (Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, “Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP),” August 2001.). TAs that are authorized for use with some or all of these other types of operations may not be authorized to verify public key certificates or CRLs. Thus it is important to be able to impose constraints on the ways in which a given TA is employed.

3.7.  Trust Anchor Format

3.7.1.  Functional Requirements

Minimally, a trust anchor management protocol MUST support management of trust anchors represented as self-signed certificates and trust anchors represented as a distinguished name, public key information and, optionally, associated data. The definition of a trust anchor MUST include a public key, a public key algorithm and, if necessary, public key parameters. When the public key is used to validate certification paths or CRLs, a distinguished name also MUST be included per [RFC5280] (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.). A trust anchor format SHOULD enable specification of a public key identifier to enable other applications of the trust anchor, for example, verification of data signed using the Cryptographic Message Syntax (CMS) SignedData structure [RFC5652] (Housley, R., “Cryptographic Message Syntax (CMS),” September 2009.). A trust anchor format also SHOULD enable the representation of constraints that can be applied to restrict the use of a trust anchor.

3.7.2.  Rationale

Prior to the publication of [RFC5914] (Housley, R., Ashmore, S., and C. Wallace, “Trust Anchor Format,” June 2010.), there was no standardized format for trust anchors. Self-signed X.509 certificates are typically used but [RFC5280] (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.) does not mandate a particular trust anchor representation. It requires only that a trust anchor's public key information and distinguished name be available during certification path validation. CMS is widely used to protect a variety of types of content using digital signatures, including contents that may verified directly using a trust anchor, such as firmware packages [RFC4108] (Housley, R., “Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages,” August 2005.). Constraints may include a validity period, constraints on certification path validation, etc.

3.8.  Source Authentication

3.8.1.  Functional Requirements

An entity receiving trust anchor management data MUST be able to authenticate the identity of the party providing the information and MUST be able to confirm the party is authorized to provide that trust anchor information.

A trust anchor manager MUST be able to authenticate which trust anchor store corresponds to a report listing the contents of the trust anchor store and be able to confirm the contents of the report have not been subsequently altered.

3.8.2.  Rationale

Data origin authentication and integrity are required to support remote management operations, even when TA management transactions are effected via store-and-forward communications.

3.9.  Reduce Reliance on Out-of-Band Trust Mechanisms

3.9.1.  Functional Requirements

When performing add operations, a trust anchor management protocol SHOULD enable TA integrity to be checked automatically by a relying party without relying on out-of-band trust mechanisms.

3.9.2.  Rationale

Traditionally, a trust anchor is distributed out-of-band with its integrity checked manually prior to installation. Installation typically is performed by anyone with sufficient administrative privilege on the system receiving the trust anchor. Reliance on out-of-band trust mechanisms is one problem with current trust anchor management approaches and reduction of the need to use out-of-band trust mechanisms is a primary motivation for developing a trust anchor management protocol. Ideally, out-of-band trust mechanisms will be required only during trust anchor store initialization.

3.10.  Replay Detection

3.10.1.  Functional Requirements

A trust anchor management protocol MUST enable participants engaged in a trust anchor management protocol exchange to detect replay attacks. A replay detection mechanism that does not introduce a requirement for a reliable source of time MUST be available. Mechanisms that do require a reliable source of time MAY be available.

3.10.2.  Rationale

Detection of replays of trust anchor management transaction is required to support remote management operations. Replay of old trust anchor management transaction could result in the reintroduction of compromised trust anchors to a trust anchor store, potentially exposing applications to malicious signed objects or certification paths.

Some devices that utilize trust anchors have no access to a reliable source of time, so a replay detection mechanism that requires a reliable time source is insufficient.

3.11.  Compromise or Disaster Recovery

3.11.1.  Functional Requirements

A trust anchor management protocol MUST enable recovery from the compromise or loss of a trust anchor private key, including the private key authorized to serve as a trust anchor manager, without requiring reinitialization of the trust store.

3.11.2.  Rationale

Compromise or loss of a private key corresponding to a trust anchor can have significant negative consequences. Currently, in some cases, re-initialization of all effected trust anchor stores is required to recover from a lost or compromised trust anchor key. Due to the costs associated with re-initialization, a trust anchor management protocol should support recovery options that do not require trust anchor store re-initialization.

4.  Security Considerations

The public key used to authenticate a TA management transaction may have been placed in the client as the result of an earlier TA management transaction or during an initial bootstrap configuration operation. In most scenarios, at least one public key authorized for trust anchor management must be placed in each trust anchor store to be managed during the initial configuration of the trust anchor store. This public key may be transported and checked using out-of-band means. In all scenarios, regardless of the authentication mechanism, at least one trust anchor manager must be established for each trust anchor store during the initial configuration of the trust anchor store.

Compromise of a trust anchor's private key can result in many security problems including issuance of bogus certificates or installation of rogue trust anchors.

Usage of trust anchor-based constraints requires great care when defining trust anchors. Errors on the part of a trust anchor manager could result in denial of service or have serious security consequences. For example, if a name constraint for a trust anchor that serves as the root of a PKI includes a typo, denial of service results for certificate holders and relying parties. If a trust anchor manager inadvertently delegates all of its privileges and the delegate subsequently removes the trust anchor manager from trust anchor stores now under its control, recovery may require reinitialization of all effected trust anchor stores.

RFC 5280 requires that certificate path validation be initialized with a TA subject name and public key, but does not require processing of other information, such as name constraints extensions. Inclusion of constraints in trust anchors is optional. When constraints are explicitly included by a trust anchor manager using a trust anchor management protocol, there exists an expectation that the certificate path validation algorithm will make use of the constraints. Application owners must confirm the path processing implementations support the processing of TA-based constraints, where required.

Many of the security considerations from [RFC5280] (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.) are also applicable to trust anchor management.

5.  IANA Considerations

None. Please remove this section prior to publication as an RFC.

6.  References

6.1. Normative References

6.2. Informative References

Authors' Addresses