Technical Summary
This document describes a transport independent protocol for the
management of trust anchors and community identifiers stored in a trust
anchor store. (Community identifiers are used to associate a cryptographic
module with one or more groups to which TAMP message may be sent in a
multicast fashion.) The application context that motivates of TAMP is that
of a cryptographic modules that is remotely managed by an administrative
entity (as opposed to locally managed by the user of the module). The
protocol makes use of the Cryptographic Message Syntax (CMS), and a
digital signature is used to provide integrity and data origin
authentication. TAMP can operate over a realtime connection, or via staged
delivery mechanisms. The protocol can be used to manage trust anchor
stores containing trust anchors represented as a Certificate, a
TBSCertificate or as TrustAnchorInfo objects.
Working Group Summary
This document entered the working group following the Trust Anchor
Management
BOF. That BOF considered the issue of trust anchor management very
broadly. It was decided that a more narrowly focused effort, emphasizing
X.509 certificates would be an appropriate first step, thus this work
became an activity for the PKIX WG. Initially, the document also included
material now found in the Trust Anchor Format (TAF) document. The working
group favored separate documents for protocol specification and format
specification. This I-D contains the former. This draft was not
particularly controversial, but a number of significant changes resulted
from working group discussion, including specification of how to use the
protocol over HTTP.
One minor point of controversy re-emerged during IETF Last Call.
Some implementations (especially browsers) consider key usage extensions
in a trust anchor as an indication that all certificates in a path must
include that extension and value. This is a non-standard interpretation,
and is not directly supported by the current specification. However, it
could be accommodated by specifying an extension for use with the current
document. This issue was raised in the wg, but the supporters could not
build consensus in the wg that this was a core feature. It is suggested
that
these extensions be addressed in future work.
Document Quality
The document is reasonably well-written and clear. An open source
implementation is being developed. The most common format used to
represent a trust anchor today is a self-signed certificate and this
format is accommodated in this document.
Personnel
Steve Kent is the Document Shepherd. Tim Polk is the Responsible Area
Director.
RFC Editor Note
(1) In Appendix B, please make the following substitution:
OLD
Eleven media type registrations are provided in this appendix. As
noted in Section 2, in all cases TAMP messages are encapsulated
within ContentInfo structures. Signed messages are additionally
encapsulated within a SignedData structure.
NEW
Eleven media type registrations are provided in this appendix,
one for each content type defined in this specification. As
noted in Section 2, in all cases TAMP messages are encapsulated
within ContentInfo structures. Signed messages are additionally
encapsulated within a SignedData structure.
(2) In Appendix B.1 though B.11, please delete the to: and
subject: lines in each registration
(3) In Appendix B.1 though B.11, please make the following �global�
changes
s/Encoding considerations: Binary/Encoding considerations: binary/
s/Intended usage: COMMON/Intended usage: LIMITED USE/