4.2.3.2 Processing for SignedData
Q. Step 2 of this process has been changed from the
Internet draft version (draft-ietf-smime-ess-09.txt). It
seems that now if the "outer" signed data layer is absent
or does not contain an mlExpansionHistory attribute, the
MLA simply adds a new outer signed layer, lists itself in
the mlExpansionHistory attribute, and sends the message to
the recipients. It would no longer expand any encrypted
data for the recipients. If someone sent a message that
was encrypted then signed to the MLA, the recipients would
not be able to decrypt it. Have I misread this paragraph?
[JSP: You have misinterpreted the paragraph.]
Did I also misinterpret the flowchart (quoted below)?
1. Has a valid signature?
YES -> 2.
NO -> STOP.
2. Does outermost SignedData layer contain mlExpansionHistory?
YES -> Check it, then -> 3.
NO -> Sign message (including outermost SignedData that
doesn't have mlExpansionHistory), deliver it, STOP.
It seems clear that the MLA would not expand encrypted data unless the outer
signature is either absent or that of an MLA.