Trust Anchor Management Protocol (TAMP)
RFC 5934
Yes
(Tim Polk)
No Objection
(Adrian Farrel)
(Dan Romascanu)
(Jari Arkko)
(Lisa Dusseault)
(Magnus Westerlund)
(Robert Sparks)
(Ron Bonica)
(Ross Callon)
Recuse
(Russ Housley)
Note: This ballot was opened for revision 08 and is now closed.
Tim Polk Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Alexey Melnikov Former IESG member
(was Discuss)
No Objection
No Objection
(2010-03-22)
Unknown
5) 2.2.3.3. 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 2.2.3.4: 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.
Cullen Jennings Former IESG member
No Objection
No Objection
(2010-03-03)
Unknown
Question for Apps ADs ... does the HTTP usage need to say anything about caches.
Dan Romascanu Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
Recuse
Recuse
()
Unknown