One document matched: draft-ietf-pkix-ta-mgmt-reqs-00.xml

<?xml version='1.0' ?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc2440 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2440.xml'>
  <!ENTITY rfc2560 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2560.xml'>
  <!ENTITY rfc3161 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3161.xml'>
  <!ENTITY rfc3852 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3852.xml'>
  <!ENTITY rfc5280 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml'>
  <!ENTITY rfc4108 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4108.xml'>
  <!ENTITY rfc5055 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5055.xml'>
]>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

<rfc ipr="full3978" docName="draft-ietf-pkix-ta-mgmt-reqs-00" category="info">
  <front>
    <title abbrev="Trust Anchor Management">Trust Anchor Management Requirements</title>
    <author initials="R.R." surname="Reddy" fullname="Raksha Reddy">
      <organization>National Security Agency</organization>
      <address>
        <postal>
          <street>Suite 6599</street>
          <street>9800 Savage Road</street>
          <city>Fort Meade</city>
          <region>MD</region>
          <code>20755</code>
        </postal>
        <email>r.reddy@radium.ncsc.mil</email>
      </address>
    </author>
    <author initials="C.W." surname="Wallace" fullname="Carl Wallace">
      <organization>Cygnacom Solutions</organization>
      <address>
        <postal>
          <street>Suite 5200</street>
          <street>7925 Jones Branch Drive</street>
          <city>McLean</city>
          <region>VA</region>
          <code>22102</code>
        </postal>
        <email>cwallace@cygnacom.com</email>
      </address>
    </author>
    <date month="June" year="2008" />
    <area>Security</area>
    <abstract>
      <t>
        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 protocols designed to address these problems.  This document discusses only public keys as trust anchors; symmetric key trust anchors are not considered.
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction">
      <t>
        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 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:
      </t>
      <t>
        <list style="symbols">
          <t>a public key certificate that begins a certification path terminated by a signature certificate or encryption certificate</t>
          <t>an object (other than a public key certificate) that cannot be validated via use of a certification path</t>
        </list>
      </t>
      <t>
        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.
      </t>
      <t>
        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.
      </t>
      <t>
        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.
      </t>
      <t>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.</t>
      <section title="Terminology">
        <t>The following terms are defined in order to provide a vocabulary for describing requirements for trust anchor management.</t>
        <t>
          <list style="hanging">
            <t hangText="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.
            </t>
            <t hangText="Trust Anchor Manager: ">
              Trust anchor manager is a role responsible for managing the contents of a trust anchor store.  Throughout this document, trust anchor managers are assumed to be represented as trust anchors.
            </t>
            <t hangText="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.  A device may have more than one trust anchor store.
            </t>
          </list>
        </t>
      </section>
    </section>
    <section title="Problem Statement">
      <t>
        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.
        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.  
      </t>
      <t>
        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.
      </t>

      <t>
        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.
      </t>
      <t>
        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.
      </t>
      <t>
        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.
      </t>
      <t>
        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 requirements for a solution to this problem along with
        some security considerations.
      </t>
    </section>
    
    <section title="Requirements">
      <t>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.</t>
 
      <section title="Transport independence">
        <section title="Functional Requirements">
          <t>
            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 be applicable in both session-oriented and store-and-forward contexts.  Message integrity must be assured in all cases.
          </t>
        </section>
        <section title="Rationale">
          <t>
            Not all devices that use trust anchors are available for online management operations; some devices may require manual interaction for trust anchor management.  Message integrity is required to authenticate the originator of a TA management transaction and confirm the authorization of the originator for that transaction.
          </t>
        </section>
        <!--Transport independence-->
      </section>

      <section title="Basic management operations">
        <section title="Functional Requirements">
          <t>
            At a minimum, a protocol used for trust anchor management must enable a trust anchor manager to perform the following operations:
          </t>
          <t>
            <list style="symbols">
              <t>Determine which trust anchors are installed in a particular trust anchor store</t>
              <t>Add one or more trust anchors to a trust anchor store</t>
              <t>Remove one or more trust anchors from a trust anchor store</t>
              <t>Replace an entire trust anchor store</t>
            </list>
          </t>
          <t>
            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 only support replacement of trust anchor stores.
          </t>
        </section>
        <section title="Rationale">
          <t>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.  Add and remove operations are compound to avoid unnecessary round trips and are provided to avoid always replacing an entire trust anchor store.  Trust anchor store replacement may be useful as a simple, higher bandwidth alternative to add and remove operations.  Many devices and some applications utilize multiple trust anchor stores.  Trust anchor store discovery is required to determine which trust anchor stores are present in a particular context.</t>
        </section>
        <!--Basic management operations-->
      </section>

      <section title="Management targets">
        <section title="Functional Requirements">
          <t>
            A protocol for TA management must allow a TA management transaction to be directed to:
          </t>
          <t>
          <list>
            <t>All TA stores for which the manager is responsible</t>
            <t>An enumerated list of one or more groups of trust anchor stores</t>
            <t>An individual trust anchor store</t>
          </list>
          </t>
        </section>
        <section title="Rationale">
          <t>
            Trust anchor configurations may be uniform across an enterprise, or they may be unique to a single application or small set of applications.   
          </t>
          <t>
            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 an entire enterprise.
          </t>
        </section>
        <!--Limited scope-->
      </section>

      <section title="Delegation of TA Management Authority">
        <section title="Functional Requirements">
          <t>
            A trust anchor management protocol must enable secure transfer of control of a trust anchor store from one trust anchor manager to another.  It must also enable delegation for specific operations without requiring delegation of the overall trust anchor management capability itself.  
          </t>
        </section>
        <section title="Rationale">
          <t>
            Trust anchor 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 and disallow further delegation of the privilege, or the trust anchor manager may allow its delegate to delegate firmware signing to other entities.
          </t>
        </section>
        <!--Delegation of TA Management Authority-->
      </section>

      <section title="RFC 5280 Support">
        <section title="Functional Requirements">
          <t>
            A trust anchor management protocol must enable management of trust anchors that can be used to validate certification paths in accordance with <xref target="RFC5280"/> and <xref target="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.  
          </t>
        </section>
        <section title="Rationale">
          <t>
            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 <xref target="RFC5280"/>.  <xref target="RFC5055"/> describes the use of trust anchors for delegated path validation.
          </t>
        </section>
        <!--RFC 5280 Support-->
      </section>

      <section title="Support Purposes Other Than Certification Path Validation">
        <section title="Functional Requirements">
          <t>
            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.
          </t>
        </section>
        <section title="Rationale">
          <t>Trust anchors are used to validate a variety of objects other than public key certificates and CRLs.  For example, a trust anchor may be used to verify firmware packages <xref target="RFC4108"/>, OCSP responses <xref target="RFC2560"/>, SCVP responses <xref target="RFC5055"/> or timestamps <xref target="RFC3161"/>.  TAs authorized for these
   operations may not be authorized to sign public key certificates or CRLs.</t>
        </section>
        <!--Support Purposes Other Than Certification Path Validation-->
      </section>

      <section title="Trust Anchor Format">
        <section title="Functional Requirements">
          <t>
            Minimally, a trust anchor management protocol must support management of trust anchors represented as self-signed certificates or as a distinguished name and public key information.  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 per <xref target="RFC3852"/>.  A trust anchor format should enable specification of 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 <xref target="RFC3852"/>.  A trust anchor format should also enable the use of constraints that can be applied to specify the type/usage of a trust anchor.
          </t>
        </section>
        <section title="Rationale">
          <t>
            There is no standardized format for trust anchors.  Self-signed X.509 certificates are typically used but <xref target="RFC5280"/> 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 <xref target="RFC4108"/>.
          </t>
        </section>
        <!-- Format Requirements -->
      </section>

      <section title="Authentication of Trust Anchor Store Contents">
        <section title="Functional Requirements">
          <t>
            A trust anchor manager must be able to authenticate which trust anchor store produced 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.  Replay of old reports (from the same trust anchor store) must be detectable by a TA manager.
          </t>
        </section>
        <section title="Rationale">
          <t>Authentication of trust anchor store-generated reports is required to support remote management operations.</t>  
        </section>
        <!-- Trust Anchor Store Authentication -->
      </section>

      <section title="Source Authentication">
        <section title="Functional Requirements">
          <t>
            An entity receiving trust anchor management data 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.          
          </t>
        </section>
        <section title="Rationale">
          <t>
            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.  
          </t>
        </section>
        <!--Source Authentication-->
      </section>

      <section title="Reduce Reliance on Out-of-Band Trust Mechanisms">
        <section title="Functional Requirements">
          <t>
            A trust anchor management protocol should enable TA integrity to be checked automatically without relying on out-of-band trust mechanisms.  
          </t>
        </section>
        <section title="Rationale">
          <t>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.</t>
        </section>
        <!--Reduce Reliance on Out-of-Band Trust Mechanisms-->
      </section>

      <section title="Replay Detection">
        <section title="Functional Requirements">
          <t>
            A trust anchor management protocol must enable participants engaged in a trust anchor management protocol exchange to detect replay attacks.  Replay detection mechanisms should not introduce a requirement for a reliable source of time as some devices that utilize trust anchors have no access to a reliable source of time.
          </t>
        </section>
        <section title="Rationale">
          <t>Replay of old trust anchor management messages could result in the addition of compromised trust anchors to a trust anchor store, potentially exposing applications to malicious signed objects or certification paths.</t>
        </section>
        <!--Replay Detection-->
      </section>

      <section title="Compromise or Disaster Recovery">
        <section title="Functional Requirements">
          <t>
            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 source of trust anchor information.  
          </t>
        </section>
        <section title="Rationale">
          <t>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.  A trust anchor management protocol should support recovery options that do not require trust anchor store re-initialization.</t>
        </section>
        <!--Compromise Recovery-->
      </section>
    </section>

    <section title="Security Considerations">
      <t>
        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.
      </t>
      <t>Many of the security considerations from <xref target="RFC5280"/> are also applicable to trust anchor management.</t>
    </section>
    <section title="IANA Considerations">
      <t>None.  Please remove this section prior to publication as an RFC.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      &rfc5280;
    </references>
    <references title="Informative References">
      &rfc2560;&rfc3161;&rfc3852;&rfc4108;&rfc5055;
    </references>
  </back>
</rfc>