Trust Anchor Management Protocol (TAMP)
RFC 5934

[Ballot comment]
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.

[Ballot discuss]
Updated, issues starting from # 14 are new (and the COMMENT # 8 is new as well):

18) Were MIME media types submitted for review to the ietf-types@ mailing list?

[Ballot comment]
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 # 8:
4.1.  TAMP Status Query

  If the digital signature on the TAMP Status Query message is valid,
  sequence number checking is successful, the signer is authorized, and
  the trust anchor store is an intended recipient of the TAMP message,
  then a TAMP Status Response message SHOULD be returned.  If a TAMP
  Status Response message is not returned, then a TAMP Error message
  SHOULD be returned.

Showing an example or two of why you are using SHOULDs here instead of MUSTs would be helpful.


A former DISCUSS item # 13:
4.3.1.  Trust Anchor List

  [I-D.ietf-pkix-ta-format] defines the TrustAnchorList structure to

You lost me, I can't find where in the document the TrustAnchorList is used. Can you please clarify?

<>

  convey a list of trust anchors.  TAMP implementations MAY process
  TrustAnchorList objects as TAMPUpdate objects with terse set to
  terse, msgRef set to allModules (with a suitable sequence number) and
  all elements within the list contained within the add field.


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.

[Ballot discuss]
Updated, issues starting from # 14 are new (and the COMMENT # 8 is new as well):

4)
2.2.3.3.  Content-Hints Attribute

  o  contentDescription is OPTIONAL.  The TAMP message signer MAY
      provide a brief description of the purpose of the TAMP message.
      The text is intended for human consumption, not machine
      processing.  The text is encoded in UTF-8 [RFC3629], which
      accommodates most of the world's writing systems.

<>

Russ: Section 2.9 of RFC 2634 defines the content-hints attribute, and it does not include a language tag.  It is being used here in the same manner
that it is used in S/MIME.  It seem too late to bring on new
requirements.  That said, I'm pleased to work with you to define a new
attribute that includes a language tag that can be used in all of the
places that content-hints is used today.  I do not think we should block
this document for it.

I wrote :The easiest way to address this is to recommend use of RFC 2482. Make this refence informative (as the document is Informational). For example add something like this to the end of the paragraph quoted above:

The default language tag [RFC5646] for the contentDescription field is
"en" (English). Alternative language tags SHOULD be specified using
the procedure described in [RFC2482]. The contentDescription field MAY include human readable description in multiplelanguages by prepending description in each language with the language tag as specified in [RFC2482] and concatenating descriptions into a single string.

RFC 5646 should be a Normative reference.

17)
4.11.  TAMP Error

    TAMPError ::= SEQUENCE {
      version  [0] TAMPVersion DEFAULT v2,
      msgType  OBJECT IDENTIFIER,

What happens if the msgType couldn't be parsed?
No TAMP Error message can be generated?

Maybe it would be better to make this field OPTIONAL.

18) Were MIME media types submitted for review to the ietf-types@ mailing list?

[Ballot comment]
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 # 8:
4.1.  TAMP Status Query

  If the digital signature on the TAMP Status Query message is valid,
  sequence number checking is successful, the signer is authorized, and
  the trust anchor store is an intended recipient of the TAMP message,
  then a TAMP Status Response message SHOULD be returned.  If a TAMP
  Status Response message is not returned, then a TAMP Error message
  SHOULD be returned.

Showing an example or two of why you are using SHOULDs here instead of MUSTs would be helpful.


A former DISCUSS item # 13:
4.3.1.  Trust Anchor List

  [I-D.ietf-pkix-ta-format] defines the TrustAnchorList structure to

You lost me, I can't find where in the document the TrustAnchorList is used. Can you please clarify?

<>

  convey a list of trust anchors.  TAMP implementations MAY process
  TrustAnchorList objects as TAMPUpdate objects with terse set to
  terse, msgRef set to allModules (with a suitable sequence number) and
  all elements within the list contained within the add field.


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.

[Ballot discuss]
Updated, issues starting from # 14 are new (and the COMMENT # 8 is new as well):

4)
2.2.3.3.  Content-Hints Attribute

  o  contentDescription is OPTIONAL.  The TAMP message signer MAY
      provide a brief description of the purpose of the TAMP message.
      The text is intended for human consumption, not machine
      processing.  The text is encoded in UTF-8 [RFC3629], which
      accommodates most of the world's writing systems.

<>

Russ: Section 2.9 of RFC 2634 defines the content-hints attribute, and it does not include a language tag.  It is being used here in the same manner
that it is used in S/MIME.  It seem too late to bring on new
requirements.  That said, I'm pleased to work with you to define a new
attribute that includes a language tag that can be used in all of the
places that content-hints is used today.  I do not think we should block
this document for it.

I wrote :The easiest way to address this is to recommend use of RFC 2482. Make this refence informative (as the document is Informational). For example add something like this to the end of the paragraph quoted above:

The default language tag [RFC5646] for the contentDescription field is
"en" (English). Alternative language tags SHOULD be specified using
the procedure described in [RFC2482]. The contentDescription field MAY include human readable description in multiplelanguages by prepending description in each language with the language tag as specified in [RFC2482] and concatenating descriptions into a single string.

RFC 5646 should be a Normative reference.

17)
4.11.  TAMP Error

    TAMPError ::= SEQUENCE {
      version  [0] TAMPVersion DEFAULT v2,
      msgType  OBJECT IDENTIFIER,

What happens if the msgType couldn't be parsed?
No TAMP Error message can be generated?

Maybe it would be better to make this field OPTIONAL.

18) Were MIME media types submitted for review to the ietf-types@ mailing list?

[Ballot comment]
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 # 8:
4.1.  TAMP Status Query

  If the digital signature on the TAMP Status Query message is valid,
  sequence number checking is successful, the signer is authorized, and
  the trust anchor store is an intended recipient of the TAMP message,
  then a TAMP Status Response message SHOULD be returned.  If a TAMP
  Status Response message is not returned, then a TAMP Error message
  SHOULD be returned.

Showing an example or two of why you are using SHOULDs here instead of MUSTs would be helpful.


A former DISCUSS item # 13:
4.3.1.  Trust Anchor List

  [I-D.ietf-pkix-ta-format] defines the TrustAnchorList structure to

You lost me, I can't find where in the document the TrustAnchorList is used. Can you please clarify?

<>

  convey a list of trust anchors.  TAMP implementations MAY process
  TrustAnchorList objects as TAMPUpdate objects with terse set to
  terse, msgRef set to allModules (with a suitable sequence number) and
  all elements within the list contained within the add field.


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.

[Ballot discuss]
Updated, issues starting from # 14 are new (and the COMMENT # 8 is new as well):

4)
2.2.3.3.  Content-Hints Attribute

  o  contentDescription is OPTIONAL.  The TAMP message signer MAY
      provide a brief description of the purpose of the TAMP message.
      The text is intended for human consumption, not machine
      processing.  The text is encoded in UTF-8 [RFC3629], which
      accommodates most of the world's writing systems.

<>

Russ: Section 2.9 of RFC 2634 defines the content-hints attribute, and it does not include a language tag.  It is being used here in the same manner
that it is used in S/MIME.  It seem too late to bring on new
requirements.  That said, I'm pleased to work with you to define a new
attribute that includes a language tag that can be used in all of the
places that content-hints is used today.  I do not think we should block
this document for it.

I wrote :The easiest way to address this is to recommend use of RFC 2482. Make this refence informative (as the document is Informational). For example add something like this to the end of the paragraph quoted above:

The default language tag [RFC5646] for the contentDescription field is
"en" (English). Alternative language tags SHOULD be specified using
the procedure described in [RFC2482]. The contentDescription field MAY include human readable description in multiplelanguages by prepending description in each language with the language tag as specified in [RFC2482] and concatenating descriptions into a single string.

RFC 5646 should be a Normative reference.

12)
4.2.  TAMP Status Query Response

  o  tampSeqNumbers is OPTIONAL.  When present, it is used to indicate
      the currently held sequence number for each trust anchor
      authorized to sign TAMP messages.  The keyId field identifies the
      trust anchor and the seqNumber field provides the current sequence
      number associated with the trust anchor.

I am confused here. How can this be converted to
    TAMPMsgRef ::= SEQUENCE {
      target  TargetIdentifier,
      seqNum  SeqNumber }
?

17)
4.11.  TAMP Error

    TAMPError ::= SEQUENCE {
      version  [0] TAMPVersion DEFAULT v2,
      msgType  OBJECT IDENTIFIER,

What happens if the msgType couldn't be parsed?
No TAMP Error message can be generated?

Maybe it would be better to make this field OPTIONAL.

18) Were MIME media types submitted for review to the ietf-types@ mailing list?

[Ballot comment]
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 # 8:
4.1.  TAMP Status Query

  If the digital signature on the TAMP Status Query message is valid,
  sequence number checking is successful, the signer is authorized, and
  the trust anchor store is an intended recipient of the TAMP message,
  then a TAMP Status Response message SHOULD be returned.  If a TAMP
  Status Response message is not returned, then a TAMP Error message
  SHOULD be returned.

Showing an example or two of why you are using SHOULDs here instead of MUSTs would be helpful.


A former DISCUSS item # 13:
4.3.1.  Trust Anchor List

  [I-D.ietf-pkix-ta-format] defines the TrustAnchorList structure to

You lost me, I can't find where in the document the TrustAnchorList is used. Can you please clarify?

<>

  convey a list of trust anchors.  TAMP implementations MAY process
  TrustAnchorList objects as TAMPUpdate objects with terse set to
  terse, msgRef set to allModules (with a suitable sequence number) and
  all elements within the list contained within the add field.


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.

[Ballot discuss]
Updated, issues starting from # 14 are new (and the COMMENT # 8 is new as well):

4)
2.2.3.3.  Content-Hints Attribute

  o  contentDescription is OPTIONAL.  The TAMP message signer MAY
      provide a brief description of the purpose of the TAMP message.
      The text is intended for human consumption, not machine
      processing.  The text is encoded in UTF-8 [RFC3629], which
      accommodates most of the world's writing systems.

<>

Russ: Section 2.9 of RFC 2634 defines the content-hints attribute, and it does not include a language tag.  It is being used here in the same manner
that it is used in S/MIME.  It seem too late to bring on new
requirements.  That said, I'm pleased to work with you to define a new
attribute that includes a language tag that can be used in all of the
places that content-hints is used today.  I do not think we should block
this document for it.

12)
4.2.  TAMP Status Query Response

  o  tampSeqNumbers is OPTIONAL.  When present, it is used to indicate
      the currently held sequence number for each trust anchor
      authorized to sign TAMP messages.  The keyId field identifies the
      trust anchor and the seqNumber field provides the current sequence
      number associated with the trust anchor.

I am confused here. How can this be converted to
    TAMPMsgRef ::= SEQUENCE {
      target  TargetIdentifier,
      seqNum  SeqNumber }
?

17)
4.11.  TAMP Error

    TAMPError ::= SEQUENCE {
      version  [0] TAMPVersion DEFAULT v2,
      msgType  OBJECT IDENTIFIER,

What happens if the msgType couldn't be parsed?
No TAMP Error message can be generated?

Maybe it would be better to make this field OPTIONAL.

18) Were MIME media types submitted for review to the ietf-types@ mailing list?

20) HTTP mapping seems to be underspecified. For example it needs to discuss cache control behavior for responses.

<>

[Ballot comment]
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.

[Ballot discuss]
Updated, issues starting from # 14 are new (and the COMMENT # 8 is new as well):

4)
2.2.3.3.  Content-Hints Attribute

  o  contentDescription is OPTIONAL.  The TAMP message signer MAY
      provide a brief description of the purpose of the TAMP message.
      The text is intended for human consumption, not machine
      processing.  The text is encoded in UTF-8 [RFC3629], which
      accommodates most of the world's writing systems.

<>

Russ: Section 2.9 of RFC 2634 defines the content-hints attribute, and it does not include a language tag.  It is being used here in the same manner
that it is used in S/MIME.  It seem too late to bring on new
requirements.  That said, I'm pleased to work with you to define a new
attribute that includes a language tag that can be used in all of the
places that content-hints is used today.  I do not think we should block
this document for it.

8)
4.1.  TAMP Status Query

  If the digital signature on the TAMP Status Query message is valid,
  sequence number checking is successful, the signer is authorized, and
  the trust anchor store is an intended recipient of the TAMP message,
  then a TAMP Status Response message SHOULD be returned.  If a TAMP
  Status Response message is not returned, then a TAMP Error message
  SHOULD be returned.

It looks like the 2 SHOULDs allow for no message to be returned.
I think this would affect interoperability.

(The same issue for all other commands.)

<>

12)
4.2.  TAMP Status Query Response

  o  tampSeqNumbers is OPTIONAL.  When present, it is used to indicate
      the currently held sequence number for each trust anchor
      authorized to sign TAMP messages.  The keyId field identifies the
      trust anchor and the seqNumber field provides the current sequence
      number associated with the trust anchor.

I am confused here. How can this be converted to
    TAMPMsgRef ::= SEQUENCE {
      target  TargetIdentifier,
      seqNum  SeqNumber }
?

13)
4.3.1.  Trust Anchor List

  [I-D.ietf-pkix-ta-format] defines the TrustAnchorList structure to

You lost me, I can't find where in the document the TrustAnchorList is used. Can you please clarify?

<>

  convey a list of trust anchors.  TAMP implementations MAY process
  TrustAnchorList objects as TAMPUpdate objects with terse set to
  terse, msgRef set to allModules (with a suitable sequence number) and
  all elements within the list contained within the add field.

17)
4.11.  TAMP Error

    TAMPError ::= SEQUENCE {
      version  [0] TAMPVersion DEFAULT v2,
      msgType  OBJECT IDENTIFIER,

What happens if the msgType couldn't be parsed?
No TAMP Error message can be generated?

Maybe it would be better to make this field OPTIONAL.

18) Were MIME media types submitted for review to the ietf-types@ mailing list?

20) HTTP mapping seems to be underspecified. For example it needs to discuss cache control behavior for responses.

<>

[Ballot comment]
1)
1.3.1.  Cryptographic Module

      If only one
      one-way hash function is present, it MUST be consistent with the
      digital signature validation and digital signature generation
      algorithms.  If only one digital signature validation algorithm is
      present, it must be consistent with the apex trust anchor
      operational public key.  If only one digital signature generation
      algorithm is present, it must be consistent with the cryptographic
      module digital signature private key.

Change a couple of "must"s to "MUST"s?

2)
1.3.3.  TAMP Processing Dependencies

  TAMP processing MUST include the following capabilities:

  o  TAMP processing MUST have a means of locating an appropriate trust
      anchor.  Two mechanisms are available.  The first mechanism is
      based on the public key identifier for digital signature
      verification, and the second mechanism is based on the trust
      anchor X.500 distinguished name and other X.509 certification path
      controls for certificate path discovery and validation.  The first
      mechanism MUST be supported, but the second mechanism can also be
      used.

Does this mean that the second mechanism is OPTIONAL? I don't think
the text is very clear.

3). Also in 1.3.3:

  o  TAMP processing MUST have read and write access to secure storage
      for trust anchors in order to update them.  Update operations
      include adding trust anchors, removing trust anchors, and
      modifying trust anchors.  Application-specific access controls
      MUST be securely stored with each management trust anchor as
      described in Section 1.3.4.

I am not sure. Does 1.3.4 cover this?

4)
1.3.4.  Application-Specific Protocol Processing

  The application-specific protocol processing MUST be provided the
  following services:

It looks like a preposition is missing here.

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.

6)
4.  Trust Anchor Management Protocol Messages

  TAMP specifies eleven message types.  The following provides the
  content type identifier for each TAMP message type, and it indicates
  whether a digital signature is REQUIRED.

This doesn't look like the right use for an RFC 2119 keyword.

7) In Section 4.3:

  o  change is used to update the information associated with an
      existing management or identity trust anchor in the trust anchor
      store.
    [...]
      Attempts to change a trust anchor added as a TBSCertificate using
      a TrustAnchorChangeInfo MUST fail.  Attempts to change a trust
      anchor added as a TrustAnchorInfo using a TBSCertificateChangeInfo
      MUST fail.

As you already listed appropriate error codes for some other failures,
it would be a good idea to list the corresponding error code(s) here as well.

8). Security consideration fields for registered MIME media types are not well written. For example, section B.1 says:

  Security considerations: Carries a request for status information.

So what? What needs to be protected? What are the risks from using this media type to applications? Etc.


A former DISCUSS item #14:
In Section 5:

Authors replied that the list of error codes is not extensible in ASN.1. I would prefer if this is stated explicitly.

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:

2)

1.3.1.  Cryptographic Module

  o  The cryptographic module MUST support at least one one-way hash
      function, one digital signature validation algorithm, one digital
      signature generation algorithm, and, if contingency keys are
      supported, one symmetric key unwrapping algorithm.

Is there a mandatory to implement algorithm?

Russ: PKIX has never specified mandatory to implement algorithms.  The reason is that other protocols make use of certificates, and these other
protocols often dictate algorithm requirements.  For example, S/MIME
does have mandatory to implement algorithms, and S/MIME depends on PKIX
certificate specifications.  The same convention is being followed here.

[Ballot discuss]
Updated, issues starting from # 14 are new (and the COMMENT # 8 is new as well):

1)
1.3.  Architectural Elements

  A globally unique algorithm identifier MUST be assigned for each one-
  way hash function, digital signature generation/validation algorithm,
  and symmetric key unwrapping algorithm that is implemented.  To
  support CMS, an object identifier (OID) is assigned to name a one-way
  hash function, and another OID is assigned to name each combination
  of a one-way hash function when used with a digital signature
  algorithm.  Similarly, certificates associate OIDs assigned to public
  key algorithms with subject public keys, and certificates make use of
  an OID that names both the one-way hash function and the digital
  signature algorithm for the certificate issuer digital signature.

Is there any particular IANA registry to choose OIDs from?
This might affect interoperability.

3)
1.3.2.  Trust Anchor Store

  o  The trust anchor store SHOULD support the use of an apex trust
      anchor.  If apex support is provided, the trust anchor store MUST
      support the secure storage of exactly one apex trust anchor.  The
      trust anchor store SHOULD support the secure storage of at least
      one additional trust anchor.  Each trust anchor MUST contain a
      unique public key.  A public key MAY appear at most one time in a
      trust anchor store.

I think use of the last MAY is wrong, it looks like you are trying to say
"MUST NOT appear more than once".

4)
2.2.3.3.  Content-Hints Attribute

  o  contentDescription is OPTIONAL.  The TAMP message signer MAY
      provide a brief description of the purpose of the TAMP message.
      The text is intended for human consumption, not machine
      processing.  The text is encoded in UTF-8 [RFC3629], which
      accommodates most of the world's writing systems.

<>

Russ: Section 2.9 of RFC 2634 defines the content-hints attribute, and it does not include a language tag.  It is being used here in the same manner
that it is used in S/MIME.  It seem too late to bring on new
requirements.  That said, I'm pleased to work with you to define a new
attribute that includes a language tag that can be used in all of the
places that content-hints is used today.  I do not think we should block
this document for it.

      The implementation MUST provide the capability to constrain the
      character set.

How can this MUST be specified?
UTF-8 is already a character set, so it is not clear what you mean here.
Maybe you meant a script?

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].

6)
4.  Trust Anchor Management Protocol Messages

  o  The TAMP Error message SHOULD be signed.  It uses the following
      object identifier: { id-tamp 9 }.

  Support for Trust Anchor Update messages is REQUIRED.  Support for
  all other message formats is RECOMMENDED.

Even support for the "TAMP Error message" is not a MUST?

I alto think you need to say which end can generate which type of message.
For example, can a Trust Anchor Store generate TAMP Status Query message?

7)
4.  Trust Anchor Management Protocol Messages

  Each TAMP query and update message include an indication of the type
  of response that is desired.  The response can either be terse or
  verbose.  All trust anchor stores SHOULD support both the terse and
  verbose responses and SHOULD generate a response of the type
  indicated in the corresponding request.

What would happen if the first SHOULD is violated?
Does this mean that the recipient MUST support both versions (as the sender might not send the version requested)?

8)
4.1.  TAMP Status Query

  If the digital signature on the TAMP Status Query message is valid,
  sequence number checking is successful, the signer is authorized, and
  the trust anchor store is an intended recipient of the TAMP message,
  then a TAMP Status Response message SHOULD be returned.  If a TAMP
  Status Response message is not returned, then a TAMP Error message
  SHOULD be returned.

It looks like the 2 SHOULDs allow for no message to be returned.
I think this would affect interoperability.

(The same issue for all other commands.)

9)
4.1.  TAMP Status Query

      The uri field can be
      used to identify a target, i.e., a trust anchor store, using a
      Uniform Resource Identifier.

I think you need a normative reference to the URI spec (RFC 3986) here.

10)
4.1.  TAMP Status Query

    TargetIdentifier ::= CHOICE {
      hwModules    [1] HardwareModuleIdentifierList,
      communities  [2] CommunityIdentifierList,
      allModules  [3] NULL,
      uri          [4] IA5String,
      otherName    [5] AnotherName}

Is any of the choices mandatory to implement?

11)
4.2.  TAMP Status Query Response

    TrustAnchorChoiceList ::= SEQUENCE SIZE (1..MAX) OF
        TrustAnchorChoice
    }

This doesn't look like a valid ASN.1: extra "}"?

12)
4.2.  TAMP Status Query Response

  o  tampSeqNumbers is OPTIONAL.  When present, it is used to indicate
      the currently held sequence number for each trust anchor
      authorized to sign TAMP messages.  The keyId field identifies the
      trust anchor and the seqNumber field provides the current sequence
      number associated with the trust anchor.

I am confused here. How can this be converted to
    TAMPMsgRef ::= SEQUENCE {
      target  TargetIdentifier,
      seqNum  SeqNumber }
?

13)
4.3.1.  Trust Anchor List

  [I-D.ietf-pkix-ta-format] defines the TrustAnchorList structure to

You lost me, I can't find where in the document the TrustAnchorList is used. Can you please clarify?

  convey a list of trust anchors.  TAMP implementations MAY process
  TrustAnchorList objects as TAMPUpdate objects with terse set to
  terse, msgRef set to allModules (with a suitable sequence number) and
  all elements within the list contained within the add field.

15).
In Section 5:

  o  badUnsignedAttrs is used to indicate that the unsignedAttrs within
      SignerInfo contains an attribute other than the contingency-
      public-key-decrypt-key unsigned attribute, which is the only
      unsigned attribute supported by this specification.

But section 2.2.4 says:

  The TAMP message originator SHOULD NOT include other unsigned
  attributes, and any unrecognized unsigned attributes MUST be ignored.

Which means that this error code can never be returned by a compliant implementation.


17)
4.11.  TAMP Error

    TAMPError ::= SEQUENCE {
      version  [0] TAMPVersion DEFAULT v2,
      msgType  OBJECT IDENTIFIER,

What happens if the msgType couldn't be parsed?
No TAMP Error message can be generated?

Maybe it would be better to make this field OPTIONAL.

18) Were MIME media types submitted for review to the ietf-types@ mailing list?

19)
C.2.  TAMP Status Response Message

  An HTTP-based TAMP Status Response message is composed of the
  appropriate HTTP headers, followed by the binary value of the DER
  encoding of the TAMPStatusResponse, wrapped in a CMS body as
  described in Section 2.

Here and in other sections describing "response messages":
Is this an HTTP response?

20) HTTP mapping seems to be underspecified. For example it needs to discuss cache control behavior for responses.

[Ballot discuss]
UPDATED to remove one point

An extensive document, so it is not surprising that I am able to
find some small concerns. I don't think that any is a major show-
stopper, but they do all need attention.

---

I had some trouble working out what an implementation was to do in
the event of some error condiditions.

For example:

1. In section 2.2.3.1

  A content-type attribute MUST contain the same object identifier as
  the content type contained in the EncapsulatedContentInfo.

2. Two places in the document say that in the event of specific errors,
  messages MUST be rejected as malformed. However, Section 5 does not
  list such a status code.                                       

  It is probable that both of the malformation cases are actually
  covered by more specific status codes and the text needs to be
  updated.

3. Section 4.3

  Attempts to change a trust anchor added as a TBSCertificate using
  a TrustAnchorChangeInfo MUST fail.  Attempts to change a trust
  anchor added as a TrustAnchorInfo using a TBSCertificateChangeInfo
  MUST fail.

I think a careful pass through the document to examine the use of "MUST"
will reveal a number of cases where the protocol action in the event of
a breach is not clear.

---

Section 4.1

  If the digital signature on the TAMP Status Query message is valid,
  sequence number checking is successful, the signer is authorized, and
  the trust anchor store is an intended recipient of the TAMP message,
  then a TAMP Status Response message SHOULD be returned.  If a TAMP
  Status Response message is not returned, then a TAMP Error message
  SHOULD be returned.

Can you say why the final SHOULD is not a MUST? I.e., under what
circumstances an implementation that decides to not return a Status
Response MAY simply swallow the Status Query.

[Ballot discuss]
An extensive document, so it is not surprising that I am able to
find some small concerns. I don't think that any is a major show-
stopper, but they do all need attention.

---

Slightly puzzled by

  This specification is intended to satisfy the protocol-related
  requirements expressed in Trust Anchor Management Requirements
  [I-D.draft-ietf-pkix-ta-mgmt-reqs] and uses vocabulary from that
  document.

Since that document is work in progress and not yet finalized, how can
this document know whether it does/will satisfy the requirements? It
sounds as though this document should wait for the other to at least
complete WG last call, if not be approved.

---

I had some trouble working out what an implementation was to do in
the event of some error condiditions.

For example:

1. In section 2.2.3.1

  A content-type attribute MUST contain the same object identifier as
  the content type contained in the EncapsulatedContentInfo.

2. Two places in the document say that in the event of specific errors,
  messages MUST be rejected as malformed. However, Section 5 does not
  list such a status code.                                       

  It is probable that both of the malformation cases are actually
  covered by more specific status codes and the text needs to be
  updated.

3. Section 4.3

  Attempts to change a trust anchor added as a TBSCertificate using
  a TrustAnchorChangeInfo MUST fail.  Attempts to change a trust
  anchor added as a TrustAnchorInfo using a TBSCertificateChangeInfo
  MUST fail.

I think a careful pass through the document to examine the use of "MUST"
will reveal a number of cases where the protocol action in the event of
a breach is not clear.

---

Section 4.1

  If the digital signature on the TAMP Status Query message is valid,
  sequence number checking is successful, the signer is authorized, and
  the trust anchor store is an intended recipient of the TAMP message,
  then a TAMP Status Response message SHOULD be returned.  If a TAMP
  Status Response message is not returned, then a TAMP Error message
  SHOULD be returned.

Can you say why the final SHOULD is not a MUST? I.e., under what
circumstances an implementation that decides to not return a Status
Response MAY simply swallow the Status Query.

[Ballot comment]
1)
1.3.1.  Cryptographic Module

      If only one
      one-way hash function is present, it MUST be consistent with the
      digital signature validation and digital signature generation
      algorithms.  If only one digital signature validation algorithm is
      present, it must be consistent with the apex trust anchor
      operational public key.  If only one digital signature generation
      algorithm is present, it must be consistent with the cryptographic
      module digital signature private key.

Change a couple of "must"s to "MUST"s?

2)
1.3.3.  TAMP Processing Dependencies

  TAMP processing MUST include the following capabilities:

  o  TAMP processing MUST have a means of locating an appropriate trust
      anchor.  Two mechanisms are available.  The first mechanism is
      based on the public key identifier for digital signature
      verification, and the second mechanism is based on the trust
      anchor X.500 distinguished name and other X.509 certification path
      controls for certificate path discovery and validation.  The first
      mechanism MUST be supported, but the second mechanism can also be
      used.

Does this mean that the second mechanism is OPTIONAL? I don't think
the text is very clear.

3). Also in 1.3.3:

  o  TAMP processing MUST have read and write access to secure storage
      for trust anchors in order to update them.  Update operations
      include adding trust anchors, removing trust anchors, and
      modifying trust anchors.  Application-specific access controls
      MUST be securely stored with each management trust anchor as
      described in Section 1.3.4.

I am not sure. Does 1.3.4 cover this?

4)
1.3.4.  Application-Specific Protocol Processing

  The application-specific protocol processing MUST be provided the
  following services:

It looks like a preposition is missing here.

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.

6)
4.  Trust Anchor Management Protocol Messages

  TAMP specifies eleven message types.  The following provides the
  content type identifier for each TAMP message type, and it indicates
  whether a digital signature is REQUIRED.

This doesn't look like the right use for an RFC 2119 keyword.

7) In Section 4.3:

  o  change is used to update the information associated with an
      existing management or identity trust anchor in the trust anchor
      store.
    [...]
      Attempts to change a trust anchor added as a TBSCertificate using
      a TrustAnchorChangeInfo MUST fail.  Attempts to change a trust
      anchor added as a TrustAnchorInfo using a TBSCertificateChangeInfo
      MUST fail.

As you already listed appropriate error codes for some other failures,
it would be a good idea to list the corresponding error code(s) here as well.

8). Security consideration fields for registered MIME media types are not well written. For example, section B.1 says:

  Security considerations: Carries a request for status information.

So what? What needs to be protected? What are the risks from using this media type to applications? Etc.

--------------------------
The following [former] DISCUSSes are listed here with some explanation of why they are not going to be addressed in this document:

2)

1.3.1.  Cryptographic Module

  o  The cryptographic module MUST support at least one one-way hash
      function, one digital signature validation algorithm, one digital
      signature generation algorithm, and, if contingency keys are
      supported, one symmetric key unwrapping algorithm.

Is there a mandatory to implement algorithm?

Russ: PKIX has never specified mandatory to implement algorithms.  The reason is that other protocols make use of certificates, and these other
protocols often dictate algorithm requirements.  For example, S/MIME
does have mandatory to implement algorithms, and S/MIME depends on PKIX
certificate specifications.  The same convention is being followed here.

[Ballot discuss]
Updated, issues starting from # 14 are new (and the COMMENT # 8 is new as well):

1)
1.3.  Architectural Elements

  A globally unique algorithm identifier MUST be assigned for each one-
  way hash function, digital signature generation/validation algorithm,
  and symmetric key unwrapping algorithm that is implemented.  To
  support CMS, an object identifier (OID) is assigned to name a one-way
  hash function, and another OID is assigned to name each combination
  of a one-way hash function when used with a digital signature
  algorithm.  Similarly, certificates associate OIDs assigned to public
  key algorithms with subject public keys, and certificates make use of
  an OID that names both the one-way hash function and the digital
  signature algorithm for the certificate issuer digital signature.

Is there any particular IANA registry to choose OIDs from?
This might affect interoperability.

3)
1.3.2.  Trust Anchor Store

  o  The trust anchor store SHOULD support the use of an apex trust
      anchor.  If apex support is provided, the trust anchor store MUST
      support the secure storage of exactly one apex trust anchor.  The
      trust anchor store SHOULD support the secure storage of at least
      one additional trust anchor.  Each trust anchor MUST contain a
      unique public key.  A public key MAY appear at most one time in a
      trust anchor store.

I think use of the last MAY is wrong, it looks like you are trying to say
"MUST NOT appear more than once".

4)
2.2.3.3.  Content-Hints Attribute

  o  contentDescription is OPTIONAL.  The TAMP message signer MAY
      provide a brief description of the purpose of the TAMP message.
      The text is intended for human consumption, not machine
      processing.  The text is encoded in UTF-8 [RFC3629], which
      accommodates most of the world's writing systems.

<>

Russ: Section 2.9 of RFC 2634 defines the content-hints attribute, and it does not include a language tag.  It is being used here in the same manner
that it is used in S/MIME.  It seem too late to bring on new
requirements.  That said, I'm pleased to work with you to define a new
attribute that includes a language tag that can be used in all of the
places that content-hints is used today.  I do not think we should block
this document for it.

      The implementation MUST provide the capability to constrain the
      character set.

How can this MUST be specified?
UTF-8 is already a character set, so it is not clear what you mean here.
Maybe you meant a script?

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].

6)
4.  Trust Anchor Management Protocol Messages

  o  The TAMP Error message SHOULD be signed.  It uses the following
      object identifier: { id-tamp 9 }.

  Support for Trust Anchor Update messages is REQUIRED.  Support for
  all other message formats is RECOMMENDED.

Even support for the "TAMP Error message" is not a MUST?

I alto think you need to say which end can generate which type of message.
For example, can a Trust Anchor Store generate TAMP Status Query message?

7)
4.  Trust Anchor Management Protocol Messages

  Each TAMP query and update message include an indication of the type
  of response that is desired.  The response can either be terse or
  verbose.  All trust anchor stores SHOULD support both the terse and
  verbose responses and SHOULD generate a response of the type
  indicated in the corresponding request.

What would happen if the first SHOULD is violated?
Does this mean that the recipient MUST support both versions (as the sender might not send the version requested)?

8)
4.1.  TAMP Status Query

  If the digital signature on the TAMP Status Query message is valid,
  sequence number checking is successful, the signer is authorized, and
  the trust anchor store is an intended recipient of the TAMP message,
  then a TAMP Status Response message SHOULD be returned.  If a TAMP
  Status Response message is not returned, then a TAMP Error message
  SHOULD be returned.

It looks like the 2 SHOULDs allow for no message to be returned.
I think this would affect interoperability.

(The same issue for all other commands.)

9)
4.1.  TAMP Status Query

      The uri field can be
      used to identify a target, i.e., a trust anchor store, using a
      Uniform Resource Identifier.

I think you need a normative reference to the URI spec (RFC 3986) here.

10)
4.1.  TAMP Status Query

    TargetIdentifier ::= CHOICE {
      hwModules    [1] HardwareModuleIdentifierList,
      communities  [2] CommunityIdentifierList,
      allModules  [3] NULL,
      uri          [4] IA5String,
      otherName    [5] AnotherName}

Is any of the choices mandatory to implement?

11)
4.2.  TAMP Status Query Response

    TrustAnchorChoiceList ::= SEQUENCE SIZE (1..MAX) OF
        TrustAnchorChoice
    }

This doesn't look like a valid ASN.1: extra "}"?

12)
4.2.  TAMP Status Query Response

  o  tampSeqNumbers is OPTIONAL.  When present, it is used to indicate
      the currently held sequence number for each trust anchor
      authorized to sign TAMP messages.  The keyId field identifies the
      trust anchor and the seqNumber field provides the current sequence
      number associated with the trust anchor.

I am confused here. How can this be converted to
    TAMPMsgRef ::= SEQUENCE {
      target  TargetIdentifier,
      seqNum  SeqNumber }
?

13)
4.3.1.  Trust Anchor List

  [I-D.ietf-pkix-ta-format] defines the TrustAnchorList structure to

You lost me, I can't find where in the document the TrustAnchorList is used. Can you please clarify?

  convey a list of trust anchors.  TAMP implementations MAY process
  TrustAnchorList objects as TAMPUpdate objects with terse set to
  terse, msgRef set to allModules (with a suitable sequence number) and
  all elements within the list contained within the add field.

14)
In Section 5:

Is the list of error codes extensible?

15).
In Section 5:

  o  badUnsignedAttrs is used to indicate that the unsignedAttrs within
      SignerInfo contains an attribute other than the contingency-
      public-key-decrypt-key unsigned attribute, which is the only
      unsigned attribute supported by this specification.

But section 2.2.4 says:

  The TAMP message originator SHOULD NOT include other unsigned
  attributes, and any unrecognized unsigned attributes MUST be ignored.

Which means that this error code can never be returned by a compliant implementation.

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?)

17)
4.11.  TAMP Error

    TAMPError ::= SEQUENCE {
      version  [0] TAMPVersion DEFAULT v2,
      msgType  OBJECT IDENTIFIER,

What happens if the msgType couldn't be parsed?
No TAMP Error message can be generated?

Maybe it would be better to make this field OPTIONAL.

18) Were MIME media types submitted for review to the ietf-types@ mailing list?

19)
C.2.  TAMP Status Response Message

  An HTTP-based TAMP Status Response message is composed of the
  appropriate HTTP headers, followed by the binary value of the DER
  encoding of the TAMPStatusResponse, wrapped in a CMS body as
  described in Section 2.

Here and in other sections describing "response messages":
Is this an HTTP response?

20) HTTP mapping seems to be underspecified. For example it needs to discuss cache control behavior for responses.

[Ballot comment]
1)
1.3.1.  Cryptographic Module

      If only one
      one-way hash function is present, it MUST be consistent with the
      digital signature validation and digital signature generation
      algorithms.  If only one digital signature validation algorithm is
      present, it must be consistent with the apex trust anchor
      operational public key.  If only one digital signature generation
      algorithm is present, it must be consistent with the cryptographic
      module digital signature private key.

Change a couple of "must"s to "MUST"s?

2)
1.3.3.  TAMP Processing Dependencies

  TAMP processing MUST include the following capabilities:

  o  TAMP processing MUST have a means of locating an appropriate trust
      anchor.  Two mechanisms are available.  The first mechanism is
      based on the public key identifier for digital signature
      verification, and the second mechanism is based on the trust
      anchor X.500 distinguished name and other X.509 certification path
      controls for certificate path discovery and validation.  The first
      mechanism MUST be supported, but the second mechanism can also be
      used.

Does this mean that the second mechanism is OPTIONAL? I don't think
the text is very clear.

3). Also in 1.3.3:

  o  TAMP processing MUST have read and write access to secure storage
      for trust anchors in order to update them.  Update operations
      include adding trust anchors, removing trust anchors, and
      modifying trust anchors.  Application-specific access controls
      MUST be securely stored with each management trust anchor as
      described in Section 1.3.4.

I am not sure. Does 1.3.4 cover this?

4)
1.3.4.  Application-Specific Protocol Processing

  The application-specific protocol processing MUST be provided the
  following services:

It looks like a preposition is missing here.

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.

6)
4.  Trust Anchor Management Protocol Messages

  TAMP specifies eleven message types.  The following provides the
  content type identifier for each TAMP message type, and it indicates
  whether a digital signature is REQUIRED.

This doesn't look like the right use for an RFC 2119 keyword.

7) In Section 4.3:

  o  change is used to update the information associated with an
      existing management or identity trust anchor in the trust anchor
      store.
    [...]
      Attempts to change a trust anchor added as a TBSCertificate using
      a TrustAnchorChangeInfo MUST fail.  Attempts to change a trust
      anchor added as a TrustAnchorInfo using a TBSCertificateChangeInfo
      MUST fail.

As you already listed appropriate error codes for some other failures,
it would be a good idea to list the corresponding error code(s) here as well.

8). Security consideration fields for registered MIME media types are not well written. For example, section B.1 says:

  Security considerations: Carries a request for status information.

So what? What needs to be protected? What are the risks from using this media type to applications? Etc.

--------------------------
The following [former] DISCUSSes are listed here with some explanation of why they are not going to be addressed in this document:

2)

1.3.1.  Cryptographic Module

  o  The cryptographic module MUST support at least one one-way hash
      function, one digital signature validation algorithm, one digital
      signature generation algorithm, and, if contingency keys are
      supported, one symmetric key unwrapping algorithm.

Is there a mandatory to implement algorithm?

Russ: PKIX has never specified mandatory to implement algorithms.  The reason is that other protocols make use of certificates, and these other
protocols often dictate algorithm requirements.  For example, S/MIME
does have mandatory to implement algorithms, and S/MIME depends on PKIX
certificate specifications.  The same convention is being followed here.

[Ballot discuss]
Updated, issues starting from # 14 are new:

1)
1.3.  Architectural Elements

  A globally unique algorithm identifier MUST be assigned for each one-
  way hash function, digital signature generation/validation algorithm,
  and symmetric key unwrapping algorithm that is implemented.  To
  support CMS, an object identifier (OID) is assigned to name a one-way
  hash function, and another OID is assigned to name each combination
  of a one-way hash function when used with a digital signature
  algorithm.  Similarly, certificates associate OIDs assigned to public
  key algorithms with subject public keys, and certificates make use of
  an OID that names both the one-way hash function and the digital
  signature algorithm for the certificate issuer digital signature.

Is there any particular IANA registry to choose OIDs from?
This might affect interoperability.

3)
1.3.2.  Trust Anchor Store

  o  The trust anchor store SHOULD support the use of an apex trust
      anchor.  If apex support is provided, the trust anchor store MUST
      support the secure storage of exactly one apex trust anchor.  The
      trust anchor store SHOULD support the secure storage of at least
      one additional trust anchor.  Each trust anchor MUST contain a
      unique public key.  A public key MAY appear at most one time in a
      trust anchor store.

I think use of the last MAY is wrong, it looks like you are trying to say
"MUST NOT appear more than once".

4)
2.2.3.3.  Content-Hints Attribute

  o  contentDescription is OPTIONAL.  The TAMP message signer MAY
      provide a brief description of the purpose of the TAMP message.
      The text is intended for human consumption, not machine
      processing.  The text is encoded in UTF-8 [RFC3629], which
      accommodates most of the world's writing systems.

<>

Russ: Section 2.9 of RFC 2634 defines the content-hints attribute, and it does not include a language tag.  It is being used here in the same manner
that it is used in S/MIME.  It seem too late to bring on new
requirements.  That said, I'm pleased to work with you to define a new
attribute that includes a language tag that can be used in all of the
places that content-hints is used today.  I do not think we should block
this document for it.

      The implementation MUST provide the capability to constrain the
      character set.

How can this MUST be specified?
UTF-8 is already a character set, so it is not clear what you mean here.
Maybe you meant a script?

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].

6)
4.  Trust Anchor Management Protocol Messages

  o  The TAMP Error message SHOULD be signed.  It uses the following
      object identifier: { id-tamp 9 }.

  Support for Trust Anchor Update messages is REQUIRED.  Support for
  all other message formats is RECOMMENDED.

Even support for the "TAMP Error message" is not a MUST?

I alto think you need to say which end can generate which type of message.
For example, can a Trust Anchor Store generate TAMP Status Query message?

7)
4.  Trust Anchor Management Protocol Messages

  Each TAMP query and update message include an indication of the type
  of response that is desired.  The response can either be terse or
  verbose.  All trust anchor stores SHOULD support both the terse and
  verbose responses and SHOULD generate a response of the type
  indicated in the corresponding request.

What would happen if the first SHOULD is violated?
Does this mean that the recipient MUST support both versions (as the sender might not send the version requested)?

8)
4.1.  TAMP Status Query

  If the digital signature on the TAMP Status Query message is valid,
  sequence number checking is successful, the signer is authorized, and
  the trust anchor store is an intended recipient of the TAMP message,
  then a TAMP Status Response message SHOULD be returned.  If a TAMP
  Status Response message is not returned, then a TAMP Error message
  SHOULD be returned.

It looks like the 2 SHOULDs allow for no message to be returned.
I think this would affect interoperability.

(The same issue for all other commands.)

9)
4.1.  TAMP Status Query

      The uri field can be
      used to identify a target, i.e., a trust anchor store, using a
      Uniform Resource Identifier.

I think you need a normative reference to the URI spec (RFC 3986) here.

10)
4.1.  TAMP Status Query

    TargetIdentifier ::= CHOICE {
      hwModules    [1] HardwareModuleIdentifierList,
      communities  [2] CommunityIdentifierList,
      allModules  [3] NULL,
      uri          [4] IA5String,
      otherName    [5] AnotherName}

Is any of the choices mandatory to implement?

11)
4.2.  TAMP Status Query Response

    TrustAnchorChoiceList ::= SEQUENCE SIZE (1..MAX) OF
        TrustAnchorChoice
    }

This doesn't look like a valid ASN.1: extra "}"?

12)
4.2.  TAMP Status Query Response

  o  tampSeqNumbers is OPTIONAL.  When present, it is used to indicate
      the currently held sequence number for each trust anchor
      authorized to sign TAMP messages.  The keyId field identifies the
      trust anchor and the seqNumber field provides the current sequence
      number associated with the trust anchor.

I am confused here. How can this be converted to
    TAMPMsgRef ::= SEQUENCE {
      target  TargetIdentifier,
      seqNum  SeqNumber }
?

13)
4.3.1.  Trust Anchor List

  [I-D.ietf-pkix-ta-format] defines the TrustAnchorList structure to

You lost me, I can't find where in the document the TrustAnchorList is used. Can you please clarify?

  convey a list of trust anchors.  TAMP implementations MAY process
  TrustAnchorList objects as TAMPUpdate objects with terse set to
  terse, msgRef set to allModules (with a suitable sequence number) and
  all elements within the list contained within the add field.

14)
In Section 5:

Is the list of error codes extensible?

15).
In Section 5:

  o  badUnsignedAttrs is used to indicate that the unsignedAttrs within
      SignerInfo contains an attribute other than the contingency-
      public-key-decrypt-key unsigned attribute, which is the only
      unsigned attribute supported by this specification.

But section 2.2.4 says:

  The TAMP message originator SHOULD NOT include other unsigned
  attributes, and any unrecognized unsigned attributes MUST be ignored.

Which means that this error code can never be returned by a compliant implementation.

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?)

17)
4.11.  TAMP Error

    TAMPError ::= SEQUENCE {
      version  [0] TAMPVersion DEFAULT v2,
      msgType  OBJECT IDENTIFIER,

What happens if the msgType couldn't be parsed?
No TAMP Error message can be generated?

Maybe it would be better to make this field OPTIONAL.

18) Were MIME media types submitted for review to the ietf-types@ mailing list?

19)
C.2.  TAMP Status Response Message

  An HTTP-based TAMP Status Response message is composed of the
  appropriate HTTP headers, followed by the binary value of the DER
  encoding of the TAMPStatusResponse, wrapped in a CMS body as
  described in Section 2.

Here and in other sections describing "response messages":
Is this an HTTP response?

20) HTTP mapping seems to be underspecified. For example it needs to discuss cache control behavior for responses.

[Ballot comment]
1)
1.3.1.  Cryptographic Module

      If only one
      one-way hash function is present, it MUST be consistent with the
      digital signature validation and digital signature generation
      algorithms.  If only one digital signature validation algorithm is
      present, it must be consistent with the apex trust anchor
      operational public key.  If only one digital signature generation
      algorithm is present, it must be consistent with the cryptographic
      module digital signature private key.

Change a couple of "must"s to "MUST"s?

2)
1.3.3.  TAMP Processing Dependencies

  TAMP processing MUST include the following capabilities:

  o  TAMP processing MUST have a means of locating an appropriate trust
      anchor.  Two mechanisms are available.  The first mechanism is
      based on the public key identifier for digital signature
      verification, and the second mechanism is based on the trust
      anchor X.500 distinguished name and other X.509 certification path
      controls for certificate path discovery and validation.  The first
      mechanism MUST be supported, but the second mechanism can also be
      used.

Does this mean that the second mechanism is OPTIONAL? I don't think
the text is very clear.

3). Also in 1.3.3:

  o  TAMP processing MUST have read and write access to secure storage
      for trust anchors in order to update them.  Update operations
      include adding trust anchors, removing trust anchors, and
      modifying trust anchors.  Application-specific access controls
      MUST be securely stored with each management trust anchor as
      described in Section 1.3.4.

I am not sure. Does 1.3.4 cover this?

4)
1.3.4.  Application-Specific Protocol Processing

  The application-specific protocol processing MUST be provided the
  following services:

It looks like a preposition is missing here.

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.

6)
4.  Trust Anchor Management Protocol Messages

  TAMP specifies eleven message types.  The following provides the
  content type identifier for each TAMP message type, and it indicates
  whether a digital signature is REQUIRED.

This doesn't look like the right use for an RFC 2119 keyword.

7) In Section 4.3:

  o  change is used to update the information associated with an
      existing management or identity trust anchor in the trust anchor
      store.
    [...]
      Attempts to change a trust anchor added as a TBSCertificate using
      a TrustAnchorChangeInfo MUST fail.  Attempts to change a trust
      anchor added as a TrustAnchorInfo using a TBSCertificateChangeInfo
      MUST fail.

As you already listed appropriate error codes for some other failures,
it would be a good idea to list the corresponding error code(s) here as well.


--------------------------
The following [former] DISCUSSes are listed here with some explanation of why they are not going to be addressed in this document:

2)

1.3.1.  Cryptographic Module

  o  The cryptographic module MUST support at least one one-way hash
      function, one digital signature validation algorithm, one digital
      signature generation algorithm, and, if contingency keys are
      supported, one symmetric key unwrapping algorithm.

Is there a mandatory to implement algorithm?

Russ: PKIX has never specified mandatory to implement algorithms.  The reason is that other protocols make use of certificates, and these other
protocols often dictate algorithm requirements.  For example, S/MIME
does have mandatory to implement algorithms, and S/MIME depends on PKIX
certificate specifications.  The same convention is being followed here.

[Ballot discuss]
Updated, issues starting from # 14 are new:

1)
1.3.  Architectural Elements

  A globally unique algorithm identifier MUST be assigned for each one-
  way hash function, digital signature generation/validation algorithm,
  and symmetric key unwrapping algorithm that is implemented.  To
  support CMS, an object identifier (OID) is assigned to name a one-way
  hash function, and another OID is assigned to name each combination
  of a one-way hash function when used with a digital signature
  algorithm.  Similarly, certificates associate OIDs assigned to public
  key algorithms with subject public keys, and certificates make use of
  an OID that names both the one-way hash function and the digital
  signature algorithm for the certificate issuer digital signature.

Is there any particular IANA registry to choose OIDs from?
This might affect interoperability.

3)
1.3.2.  Trust Anchor Store

  o  The trust anchor store SHOULD support the use of an apex trust
      anchor.  If apex support is provided, the trust anchor store MUST
      support the secure storage of exactly one apex trust anchor.  The
      trust anchor store SHOULD support the secure storage of at least
      one additional trust anchor.  Each trust anchor MUST contain a
      unique public key.  A public key MAY appear at most one time in a
      trust anchor store.

I think use of the last MAY is wrong, it looks like you are trying to say
"MUST NOT appear more than once".

4)
2.2.3.3.  Content-Hints Attribute

  o  contentDescription is OPTIONAL.  The TAMP message signer MAY
      provide a brief description of the purpose of the TAMP message.
      The text is intended for human consumption, not machine
      processing.  The text is encoded in UTF-8 [RFC3629], which
      accommodates most of the world's writing systems.

<>

Russ: Section 2.9 of RFC 2634 defines the content-hints attribute, and it does not include a language tag.  It is being used here in the same manner
that it is used in S/MIME.  It seem too late to bring on new
requirements.  That said, I'm pleased to work with you to define a new
attribute that includes a language tag that can be used in all of the
places that content-hints is used today.  I do not think we should block
this document for it.

      The implementation MUST provide the capability to constrain the
      character set.

How can this MUST be specified?
UTF-8 is already a character set, so it is not clear what you mean here.
Maybe you meant a script?

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].

6)
4.  Trust Anchor Management Protocol Messages

  o  The TAMP Error message SHOULD be signed.  It uses the following
      object identifier: { id-tamp 9 }.

  Support for Trust Anchor Update messages is REQUIRED.  Support for
  all other message formats is RECOMMENDED.

Even support for the "TAMP Error message" is not a MUST?

I alto think you need to say which end can generate which type of message.
For example, can a Trust Anchor Store generate TAMP Status Query message?

7)
4.  Trust Anchor Management Protocol Messages

  Each TAMP query and update message include an indication of the type
  of response that is desired.  The response can either be terse or
  verbose.  All trust anchor stores SHOULD support both the terse and
  verbose responses and SHOULD generate a response of the type
  indicated in the corresponding request.

What would happen if the first SHOULD is violated?
Does this mean that the recipient MUST support both versions (as the sender might not send the version requested)?

8)
4.1.  TAMP Status Query

  If the digital signature on the TAMP Status Query message is valid,
  sequence number checking is successful, the signer is authorized, and
  the trust anchor store is an intended recipient of the TAMP message,
  then a TAMP Status Response message SHOULD be returned.  If a TAMP
  Status Response message is not returned, then a TAMP Error message
  SHOULD be returned.

It looks like the 2 SHOULDs allow for no message to be returned.
I think this would affect interoperability.

(The same issue for all other commands.)

9)
4.1.  TAMP Status Query

      The uri field can be
      used to identify a target, i.e., a trust anchor store, using a
      Uniform Resource Identifier.

I think you need a normative reference to the URI spec (RFC 3986) here.

10)
4.1.  TAMP Status Query

    TargetIdentifier ::= CHOICE {
      hwModules    [1] HardwareModuleIdentifierList,
      communities  [2] CommunityIdentifierList,
      allModules  [3] NULL,
      uri          [4] IA5String,
      otherName    [5] AnotherName}

Is any of the choices mandatory to implement?

11)
4.2.  TAMP Status Query Response

    TrustAnchorChoiceList ::= SEQUENCE SIZE (1..MAX) OF
        TrustAnchorChoice
    }

This doesn't look like a valid ASN.1: extra "}"?

12)
4.2.  TAMP Status Query Response

  o  tampSeqNumbers is OPTIONAL.  When present, it is used to indicate
      the currently held sequence number for each trust anchor
      authorized to sign TAMP messages.  The keyId field identifies the
      trust anchor and the seqNumber field provides the current sequence
      number associated with the trust anchor.

I am confused here. How can this be converted to
    TAMPMsgRef ::= SEQUENCE {
      target  TargetIdentifier,
      seqNum  SeqNumber }
?

13)
4.3.1.  Trust Anchor List

  [I-D.ietf-pkix-ta-format] defines the TrustAnchorList structure to

You lost me, I can't find where in the document the TrustAnchorList is used. Can you please clarify?

  convey a list of trust anchors.  TAMP implementations MAY process
  TrustAnchorList objects as TAMPUpdate objects with terse set to
  terse, msgRef set to allModules (with a suitable sequence number) and
  all elements within the list contained within the add field.

14)
In Section 5:

Is the list of error codes extensible?

15).
In Section 5:

  o  badUnsignedAttrs is used to indicate that the unsignedAttrs within
      SignerInfo contains an attribute other than the contingency-
      public-key-decrypt-key unsigned attribute, which is the only
      unsigned attribute supported by this specification.

But section 2.2.4 says:

  The TAMP message originator SHOULD NOT include other unsigned
  attributes, and any unrecognized unsigned attributes MUST be ignored.

Which means that this error code can never be returned by a compliant implementation.

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?

17)
4.11.  TAMP Error

    TAMPError ::= SEQUENCE {
      version  [0] TAMPVersion DEFAULT v2,
      msgType  OBJECT IDENTIFIER,

What happens if the msgType couldn't be parsed?
No TAMP Error message can be generated?

Maybe it would be better to make this field OPTIONAL.

[Ballot comment]
1)
1.3.1.  Cryptographic Module

      If only one
      one-way hash function is present, it MUST be consistent with the
      digital signature validation and digital signature generation
      algorithms.  If only one digital signature validation algorithm is
      present, it must be consistent with the apex trust anchor
      operational public key.  If only one digital signature generation
      algorithm is present, it must be consistent with the cryptographic
      module digital signature private key.

Change a couple of "must"s to "MUST"s?

2)
1.3.3.  TAMP Processing Dependencies

  TAMP processing MUST include the following capabilities:

  o  TAMP processing MUST have a means of locating an appropriate trust
      anchor.  Two mechanisms are available.  The first mechanism is
      based on the public key identifier for digital signature
      verification, and the second mechanism is based on the trust
      anchor X.500 distinguished name and other X.509 certification path
      controls for certificate path discovery and validation.  The first
      mechanism MUST be supported, but the second mechanism can also be
      used.

Does this mean that the second mechanism is OPTIONAL? I don't think
the text is very clear.

3). Also in 1.3.3:

  o  TAMP processing MUST have read and write access to secure storage
      for trust anchors in order to update them.  Update operations
      include adding trust anchors, removing trust anchors, and
      modifying trust anchors.  Application-specific access controls
      MUST be securely stored with each management trust anchor as
      described in Section 1.3.4.

I am not sure. Does 1.3.4 cover this?

4)
1.3.4.  Application-Specific Protocol Processing

  The application-specific protocol processing MUST be provided the
  following services:

It looks like a preposition is missing here.

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.

6)
4.  Trust Anchor Management Protocol Messages

  TAMP specifies eleven message types.  The following provides the
  content type identifier for each TAMP message type, and it indicates
  whether a digital signature is REQUIRED.

This doesn't look like the right use for an RFC 2119 keyword.

7) In Section 4.3:

  o  change is used to update the information associated with an
      existing management or identity trust anchor in the trust anchor
      store.
    [...]
      Attempts to change a trust anchor added as a TBSCertificate using
      a TrustAnchorChangeInfo MUST fail.  Attempts to change a trust
      anchor added as a TrustAnchorInfo using a TBSCertificateChangeInfo
      MUST fail.

As you already listed appropriate error codes for some other failures,
it would be a good idea to list the corresponding error code(s) here as well.

[Ballot discuss]
This is only part 1, as I haven't finished reading the whole document and it is a long one.

I have a really long list of issues. I might downgrade some of them to COMMENTs.

1)
1.3.  Architectural Elements

  A globally unique algorithm identifier MUST be assigned for each one-
  way hash function, digital signature generation/validation algorithm,
  and symmetric key unwrapping algorithm that is implemented.  To
  support CMS, an object identifier (OID) is assigned to name a one-way
  hash function, and another OID is assigned to name each combination
  of a one-way hash function when used with a digital signature
  algorithm.  Similarly, certificates associate OIDs assigned to public
  key algorithms with subject public keys, and certificates make use of
  an OID that names both the one-way hash function and the digital
  signature algorithm for the certificate issuer digital signature.

Is there any particular IANA registry to choose OIDs from?
This might affect interoperability.

2)

1.3.1.  Cryptographic Module

  o  The cryptographic module MUST support at least one one-way hash
      function, one digital signature validation algorithm, one digital
      signature generation algorithm, and, if contingency keys are
      supported, one symmetric key unwrapping algorithm.

Is there a mandatory to implement algorithm?

3)
1.3.2.  Trust Anchor Store

  o  The trust anchor store SHOULD support the use of an apex trust
      anchor.  If apex support is provided, the trust anchor store MUST
      support the secure storage of exactly one apex trust anchor.  The
      trust anchor store SHOULD support the secure storage of at least
      one additional trust anchor.  Each trust anchor MUST contain a
      unique public key.  A public key MAY appear at most one time in a
      trust anchor store.

I think use of the last MAY is wrong, it looks like you are trying to say
"MUST NOT appear more than once".

4)
2.2.3.3.  Content-Hints Attribute

  o  contentDescription is OPTIONAL.  The TAMP message signer MAY
      provide a brief description of the purpose of the TAMP message.
      The text is intended for human consumption, not machine
      processing.  The text is encoded in UTF-8 [RFC3629], which
      accommodates most of the world's writing systems.

<>

      The implementation MUST provide the capability to constrain the
      character set.

How can this MUST be specified?
UTF-8 is already a character set, so it is not clear what you mean here.
Maybe you meant a script?

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].

6)
4.  Trust Anchor Management Protocol Messages

  o  The TAMP Error message SHOULD be signed.  It uses the following
      object identifier: { id-tamp 9 }.

  Support for Trust Anchor Update messages is REQUIRED.  Support for
  all other message formats is RECOMMENDED.

Even support for the "TAMP Error message" is not a MUST?

I alto think you need to say which end can generate which type of message.
For example, can a Trust Anchor Store generate TAMP Status Query message?

7)
4.  Trust Anchor Management Protocol Messages

  Each TAMP query and update message include an indication of the type
  of response that is desired.  The response can either be terse or
  verbose.  All trust anchor stores SHOULD support both the terse and
  verbose responses and SHOULD generate a response of the type
  indicated in the corresponding request.

What would happen if the first SHOULD is violated?
Does this mean that the recipient MUST support both versions (as the sender might not send the version requested)?

8)
4.1.  TAMP Status Query

  If the digital signature on the TAMP Status Query message is valid,
  sequence number checking is successful, the signer is authorized, and
  the trust anchor store is an intended recipient of the TAMP message,
  then a TAMP Status Response message SHOULD be returned.  If a TAMP
  Status Response message is not returned, then a TAMP Error message
  SHOULD be returned.

It looks like the 2 SHOULDs allow for no message to be returned.
I think this would affect interoperability.

(The same issue for all other commands.)

9)
4.1.  TAMP Status Query

      The uri field can be
      used to identify a target, i.e., a trust anchor store, using a
      Uniform Resource Identifier.

I think you need a normative reference to the URI spec (RFC 3986) here.

10)
4.1.  TAMP Status Query

    TargetIdentifier ::= CHOICE {
      hwModules    [1] HardwareModuleIdentifierList,
      communities  [2] CommunityIdentifierList,
      allModules  [3] NULL,
      uri          [4] IA5String,
      otherName    [5] AnotherName}

Is any of the choices mandatory to implement?

11)
4.2.  TAMP Status Query Response

    TrustAnchorChoiceList ::= SEQUENCE SIZE (1..MAX) OF
        TrustAnchorChoice
    }

This doesn't look like a valid ASN.1: extra "}"?

12)
4.2.  TAMP Status Query Response

  o  tampSeqNumbers is OPTIONAL.  When present, it is used to indicate
      the currently held sequence number for each trust anchor
      authorized to sign TAMP messages.  The keyId field identifies the
      trust anchor and the seqNumber field provides the current sequence
      number associated with the trust anchor.

I am confused here. How can this be converted to
    TAMPMsgRef ::= SEQUENCE {
      target  TargetIdentifier,
      seqNum  SeqNumber }
?

13) In Section 4.3:

  The fields of TBSCertificateChangeInfo are used to alter the fields
  within a TBSCertificate structure.  TBSCertificate is described in
  [RFC5280].  For all fields except exts, if the field is absent in a
  change trust anchor update, then any previous value associated with a
  trust anchor is unchanged.

I think this contradicts some of the earlier statements in the same section, for example:

  o  certPath is OPTIONAL, and when present, it provides the controls
      needed to construct and validate an X.509 certification path.
      When absent in a change trust anchor update, any controls that
      were previously associated with the management or identity trust
      anchor are removed, which means that delegation is no longer
      permitted.

14)
4.3.1.  Trust Anchor List

  [I-D.ietf-pkix-ta-format] defines the TrustAnchorList structure to

You lost me, I can't find where in the document the TrustAnchorList is used. Can you please clarify?

  convey a list of trust anchors.  TAMP implementations MAY process
  TrustAnchorList objects as TAMPUpdate objects with terse set to
  terse, msgRef set to allModules (with a suitable sequence number) and
  all elements within the list contained within the add field.

[Ballot discuss]
Procedure issue - the IESG write-up includes a personal statement that needs to be re-formulated - 'Rather than hold
up this document, I have decided to push this document forward and will
suggest that the folks interested in this functionality draft a
specification with the necessary extension for processing as an individual submission.'

IANA comments:

Upon approval of this document, IANA will make the following
assignments in the "Application Media Types" registry at
http://www.iana.org/assignments/media-types/application/

tamp-status-query [RFC-pkix-tamp-05]
tamp-status-response [RFC-pkix-tamp-05]
tamp-update [RFC-pkix-tamp-05]
tamp-update-confirm [RFC-pkix-tamp-05]
tamp-apex-update [RFC-pkix-tamp-05]
tamp-apex-update-confirm [RFC-pkix-tamp-05]
tamp-community-update [RFC-pkix-tamp-05]
tamp-community-update-confirm [RFC-pkix-tamp-05]
tamp-sequence-adjust [RFC-pkix-tamp-05]
tamp-sequence-adjust-confirm [RFC-pkix-tamp-05]
tamp-error [RFC-pkix-tamp-05]

We understand the above to be the only IANA Action for this document.

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Steve Kent is the Document Shepherd for this document. I have reviewed this version of the document and I believe it is ready for forwarding to the IESG for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

The document has received adequate review from key WG members and non-WG members.  There are no concerns about the depth or breadth of the reviews that have been performed.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

There are no specific concerns to highlight to the AD or IESG. No IPR
disclosures have been filed related to this document.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

This document has reached WG consensus after considerable debate when the specification was initially offered. As a result, the initial contents of this I-D were separated into two specifications. The other specification (Trust Anchor Format) is currently in the RFC editors queue. One WG member (Denis Pinkas) is unhappy that not all of his recommendations have been accommodated, but this is common behavior for Denis :

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarize the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

Yes.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

References have been split into normative and informative sections. There is
one normative reference to an in-progress I-D, which will be an Informational RFC:

  [I-D.ietf-pkix-new-asn1]
            Hoffman, P. and J. Schaad, "New ASN.1 Modules for PKIX",
            draft-ietf-pkix-new-asn1-07 (work in progress),
            August 2009.


  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section (in the -05 version) will specify that eleven MIME type registrations will be required. These are already included in Appendix B of the I-D, but the -04 version of the I-D had the "no IANA actions required" boilerplate.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

The ASN.1 appears to be correct, but I have not personally tried to compile it.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:
    Technical Summary
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.
    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?
    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

Technical Summary

This document describes a transport independent protocol for the management of trust anchors and community identifiers stored in a trust anchor store. (Community identifiers are used to associate a cryptographic module with one or more groups to which TAMP message may be sent in a multicast fashion.) The application context that motivates of TAMP is that of a cryptographic modules that is remotely managed by an administrative entity (as opposed to locally managed by the user of the module). The protocol makes use of the Cryptographic Message Syntax (CMS), and a digital signature is used to provide integrity and data origin authentication. TAMP can operate over a realtime connection, or via staged delivery mechanisms. The protocol can be used to manage trust anchor stores containing trust anchors represented as a Certificate, a TBSCertificate or as TrustAnchorInfo objects.

Working Group Summary

This document entered the working group following the Trust Anchor Management
BOF. That BOF considered the issue of trust anchor management very broadly. It was decided that a more narrowly focused effort, emphasizing X.509 certificates would be an appropriate first step, thus this work became an activity for the PKIX WG.  Initially, the document also included material now found in the Trust Anchor Format (TAF) document. The working group favored separate documents for protocol specification and format specification. This I-D contains the former.  This draft was not particularly controversial, but a number of significant changes resulted from working group discussion, including
specification of how to use the protocol over HTTP.

Document Quality

The document is reasonably well-written and clear. I have been told that an open source implementation is being developed.  The most common format used to represent a trust anchor today is a self-signed certificate and this format is accommodated in this document.