Документ взят из кэша поисковой машины. Адрес оригинального документа : http://mirror.msu.net/pub/rfc-editor/rfc-ed-all/rfc5934.txt Дата изменения: Fri Aug 20 02:43:11 2010 Дата индексирования: Mon Oct 1 23:16:25 2012 Кодировка: Поисковые слова: 47 tuc

Internet Engineering Task Force (IETF) R. Housley
Request for Comments: 5934 Vigil Security, LLC
Category: Standards Track S. Ashmore
ISSN: 2070-1721 National Security Agency
C. Wallace
Cygnacom Solutions
August 2010


Trust Anchor Management Protocol (TAMP)

Abstract

This document describes a transport independent protocol for the
management of trust anchors (TAs) and community identifiers stored in
a trust anchor store. The protocol makes use of the Cryptographic
Message Syntax (CMS), and a digital signature is used to provide
integrity protection and data origin authentication. The protocol
can be used to manage trust anchor stores containing trust anchors
represented as Certificate, TBSCertificate, or TrustAnchorInfo
objects.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5934.
















Housley, et al. Standards Track [Page 1]

RFC 5934 TAMP August 2010


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.

























Housley, et al. Standards Track [Page 2]

RFC 5934 TAMP August 2010


Table of Contents

1. Introduction ....................................................4
1.1. Terminology ................................................5
1.2. Trust Anchors ..............................................5
1.2.1. Apex Trust Anchors ..................................6
1.2.2. Management Trust Anchors ............................7
1.2.3. Identity Trust Anchors ..............................7
1.3. Architectural Elements .....................................8
1.3.1. Cryptographic Module ................................8
1.3.2. Trust Anchor Store ..................................9
1.3.3. TAMP Processing Dependencies ........................9
1.3.4. Application-Specific Protocol Processing ...........10
1.4. ASN.1 Encoding ............................................11
2. Cryptographic Message Syntax Profile ...........................12
2.1. ContentInfo ...............................................13
2.2. SignedData Info ...........................................14
2.2.1. SignerInfo .........................................15
2.2.2. EncapsulatedContentInfo ............................16
2.2.3. Signed Attributes ..................................16
2.2.4. Unsigned Attributes ................................18
3. Trust Anchor Formats ...........................................18
4. Trust Anchor Management Protocol Messages ......................19
4.1. TAMP Status Query .........................................21
4.2. TAMP Status Query Response ................................24
4.3. Trust Anchor Update .......................................27
4.3.1. Trust Anchor List ..................................31
4.4. Trust Anchor Update Confirm ...............................32
4.5. Apex Trust Anchor Update ..................................34
4.6. Apex Trust Anchor Update Confirm ..........................36
4.7. Community Update ..........................................38
4.8. Community Update Confirm ..................................40
4.9. Sequence Number Adjust ....................................42
4.10. Sequence Number Adjust Confirm ...........................43
4.11. TAMP Error ...............................................44
5. Status Codes ...................................................45
6. Sequence Number Processing .....................................50
7. Subordination Processing .......................................51
8. Implementation Considerations ..................................54
9. Wrapped Apex Contingency Key Certificate Extension .............54
10. Security Considerations .......................................55
11. IANA Considerations ...........................................58
12. References ....................................................58
12.1. Normative References .....................................58
12.2. Informative References ...................................59






Housley, et al. Standards Track [Page 3]

RFC 5934 TAMP August 2010


Appendix A. ASN.1 Modules ........................................61
A.1. ASN.1 Module Using 1993 Syntax ............................61
A.2. ASN.1 Module Using 1988 Syntax ............................70
Appendix B. Media Type Registrations .............................77
B.1. application/tamp-status-query .............................77
B.2. application/tamp-status-response ..........................78
B.3. application/tamp-update ...................................79
B.4. application/tamp-update-confirm ...........................80
B.5. application/tamp-apex-update ..............................81
B.6. application/tamp-apex-update-confirm ......................82
B.7. application/tamp-community-update .........................83
B.8. application/tamp-community-update-confirm .................84
B.9. application/tamp-sequence-adjust ..........................85
B.10. application/tamp-sequence-adjust-confirm ..................86
B.11. application/tamp-error ....................................87
Appendix C. TAMP over HTTP .......................................88
C.1. TAMP Status Query Message .................................89
C.2. TAMP Status Response Message ..............................89
C.3. Trust Anchor Update Message ...............................89
C.4. Trust Anchor Update Confirm Message .......................89
C.5. Apex Trust Anchor Update Message ..........................89
C.6. Apex Trust Anchor Update Confirm Message ..................90
C.7. Community Update Message ..................................90
C.8. Community Update Confirm Message ..........................90
C.9. Sequence Number Adjust Message ............................90
C.10. Sequence Number Adjust Confirm Message ....................90
C.11. TAMP Error Message ........................................91

1. Introduction

This document describes the Trust Anchor Management Protocol (TAMP).
TAMP may be used to manage the trust anchors and community
identifiers in any device that uses digital signatures; however, this
specification was written with the requirements of cryptographic
modules in mind. For example, TAMP can support signed firmware
packages [RFC4108], where the trust anchor public key can be used to
validate digital signatures on firmware packages or validate the
X.509 certification path [RFC5280][X.509] of the firmware package
signer.

Most TAMP messages are digitally signed to provide integrity
protection and data origin authentication. Both signed and unsigned
TAMP messages employ the Cryptographic Message Syntax (CMS)
[RFC5652]. The CMS is a data protection encapsulation syntax that
makes use of ASN.1 [X.680].






Housley, et al. Standards Track [Page 4]

RFC 5934 TAMP August 2010


This specification does not provide for confidentiality of TAMP
messages. If confidentiality is required, then the communications
environment that is used to transfer TAMP messages must provide it.
This specification is intended to satisfy the protocol-related
requirements expressed in "Trust Anchor Management Requirements"
[TA-MGMT-REQS] and uses vocabulary from that document.

TAMP messages may be exchanged in real time over a network, such as
via HTTP as described in Appendix A, or may be stored and transferred
using other means. TAMP exchanges consist of a request message that
includes instructions for a trust anchor store and, optionally, a
corresponding response message that reports the result of carrying
out the instructions in the request. Response messages need not be
propagated in all cases. For example, a GPS receiver may be unable
to transmit a response and may instead use an attached display to
indicate the results of processing a TAMP request.

1.1. Terminology

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].

1.2. Trust Anchors

TAMP manages trust anchors. A trust anchor contains a public key
that is used to validate digital signatures. TAMP recognizes three
formats for representing trust anchor information: Certificate
[RFC5280], TBSCertificate [RFC5280], and TrustAnchorInfo [RFC5914].

All trust anchors are distinguished by the public key, and all trust
anchors consist of the following components:

o A public key signature algorithm identifier and associated public
key, which MAY include parameters

o A public key identifier

Other information may appear in a trust anchor, including
certification path processing controls and a human readable name.

TAMP recognizes three types of trust anchors based on functionality:
apex trust anchors, management trust anchors, and identity trust
anchors.

In addition to the information described above, apex trust anchors
and management trust anchors that sign TAMP messages have an
associated sequence number that is used for replay detection.



Housley, et al. Standards Track [Page 5]

RFC 5934 TAMP August 2010


The public key is used to name a trust anchor, and the public key
identifier is used to identify the trust anchor as a signer of a
particular object, such as a SignedData object or a public key
certificate. This public key identifier can be stored with the trust
anchor, or in most public key identifier assignment methods, it can
be computed from the public key whenever needed.

A trust anchor public key can be used in two different ways to
support digital signature validation. In the first approach, the
trust anchor public key is used directly to validate the digital
signature. In the second approach, the trust anchor public key is
used to validate an X.509 certification path, and then the subject
public key in the final certificate in the certification path is used
to validate the digital signature. When the second approach is
employed, the certified public key may be used for things other than
digital signature validation; the other possible actions are
constrained by the key usage certificate extension.

TAMP implementations MUST support validation of TAMP messages that
are directly validated using a trust anchor. Support for TAMP
messages validated using an X.509 certificate validated using a trust
anchor, or using longer certification paths, is OPTIONAL. The CMS
provides a location to carry X.509 certificates, and this facility
can be used to transfer certificates to aid in the construction of
the certification path.

1.2.1. Apex Trust Anchors

Within the context of a single trust anchor store, one trust anchor
is superior to all others. This trust anchor is referred to as the
apex trust anchor. This trust anchor represents the ultimate
authority over the trust anchor store. Much of this authority can be
delegated to other trust anchors.

The apex trust anchor private key is expected to be controlled by an
entity with information assurance responsibility for the trust anchor
store. The apex trust anchor is by definition unconstrained and
therefore does not have explicit authorization information associated
with it.

Due to the special nature of the apex trust anchor, TAMP includes
separate facilities to change it. In particular, TAMP includes a
facility to securely replace the apex trust anchor. This action
might be taken for one or more of the following reasons:

o The crypto period for the apex trust anchor public/private key
pair has come to an end




Housley, et al. Standards Track [Page 6]

RFC 5934 TAMP August 2010


o The apex trust anchor private key is no longer available

o The apex trust anchor public/private key pair needs to be revoked

o The authority has decided to use a different digital signature
algorithm or the same digital signature algorithm with different
parameters, such as a different elliptic curve

o The authority has decided to use a different key size

o The authority has decided to transfer control to another authority

To accommodate these requirements, the apex trust anchor MAY include
two public keys. Whenever the apex trust anchor is updated, both
public keys will be replaced. The first public key, called the
operational public key, is used in the same manner as other trust
anchors. Any type of TAMP message, including an Apex Trust Anchor
Update message, can be validated with the operational public key.
The second public key, called the contingency public key, can only be
used to update the apex trust anchor. The contingency private key
SHOULD be used at only one point in time; it is used only to sign an
Apex Trust Anchor Update message that results in its own replacement
(as well as the replacement of the operational public key). The
contingency public key is distributed in encrypted form. When the
contingency public key is used to validate an Apex Trust Anchor
Update message, the symmetric key needed to decrypt the contingency
public key is provided as part of the signed Apex Trust Anchor Update
message that is to be verified with the contingency public key.

1.2.2. Management Trust Anchors

Management trust anchors are used in the management of cryptographic
modules. For example, the TAMP messages specified in this document
are validated to a management trust anchor. Likewise, a signed
firmware package as specified in [RFC4108] is validated to a
management trust anchor.

1.2.3. Identity Trust Anchors

Identity trust anchors are used to validate certification paths, and
they represent the trust anchor for a public key infrastructure.
They are most often used in the validation of certificates associated
with non-management applications.








Housley, et al. Standards Track [Page 7]

RFC 5934 TAMP August 2010


1.3. Architectural Elements

TAMP does not assume any particular architecture. However, TAMP
REQUIRES the following architectural elements: a cryptographic
module, a trust anchor store, TAMP protocol processing, and other
application-specific protocol processing.

A globally unique algorithm identifier MUST be assigned for each one-
way hash function, digital signature generation/validation algorithm,
and symmetric key unwrapping algorithm that is implemented. To
support CMS, an object identifier (OID) is assigned to name a one-way
hash function, and another OID is assigned to name each combination
of a one-way hash function when used with a digital signature
algorithm. Similarly, certificates associate OIDs assigned to public
key algorithms with subject public keys, and certificates make use of
an OID that names both the one-way hash function and the digital
signature algorithm for the certificate issuer digital signature.
[RFC3279], [RFC3370], [RFC5753], and [RFC5754] provide OIDs for a
number of commonly used algorithms; however, OIDs may be defined in
later or different specifications.

1.3.1. Cryptographic Module

The cryptographic module MUST include the following capabilities:

o The cryptographic module SHOULD support the secure storage of a
digital signature private key to sign TAMP responses and either a
certificate containing the associated public key or a certificate
designator. In the latter case, the certificate is stored
elsewhere but is available to parties that need to validate
cryptographic module digital signatures. The designator is a
public key identifier.

o The cryptographic module MUST support at least one one-way hash
function, one digital signature validation algorithm, one digital
signature generation algorithm, and, if contingency keys are
supported, one symmetric key unwrapping algorithm. If only one
one-way hash function is present, it MUST be consistent with the
digital signature validation and digital signature generation
algorithms. If only one digital signature validation algorithm is
present, it MUST be consistent with the apex trust anchor
operational public key. If only one digital signature generation
algorithm is present, it MUST be consistent with the cryptographic
module digital signature private key. These algorithms MUST be
available for processing TAMP messages, including the content
types defined in [RFC5652], and for validation of X.509





Housley, et al. Standards Track [Page 8]

RFC 5934 TAMP August 2010


certification paths. As with similar specifications, such as
RFC 5280, this specification does not mandate support for any
cryptographic algorithms. However, algorithm requirements may be
imposed by specifications that use trust anchors managed via TAMP.

1.3.2. Trust Anchor Store

The trust anchor store MUST include the following capabilities:

o Each trust anchor store MUST have a unique name. For example, a
cryptographic module containing a single trust anchor store may be
identified by a unique serial number with respect to other modules
within the same family where the family is represented as an ASN.1
object identifier (OID) and the unique serial number is
represented as a string of octets. Other means of establishing a
unique name are also possible.

o Each trust anchor store SHOULD have the capability to securely
store one or more community identifiers. The community identifier
is an OID, and it identifies a collection of cryptographic modules
that can be the target of a single TAMP message or the intended
recipients for a particular management message.

o The trust anchor store SHOULD support the use of an apex trust
anchor. If apex support is provided, the trust anchor store MUST
support the secure storage of exactly one apex trust anchor. The
trust anchor store SHOULD support the secure storage of at least
one additional trust anchor. Each trust anchor MUST contain a
unique public key. A public key MUST NOT appear more than once in
a trust anchor store.

o The trust anchor store MUST have the capability to securely store
a sequence number for each trust anchor authorized to generate
TAMP messages and be able to report the sequence number along with
the key identifier of the trust anchor.

1.3.3. TAMP Processing Dependencies

TAMP processing MUST include the following capabilities:

o TAMP processing MUST have a means of locating an appropriate trust
anchor. Two mechanisms are available. The first mechanism is
based on the public key identifier for digital signature
verification, and the second mechanism is based on the trust
anchor X.500 distinguished name and other X.509 certification path
controls for certificate path discovery and validation. The first
mechanism MUST be supported, but the second mechanism MAY be
supported.



Housley, et al. Standards Track [Page 9]

RFC 5934 TAMP August 2010


o TAMP processing MUST be able to invoke the digital signature
validation algorithm using the public key held in secure storage
for trust anchors.

o TAMP processing MUST have read and write access to secure storage
for sequence numbers associated with each TAMP message signer as
described in Section 6.

o TAMP processing MUST have read and write access to secure storage
for trust anchors in order to update them. Update operations
include adding trust anchors, removing trust anchors, and
modifying trust anchors. Application-specific constraints MUST be
securely stored with each management trust anchor as described in
Section 1.3.4.

o TAMP processing MUST have read access to secure storage for the
community membership list, if any, to determine whether a targeted
message ought to be accepted.

o To implement the OPTIONAL community identifier update feature,
TAMP processing MUST have read and write access to secure storage
for the community membership list.

o To generate signed confirmation messages, TAMP processing MUST be
able to invoke the digital signature generation algorithm using
the cryptographic module digital signature private key, and it
MUST have read access to the cryptographic module certificate or
its designator. TAMP uses X.509 certificates [RFC5280].

o The TAMP processing MUST have read access to the trust anchor
store unique name.

1.3.4. Application-Specific Protocol Processing

The apex trust anchor and management trust anchors managed with TAMP
can be used by the TAMP application. Other management applications
MAY make use of all three types of trust anchors, but non-management
applications SHOULD only make use of identity trust anchors.
Applications MUST ensure that usage of a trust anchor is consistent
with any constraints associated with the trust anchor. For example,
if name constraints are associated with a trust anchor, certification
paths that start with the trust anchor and contain certificates with
names that violate the name constraints MUST be rejected.

The application-specific protocol processing MUST be provided with
the following services:





Housley, et al. Standards Track [Page 10]

RFC 5934 TAMP August 2010


o The application-specific protocol processing MUST have a means of
locating an appropriate trust anchor. Two mechanisms are
available to applications. The first mechanism is based on the
public key identifier for digital signature verification, and the
second mechanism is based on the trust anchor X.500 distinguished
name and other X.509 certification path controls for certificate
path discovery and validation.

o The application-specific protocol processing MUST be able to
invoke the digital signature validation algorithm using the public
key held in secure storage for trust anchors.

o The application-specific protocol processing MUST have read access
to data associated with trust anchors to ensure that constraints
can be enforced appropriately. For example, an application MUST
have read access to any name constraints associated with a TA to
ensure that certification paths terminated by that TA do not
include certificates issued to entities outside the TA manager-
designated namespace.

o The application-specific protocol processing MUST have read access
to secure storage for the community membership list, if any, to
determine whether a targeted message ought to be accepted.

o If the application-specific protocol requires digital signatures
on confirmation messages or receipts, then the application-
specific protocol processing MUST be able to invoke the digital
signature generation algorithm with the cryptographic module
digital signature private key and its associated certificate or
certificate designator. Digital signature generation MUST be
controlled in a manner that ensures that the content type of
signed confirmation messages or receipts is appropriate for the
application-specific protocol processing.

o The application-specific protocol processing MUST have read access
to the trust anchor store unique name.

1.4. ASN.1 Encoding

The CMS uses Abstract Syntax Notation One (ASN.1) [X.680]. ASN.1 is
a formal notation used for describing data protocols, regardless of
the programming language used by the implementation. Encoding rules
describe how the values defined in ASN.1 will be represented for
transmission. The Basic Encoding Rules (BER) [X.690] are the most
widely employed rule set, but they offer more than one way to
represent data structures. For example, definite-length encoding and
indefinite-length encoding are supported. This flexibility is not
desirable when digital signatures are used. As a result, the



Housley, et al. Standards Track [Page 11]

RFC 5934 TAMP August 2010


Distinguished Encoding Rules (DER) [X.690] were invented. DER is a
subset of BER that ensures a single way to represent a given value.
For example, DER always employs definite-length encoding.

Digitally signed structures MUST be encoded with DER. In other
specifications, structures that are not digitally signed do not
require DER, but in this specification, DER is REQUIRED for all
structures. By always using DER, the TAMP processor will have fewer
options to implement.

ASN.1 is used throughout the text of this document for illustrative
purposes. The authoritative source of ASN.1 for the structures
defined in this document is Appendix A.

2. Cryptographic Message Syntax Profile

TAMP makes use of signed and unsigned messages. The Cryptographic
Message Syntax (CMS) is used in both cases. A digital signature is
used to protect the message from undetected modification and provide
data origin authentication. TAMP makes no general provision for
encryption of content.

CMS is used to construct a signed TAMP message. The CMS ContentInfo
content type MUST always be present. For signed messages,
ContentInfo MUST encapsulate the CMS SignedData content type; for
unsigned messages, ContentInfo MUST encapsulate the TAMP message
directly. The CMS SignedData content type MUST encapsulate the TAMP
message. A unique content type identifier identifies the particular
type of TAMP message. The CMS encapsulation of a signed TAMP message
is summarized by:

ContentInfo {