Trust Anchor Management Protocol (TAMP)
RFC 5934

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 -)
No email
send info
Question for Apps ADs ... does the HTTP usage need to say anything about caches.

Alexey Melnikov (was Discuss) No Objection

Comment (2010-03-22)
No email
send info
5)  Content-Hints Attribute

   o  contentType is mandatory.  This field indicates the content type
      that will be discovered when CMS protection content types are

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:

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

   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.

(Dan Romascanu) (was Discuss) No Objection

(Robert Sparks) No Objection

Magnus Westerlund No Objection

(Russ Housley) Recuse