Document: draft-ietf-smime-multisig-04.txt
Reviewer: Elwyn Davies
Review Date: 7 March 2008
IETF LC End Date: 7 March 2008
IESG Telechat date: (if known)

Summary:
Mostly fine except for a piece of unclear specification noted below and a few 
editorial nits.
Caveat: I am not a security expert and this should not be taken as an endorsement 
of the security competence of the proposal.

Comments:
s3:  The first part of the specification for MultipleSignatures is :

>    The fields in MultipleSignatures have the following meaning:
>
>      - bodyHashAlg includes the digest algorithmIdentifier for the
>      referenced multiple-signatures attribute.
>
>      - signAlg includes the signature algorithmIdentifier for the
>      referenced multiple-signatures attribute.
>
I am confused by the use of 'includes' here: Do these specs imply that the values of 
these fields are comma separated lists of all relevant alg identifiers for the 
signatures?  An example with three signatures might clarify what is going on, 
but the spec should be clarified in any case, I think (but I may just not be 
sufficiently knowledgable about this sort of spec).
 

Editorial:
idnits reports a clean bill of health.

Abstract: Expand CMS acronym.

s5: s/in a singled/in a single/

s5.2: s/the rquire application/the required application/

s5.3, para 5: The first sentence
>
> If signatures are added for the support of [ESS] features, then the
>    fact that an outer layer signature can be treated as a non-
>    significant failure.
>
does not parse.  Probably missing 'is invalid' or some such relating to outer layer signature.


Appendix B: 'hashes CMS'??? Does not parse!

B.1: s/is needed/are needed/

B.2 1/a/ii: s/Reistance/Resistance/

B.2 1/c/iii: s/success/successful/

B.2 2: Expand DER acronym.

B.2: is not normative but uses SHOULD NOT.

B.2 (2nd para on p18): s/that the attack/than the attack/