Skip to main content

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