Protocol Action: 'Trust Anchor Management Protocol (TAMP)' to Proposed Standard

[The IESG <[e-mail]>]

The IESG has approved the following document:

- 'Trust Anchor Management Protocol (TAMP) '
   <draft-ietf-pkix-tamp-08.txt> as a Proposed Standard


This document is the product of the Public-Key Infrastructure (X.509) Working Group. 

The IESG contact persons are Tim Polk and Sean Turner.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-tamp-08.txt

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/