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