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/
_______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
