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.
The language here is actually slightly more restrictive than the examples I
have pointed out previously. However, the bottom line is that you are once
again confusing the specification of the meaning a single instance of use with
an explicit prohibition of other forms of use. If you want to prohibit certain
forms of use you have to say so. If you do not say so and the forms are
syntactically valid they are completely legal.
The English language contains ample facilites for doing this sort of thing, yet
I see nothing in RFC1421 that says you cannot use the facilites RFC1421
provides to sign something more than once. If you want to prohibit such
use you have to do it explicitly.
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.
Ahh. I always love it when discussions like this devolve into statements where
the intent of the writers is to be indirectly inferred by the location of
certain prose in the document. Let's be honest and face up to the fact that
RFC1421 provides for even more of the sort of services you dislike seeing in
MIME/PEM. This "little man on the stair" really is there, I'm afraid.
On the other hand, if you are right about this (you have yet to produce any
prose to demonstrate this), then I claim that you have effectively nullified
the issue you have with MIME/PEM as well, since MIME/PEM is currently aligned
with RFC1421 in this area.
Ned