Paul, thanks for noticing that. Most of the discussion concerned
"what is a conformant message", i.e. what must the sender do to conform.
The requirements on receivers are important too. Jim's original
text included:
Additionally, a client
SHOULD NOT allow access to the mail if it cannot verify at least
one of the SignerInfos which contains the security label.
I'm at a loss to recommend what a receiver should do if it receives
a message that is illegal as a result of non-cryptographically-protected
information. Since anyone can add and delete outer signatures, it
doesn't seem right to deny access to the mail if the recipient or
any third party could massage the message into conformant form.
If the S/MIME spec is allowed to recommend User Interface behavior, I'd
say:
"If any of the SignerInfos includes a security label attribute,
then all of the SignerInfos MUST include the security label
authenticated attribute, and the value of each MUST be identical.
A client SHOULD warn the user if a message not meeting this
requirement is received."
In a cursory scan of the CMS and MSG drafts, I didn't come across
any requirements on receivers. The following probably belongs
in the MSG draft if we are going to make UI recommendations:
"A client SHOULD warn the user if it cannot verify at least one
of the SignerInfos in a SignedData.", or
"A client SHOULD warn the user if it cannot verify all of the
SignerInfos in a SignedData."
If we say "SHOULD NOT allow access", and the user can get access
simply by deleting a SignerInfo, the S/MIME spec doesn't pass the
laugh test.