Trust Anchor Management Protocol (TAMP)
Note: This ballot was opened for revision 08 and is now closed.
(Tim Polk) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Lisa Dusseault) No Objection
(Adrian Farrel) (was Discuss) No Objection
(Cullen Jennings) No Objection
Comment (2010-03-03 for -)
Question for Apps ADs ... does the HTTP usage need to say anything about caches.
Alexey Melnikov (was Discuss) No Objection
5) 184.108.40.206. Content-Hints Attribute o contentType is mandatory. This field indicates the content type that will be discovered when CMS protection content types are removed. I think it would be good to add here that if the content-type discovered after removing encapsulation doesn't match this value, then the message MUST be discarded. -------------------------- A former DISCUSS item # 16: In Section 5: o notAuthorized is used to indicate one of two possible error situations. In one case the sid within SignerInfo leads to an installed trust anchor, but that trust anchor is not an authorized signer for the received TAMP message content type. Identity trust anchors are not authorized signers for any of the TAMP message content types. Is there any way in TAMP to discover or manage who is authorized to perform an action? (Is this partially covered by section 7?) Carl: TAMP does not define an authorization mechanism. One authorization mechanism has been defined (CMS Content Constraints). When this mechanism is used the results of a status query message will indicate who is authorized. -------------------------- The following [former] DISCUSSes are listed here with some explanation of why they are not going to be addressed in this document: 5) I think the following Informative reference should be Normative: [RFC4049] Housley, R., "BinaryTime: An Alternate Format for Representing Date and Time in ASN.1", RFC 4049, April 2005. due to the following text in Section 220.127.116.11: The TAMP message originator MAY include a binary-signing-time attribute, specifying the time at which the digital signature was applied to the TAMP message. The binary-signing-time attribute is defined in [RFC4049]. Russ (rephrased): the reference is Experimental, would prefer not to do another IETF LC for the downref.