Trust Anchor Management Problem Statement

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 paty (RP) as authoritative for an application. A public key used to verify a signature must be configured as a trust anchor or contained in a certificate that can be transitively verified by a certification path terminating at a trust anchor. Directly trusted public keys are known as trust anchors. 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) 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 often is used to define the scope of a trust anchor, by imposing constraints on the signatures it 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. Whenever a signature is verified, a trust anchor must be used, either by verifying the signature directly using a TA or by validating a certification path that begins with a TA. One particular 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. All applications that rely upon digital signatures rely upon some means of managing one or more sets of trust anchors. These sets of trust anchors are referred to in this document as trust anchor stores. 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. Trust anchor stores are managed by trust anchor managers. In some cases, a device may have a single trust anchor that is hard-wired or managed only through physical access to the device. However, to support the ability to delegate different TA managment functions to different authorities, the device may require multiple trust anchors. It may be desirable to manage these trust anchors using similar means as software updates, certificate requests, etc., to enable code reuse. This section provides an introduction and defines basic terminology. Section 2 describes problems with current trust anchor management methods. Sections 3 and 4 describe functional properties and security considerations for a trust anchor management solution, and essentially define requirements for a trust anchor management solution.

The following terms are defined in order to provide a vocabulary for describing requirements for trust anchor management. A trust anchor is an authoritative entity represented 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. A trust anchor manager is a role responsible for managing the contents of a trust anchor store. A trust anchor store is a set of one or more trust anchors. A trust anchor store may be managed by one or more trust anchor managers.

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 or a mail originator's or recipient's certificate. Many software distributions are digitally signed to enable authentication of the software source to be performed 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. An application and platform-independent way to manage TAs would be preferable. Trust anchors are typically stored in application- 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. 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. There is currently no standard means of limiting the applicability (scope) of a trust anchor except by placing different TAs in different stores and limiting the set of applications that access a given TA store. 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 and etc. In order for these requirements to be enforced, trust anchor stores must be managed in accord with policy authority intentions and avoid circumventing constraints defined in a cross-certificate by recognizing the subject of the cross certificate as a trust anchor. 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. Ideally, only the initial set of trust anchors 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 which trust anchors installed in a particular trust anchor store nor a standard means of managing those trust anchors. The remainder of this document describes some of the functional characteristics a solution to this problem should exhibit along with some security considerations.

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 should also be applicable in both session-oriented and store-and-forward contexts. At a minimum, it must enable a trust anchor manager to discovery which TA stores are present, to add trust anchors to, remove trust anchors from, and determine which trust anchors are installed in a particular trust anchor store. Trust anchor configurations may be uniform across an enterprise, or they may be unique to a single application or small set of applications. A protocol for TA management must allow a TA management transaction, to be directed to all TA stores for which the manager is responsible, targeted to an enumerated list of one or more groups of trust anchor stores, or targeted to an individual trust anchor store. Once installed into a trust anchor store, a trust anchor represents an entity with authority recognized by applications that use that store. It is important to be able to define the scope of authority associated with each trust anchor. That scope be very specific (e.g., a trust anchor public key may be limited to verification of firmware updates only), or more general (such as to validate certification paths for certificates issued to users or devices). It should be possible to authorize a trust anchor to delegate authority (to other TAs) and to prevent delegation. A trust anchor manager has significant control over a device or application due to the ability to control what other authorities are recognized. In some cases, a trust anchor manager may be the legal owner of a device or application. In other cases, a trust anchor manager may be an entity responsible for the operation of a device, such as a firmware provider for a cable or satellite TV set top box. A trust anchor manager may be static over the life of a device, or it may change as legal ownership or other factors change. A trust anchor management protocol should enable secure transfer of control of a device from one trust anchor manager to another. It also should enable delegation of TA management control over specific aspects of the device, without requiring delegation of the overall trust anchor management capability itself. Trust anchor re-key is one type of transfer that must be supported. A trust anchor management protocol must be capable of managing trust anchors that can be used to validate certification paths in accordance with . Minimally, 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, a distinguished name also must be included. A public key identifier should be included to enable other applications of the trust anchor, for example, verification of data signed using the Cryptographic Message Syntax SignedData structure . Trust anchors may be explicitly authorized for a limited set of purposes. For example, a trust anchor may be authorized for verification of signed firmware packages but not authorized for validating certification paths. A trust anchor management protocol must enable the management of trust anchors that do not serve as trust anchors for certification path validation. 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 and by supporting expression of constraints on trust anchor usage. Limited installation requires the ability to identify the members of the community that are authorized to rely upon a particular trust anchor, as well as the ability to query and report on the contents of trust anchor stores. The trust anchor constraints can represent the limitations that would have been expressed in a cross-certificate and limited installation ensures the recognition of the trust anchor does not necessarily encompass and entire enterprise. There is no standardized format for trust anchors. Self-signed X.509 certificates are typically used but 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. Minimally, a trust anchor management protocol should support management of trust anchors represented as self-signed certificates or as a distinguished name and public key information. A trust anchor manager must be able to authenticate which device produced a report listing the contents of a trust anchor store and, be able to confirm the contents of the report have not been subsequently altered. Replay of old reports (from the same device) must be detectable by a TA manager. A trust anchor definition should 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. A trust anchor manager must be able to establish the constraints associated with every trust anchor controlled by the manager.

The integrity of trust anchor management transactions must be assured, i.e., and it must be possible to authenticate the originator of a TA management transaction and confirm the authorization of the originator for that transaction. 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. A trust anchor management protocol should enable TA integrity to be checked automatically by relying upon a public key that is resident in a client system participating in the protocol. The public key used to authenticate the trust anchor management transactions may have been placed in the client as the result of an earlier 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 store to be managed during the initial configuration of the trust store. This public key may be transported and checked using traditional out-of-band means. In all scenarios, regardless of the authentication mechanism, at least one trust anchor manager must be established for each trust store during the initial configuration of the trust store. An entity receiving trust anchor information must be able to authenticate 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 may be authorized to participate in trust anchor management protocol exchanges, but be limited to managing trust anchors within a particular scope. Alternatively, a trust anchor manager may be authorized to participate in trust anchor management protocol exchanges without any constraints on the types of trust anchors that may be managed. Clear subordination rules must be defined so that an administrator can determine, unambiguously, the scope of authority for any trust anchor installed in a device. Some devices that utilize trust anchors may have no access to a reliable source of time. Trust anchor management transactions should enable such devices to engage in trust anchor management protocol exchanges without being subject to replay attacks that could add old or no-longer-trusted trust anchors to a trust anchor store. Compromise of a private key corresponding to a trust anchor can have significant negative consequences. A trust anchor management protocol must enable recovery from the compromise of a trust anchor private key, including the private key authorized to serve as a source of trust anchor information.

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