Sandy,
You cite the discussion in 4.6.2.1 and 4.6.2.3 as supporting
the contention that PEM allows for multiple originator signatures,
with the impression that these may be different individuals. The
heading for 4.6.2 is "...Header Fields Normally Per-Message," which
is a hint. 4.6.2.3 states:
A "MIC-Info:" field will occur after a sequence of fields beginning
with a "Originator-ID-Asymmetric:" or "Originator-Certificate:" field
and followed by any associated "Issuer-Certificate:" fields. A
"MIC-Info:" field applies to all subsequent recipients for whom
asymmetric key management is used, until and unless overridden by a
subsequent "Originator-ID-Asymmetric:" or "Originator-Certificate:"
and corresponding "MIC-Info:".
This makes it clear that only one MIC-Info field appears per
Originator identifier field. I assume that your argument that
multiple MIC-Info fields are legitimate derrives from the last
statement, i.e., that another MIC-Info field can appear only after
another Originator identifier field. However, 4.6.2.1 states:
Multiple Originator-ID and/or "Originator-Certificate:" fields may
occur in a message when different originator-oriented IK components
must be used by a message's originator in order to prepare a message
so as to be suitable for processing by different recipients. In
particular, multiple such fields will occur when both symmetric and
asymmetric cryptography are applied to a single message in order to
process the message for different recipients.
So, the normal case is that there is exactly one MIC-Info field per
PEM-protected message (i.e., at the top level), and the ONLY
circumstances in which multiple fields are allowed appear are those
where they are REQUIRED for processing by different recipients,
specifically in the context of mixed use of symmetyric and asymmetric
key management.
If the intent had been to allow multiple instances of MIC-Info, in the
sense you argue, then MIC-Info would logically appear in section
4.6.3, the section that defines fields that may appear multiple times
in a PEM header. The very limited circumstances under which MIC-Info
is allowed to occur more than once in a message were described in the
relevant sections.
You also cite the BNF syntax at the end of the RFC. The limitations
of this sort of notation, and of ASN.1, are well known and that's one
reason that people provide descriptive text to complement the syntax
notation. One should always read such notation in context.
Steve