RFC 6024

Trust Anchor Management Requirements

📅 published October 2010, from ietf

RFC 6024: Trust Anchor Management Requirements 🎀

Okay bestie, this one is RFC 6024, and it's all about trust anchors 🔐. It's published as Informational, which means it's sharing info, not a standards-track spec. The authors are R. Reddy from the National Security Agency and C. Wallace from Cygnacom Solutions. It came out in October 2010, and it's on the IETF stream with ISSN 2070-1721. It doesn't obsolete or update any other RFCs. 💅

Abstract 🌸

Okay so a trust anchor is an authoritative entity, represented by a public key plus some associated data 🔑. The public key checks digital signatures, and the associated data limits what kinds of info the trust anchor is actually authoritative for. A relying party uses trust anchors to decide if a signed object is valid. It does this by checking the signature with the trust anchor's public key and by enforcing the constraints in the associated data ✨. This doc describes the problems caused by not having a standard way to manage trust anchors, and it sets requirements for data formats and push-based protocols that fix them. It's giving problem-solver energy 🦋.

Status of This Memo 📝

This document is not an Internet Standards Track specification. It's published for informational purposes only 💜.

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🧐.

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6024 🌈.

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 it was published. Please read those carefully, since they explain your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Unless you get an adequate license from those copyright holders, this document must not be modified outside the IETF Standards Process, and derivative works of it must not be created outside the IETF Standards Process. The one exception is formatting it for publication as an RFC or translating it into languages other than English 🙏.

Table of Contents 🗺️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
  1.2.  Requirements Notation  . . . . . . . . . . . . . . . . . .  4
2.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  5
3.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  6
  3.1.  Transport Independence . . . . . . . . . . . . . . . . . .  6
  3.2.  Basic Management Operations  . . . . . . . . . . . . . . .  7
  3.3.  Management Targets . . . . . . . . . . . . . . . . . . . .  7
  3.4.  Delegation of TA Manager Authority . . . . . . . . . . . .  8
  3.5.  RFC 5280 Support . . . . . . . . . . . . . . . . . . . . .  9
  3.6.  Support Purposes other than Certification Path
        Validation . . . . . . . . . . . . . . . . . . . . . . . .  9
  3.7.  Trust Anchor Format  . . . . . . . . . . . . . . . . . . . 10
  3.8.  Source Authentication  . . . . . . . . . . . . . . . . . . 10
  3.9.  Reduce Reliance on Out-of-Band Trust Mechanisms  . . . . . 11
  3.10. Replay Detection . . . . . . . . . . . . . . . . . . . . . 11
  3.11. Compromise or Disaster Recovery  . . . . . . . . . . . . . 12
4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
  5.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
  5.2.  Informative References . . . . . . . . . . . . . . . . . . 13

1. Introduction ✨

Okay so digital signatures are everywhere 💅. For a signature to give you integrity and authentication, the public key that verifies it must be "trusted", meaning a relying party (RP) accepts it as appropriate for the context it's working in. A public key used to verify a signature must be configured as a trust anchor (TA), or be contained in a certificate that can be transitively verified by a certification path ending at a trust anchor. A trust anchor is a public key plus associated data that an RP uses 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 only have local significance 🏠. Each RP is configured with a set of trust anchors, either by the RP itself or by an entity that manages TAs in the context where the RP operates. The associated data defines the scope of a trust anchor by putting 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, those constraints might cover a combination of name spaces, certificate policies, or application/usage types 🧩.

One use of digital signatures is verifying signatures on firmware packages loaded into hardware modules, like cryptographic modules, cable boxes, routers, etc. 📡 Since these devices are often managed remotely, they must be able to authenticate the source of management interactions, and they can use trust anchors to do that. But trust anchors need managing too 😭. Other apps that need 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) 📧.

Every app that relies on digital signatures relies on some way of managing one or more sets of trust anchors 🔥. Each set of trust anchors is called a trust anchor store in this document. Usually the means of managing trust anchor stores are app-specific and depend on out-of-band means to establish and maintain trustworthiness. An app may use multiple trust anchor stores, and a given trust anchor store may be used by multiple apps. Each trust anchor store is managed by at least one TA manager, and a TA manager may manage multiple TA stores 👑.

The requirements in this document were written before [RFC5914] and [RFC5934] were published. The doc wasn't published at that time, so requirements could still change while the technical specs were being developed. The requirements below are the ones that were considered while [RFC5914] and [RFC5934] were being developed 🦋.

This section is the intro and defines the 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 📖

Okay, these terms are defined so we all have the same vocab for describing trust anchor management requirements 🫶.

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: A 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, and each of them 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] 💖.

(continued in part 2 🫶)

2. Problem Statement ✨

okay so trust anchors are literally everywhere 💖 most browsers and email clients use them when they authenticate TLS sessions, verify signed email, or generate encrypted email by validating a certification path to a server's certificate, an email originator's certificate, or an email recipient's certificate, respectively. 🎀 Lots of software distributions are digitally signed too, so you can authenticate the source before installing anything 🔐 (it's giving security, fr). These trust anchors are usually installed as part of the operating system (OS) or application, pushed out with an enterprise configuration management system, or installed directly by an OS or application user. 💅

Trust anchors are typically stored in application-specific or OS-specific trust anchor stores, and honestly it's a little messy 🙈 one machine can have a bunch of different stores that aren't synchronized with each other. Looking at what's in a particular store usually means using a proprietary tool that only speaks that one store's language. 💀

Here's the tea 🫣 having a trust anchor in a particular store often gives implicit permission to validate signatures for any context that store is accessed from. For example, a timestamp authority's (TSA) public key might be installed in a store so it can validate signatures on timestamps [RFC3161]. But if that same store is used by multiple applications with different purposes, the same key could be used (inappropriately) to validate other things like certificates or Online Certificate Status Protocol (OCSP) responses. 😭 Before [RFC5914] was published, there was no standard general-purpose mechanism for limiting the applicability (scope) of a trust anchor. The common workaround was to place different TAs in different stores and limit the set of applications that access a given TA store. 🧚

Trust relationships between Public Key Infrastructures (PKIs) are negotiated by policy authorities, and those negotiations can take a lot of time ⏳ because everyone's requirements need to be satisfied. Those requirements are expressed, to some extent, in public key certificates through policy constraints, name constraints, etc. 📜 For these requirements to actually be enforced, trust anchor stores have to be managed in line with what the policy authority intended. Otherwise, the constraints in a cross-certificate could be dodged by recognizing the subject of the cross-certificate as a trust anchor, which would let path processing implementations skip the cross-certificate entirely. 🙅‍♀️ no thank u.

Trust anchors are often represented as self-signed certificates, which don't provide any useful means of establishing that the information in the certificate is valid 🤷 Confidence in a trust anchor's integrity is usually established out-of-band, often by checking the "fingerprint" (one-way hash) of the self-signed certificate against an authoritative source. Routine trust anchor rekey operations typically need similar out-of-band checks, though in-band rekey of a trust anchor is supported by the Certificate Management Protocol (CMP) [RFC4210]. Ideally, only the initial set of trust anchors installed in a particular trust anchor store should require out-of-band verification, especially when the costs of out-of-band checks are high compared to the security requirements of the applications using that store. 🎯

Despite how prevalent trust anchors are, there's no standard means for discovering the set of trust anchors installed in a particular trust anchor store, and no standard means of managing them either 😤 The rest 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 managing trust anchors MUST be transport independent so it can apply across 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 handle both communication models in a uniform way, 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, so some devices may need manual interaction for trust anchor management. Data origin authentication and integrity are required to make sure the transaction hasn't 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 needed to manage the contents of a trust anchor store. An edit operation was left out for the 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 these operations are provided so you don't always have to 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 set up 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 happen at the enterprise level. In some scenarios it can be useful to set up 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 that recognizing 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 rekey 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] and [RFC5055]. 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]. [RFC5055] 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 they issue; 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], OCSP responses [RFC2560], Server-Based Certificate Validation Protocol (SCVP) responses [RFC5055], or timestamps [RFC3161]. 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 📜

Okay bestie, the bare minimum here is that a trust anchor management protocol MUST support management of trust anchors represented as self-signed certificates, and also trust anchors represented as a distinguished name, public key information, and, optionally, associated data 🎀. A trust anchor's definition MUST include a public key, a public key algorithm, and, if necessary, public key parameters 🔑. When that public key is used to validate certification paths or CRLs, a distinguished name also MUST be included per [RFC5280] ✨. A trust anchor format SHOULD let you specify a public key identifier so other applications can use the trust anchor too, like verifying data signed with the Cryptographic Message Syntax (CMS) SignedData structure [RFC5652] 💅. A trust anchor format also SHOULD let you represent constraints that restrict how a trust anchor can be used 🦋.

3.7.2. Rationale 🌸

So here's the tea 🫖. Before [RFC5914] came out, there was no standardized format for trust anchors, which is kind of wild 😭. Self-signed X.509 certificates are what people usually reach for, but [RFC5280] doesn't mandate any particular trust anchor representation. It only requires that a trust anchor's public key information and distinguished name be available during certification path validation 🧚. CMS is super popular for protecting all kinds of content with digital signatures, including stuff that can be checked straight against a trust anchor, like firmware packages [RFC4108] 🔥. And constraints might include a validity period, constraints on certification path validation, etc. 💜

3.8. Source Authentication 🪪

3.8.1. Functional Requirements 🔍

An entity that receives trust anchor management data MUST be able to authenticate the identity of the party providing the information, and MUST be able to confirm that 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 go through 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, and its integrity gets checked manually before installation 😩. Installation is typically done by anyone with sufficient administrative privilege on the system receiving the trust anchor, which is a big ask 🙈. Reliance on out-of-band trust mechanisms is one problem with current trust anchor management approaches, so reducing the need for them 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 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 🧠

Detecting replays of trust anchor management transactions is required to support remote management operations 📡. Replaying old trust anchor management transactions could result in compromised trust anchors getting reintroduced to a trust anchor store, which could potentially expose applications to malicious signed objects or certification paths 😱.

Some devices that use trust anchors have no access to a reliable source of time, so a replay detection mechanism that requires a reliable time source is insufficient for them 🕯️.

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 re-initialization 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 💀. Right now, in some cases, every affected trust anchor store has to be re-initialized to recover from a lost or compromised trust anchor key 😤. Because re-initialization is costly, a trust anchor management protocol should support recovery options that don't 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 that 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 its initial configuration 🏰.

Compromise of a trust anchor's private key can cause lots of security problems, including issuance of bogus certificates or installation of rogue trust anchors 🚩💀.

Using 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 later removes the trust anchor manager from the trust anchor stores now under its control, recovery may require re-initialization of all affected trust anchor stores 😭.

[RFC5280] requires that certificate path validation be initialized with a TA subject name and public key, but it does not require processing of other information, such as name constraints extensions 📋. Including constraints in trust anchors is optional 🎈. When a trust anchor manager explicitly includes constraints using a trust anchor management protocol, there is an expectation that the certificate path validation algorithm will make use of those constraints ✅. Application owners must confirm that path processing implementations support processing of TA-based constraints, where required 🔎.

Many of the security considerations from [RFC5280] are also applicable to trust anchor management 🌟.

5. References 📚

5.1. Normative References 💫

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑
  • [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. Polk, "Server-Based Certificate Validation Protocol (SCVP)", RFC 5055, December 2007. 🛰️
  • [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", RFC 5280, May 2008. 🎀

5.2. Informative References 🌼

  • [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999. 🦋
  • [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001. ⏱️
  • [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, August 2005. 🔐
  • [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, September 2005. 🧾
  • [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009. 📦
  • [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Format", RFC 5914, June 2010. ⚓
  • [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Management Protocol (TAMP)", RFC 5934, August 2010. 🌈

Authors' Addresses 💌

Raksha Reddy
National Security Agency
Suite 6599
9800 Savage Road
Fort Meade, MD  20755

EMail: r.reddy@radium.ncsc.mil


Carl Wallace
Cygnacom Solutions
Suite 5400
7925 Jones Branch Drive
McLean, VA  22102

EMail: cwallace@cygnacom.com
📦 where this page comes from