First, let me say that I have committed the time-wasting error or
arguing a point that is not relevant to the subject matter at hand.
MIME-PEM allows for different originator fields, including MICs, in
exactly the same manner as RFC 1421 does. If what RFC 1421 defines
is a multiple signature, then so is what MIME-PEM defines. If what
RFC 1421 defines is not a multiple signature, then neither is what
MIME-PEM defines.
That said, I just can't resist countering the answer to my message.
Steve Kent has said:
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.
(a) I have said "RFC 1421 permits this." You have said "In the normal
case it does not happen". So? Countering an existential statement
with a statistical expectation is not valid.
(b) As I have said before, when a spec motivates a feature by a particular
expected use, the feature is not restricted to only that motivational use.
To say that these are "the ONLY circumstances in which multiple fields are
allowed" is forcing a stronger interpretation on the paragraph than is
warranted.
(c) Even your strong interpretation of the paragraph (how I do wish it
had been stated in some unambiguous notation, like, dare I say, math)
does not counter my contention that ambiguity can result even in RFC
1421 type multiple signatures, unless you also maintain that:
(i) any recipient may appear only once in the headers AND
(ii) implementations are forbidden to verify any MIC other than one
which is associated with the recipient (in the MIC-Info field
following the preceding originator for the asymmetric case, in
the following Key-Info field for the symmetric case).
(i) is difficult to enforce if entities who receive a message have
more than one possible identifier. Since symmetric ID's contain an
Entity Identifier which is an e-mail name (i.e. not a DN like the asymmetric
ID's), even the strong interpretation would be hard put to enforce (i).
I stand ready to be corrected by those who know the spec better than I that
(i) is indeed required. But I cannot believe that (ii) is in there -- surely
I would have remembered that!
Consider the case that Steve is sending a message to all his group
members, with whom he can communicate with asymmetric cryptography.
Because the message concerns work requirements, he also wants to send
it to the local union leaders, which whom he communicates with
symmetric cryptography (perhaps separtately, perhaps through a mailing
list). Unbeknowst to him, Sandy in his group is also the shop
steward. There are two MIC's in the message (at least), one for the
asymmetric group and at least one for the symmetric group. Sandy has
the ability to verify both when she receives the message. If she does
verify both, then the possibility exists for an ambiguous result
because one MIC verifies correctly and the other does not. To prevent
the possibility for an ambiguous result, you would have to ensure that
Sandy appeared only once on the recipient list (hard when one recipient
is a Recipient-ID-Asymmetric pointing at a certificate and the other
is a Recipient-ID-Symmetric which has a e-mail name form, even harder
when one recipient is a mailing list) and that Sandy's software does
not attempt to verify any MIC's other than the one associated with
her Recipient-ID.
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.
The purpose of a formal notation is to remove the ambiguity of the
natural language. It is always possible to say something exactly in a
formal notation that is other than what you intended to say. But then
you fix the formal notation, you don't point back at the ambiguous
text. Relying on the text to disambiguate the formal notation is IMHO
a bad approach. Note, for example, that you and I have a very different
interpretation of what the word "may" means in the section of the spec
which you quote. To what do we now appeal to settle the question?