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 summary of the review is Ready with nits.

The Security Considerations look OK.

I'm not that familiar with the corner of public key infrastructure
covered in this draft. However, my understanding is that signing a
strong hash of a digital object verifies the object to the extent that
the signature can be verified regardless of how the object is
obtained. So I found it curious that, in this case, if there is a
filename associated with the hash in the signed checklist but the
object was not from a file or from a file with a different name, then
verification is required to fail.

Nits/Trivia:
-------------

In Section 5, Page 8, the possible disadvantage of so specially
calling attention to Section 4.4.1 is that it implicitly reduces, even
if only a small amount, the emphasis on the rest of Section 4.
Possibly the following change which also has the advantage of being a
bit shorter:
OLD
   1.  The contents of the CMS eContent field MUST conform to the
       constraints described in Section 4.  In particular, for each
       FileNameAndHash element in the checkList field, its contents MUST
       conform to the constraints described in Section 4.4.1.
NEW
   1.  The contents of the CMS eContent field MUST conform to all of the
       constraints described in Section 4 including the constraints
described in Section 4.4.1.

Section 7, first sentence, Grammer:
OLD
   When creating digital objects of a plain-text nature (such as ASCII,
   UTF-8, HTML, Javascript, XML, etc) it is RECOMMENDED to convert such
   objects into a lossless compressed form.
NEW
   When creating digital objects of a plain-text nature (such as ASCII,
   UTF-8, HTML, Javascript, XML, etc) converting such
   objects into a lossless compressed form is RECOMMENDED.

Section 8, Page 11 at beginning of last paragraph: "an one-time" -> "a one-time"

I notice that the IANA "SMI Security for S/MIME CMS Content Type
(1.2.480.113549.1.9.16.1
)" registry entry for id-ct-signedChecklist references an old version
of the draft. Presumably IANA will fix this as the document
progresses.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com