Hi, 

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

The main issue I have is the absence of security considerations ;-), but otherwise the text appears to me quite clear. I will review the document once the security consideration is completed.

I do not see the document mentioning any sort of negotiation which limits the scope of possible downgrade attacks or the ability from one party to "orchestrate" in some ways, what the other party. In other words, if I did not missed anything the signature is a local policy. This typically means that a client may sign while responses may not be signed.  Section 1.5 defines what needs to be agreed between multiple parties, but does not provides details how this could be achieved.

Some very minor editorial comments.
section 1.4
<mglt>
   The qualified term "digital
   signature" refers specifically to the output of an asymmetric
   cryptographic signing operation.

May be that would be clearer to define digital signature before mentioning "signature" is used for both digital signature and Keyed MAC.  
</mglt>


section 1.5 
   *  The set of content identifiers (Section 2) that are expected and
      required. 
<mglt>
I suppose that the content are security related, but it is unclear at least to me at this stage if the content have any kind of limitation. Typically, if a party is able require an specific header that leaks private information, that may be an issue. I think the text might be able to clarify this.  

Though I expected it to be detailed later and "expected" security related information is always suspicious of ending in a best effort situation where security is optional. These are simply what come to my mind when reading these lines. There is no necessary some actions to be taken if you believe that is not necessary.   
</mglt>

section 2.4
<mglt>
   If covered content references an identifier that cannot be resolved
   to a value in the message, the implementation MUST produce an error.
   Such situations are included but not limited to:

   *  The signer or verifier does not understand the content identifier.

   *  The identifier identifies a header field that is not present in
      the message or whose value is malformed.

If the value is malformed, it may indicate that the value is interpreted previously the integrity has been checked. I am sure this is not what the text is meaning, but this is how I read it, so I believe that some clarification may be needed. 
</mglt>