Ned,
I think the text in 1421 is pretty clear about the question of
multiple signatures. I admit that it requires reading the while
document, but the whole document is pretty well written (thanks to the
efforts of John Linn) and certainly a lot shorter than some other, not
nearly so well written documents that have become standards.
This isn't all that complex an issue, despite your
protestations to the contrary. The syntax allows multiple signatures,
but the text says under what circumstances these multiple signatures
may occur. It is explicit about the allowed use of multiple
signatures and, unlike many standard documents, even provides
motivation for why this "exception" to the normal case is provided.
If you don't feel that the language is sufficiently explicit,
I'm sorry. Perhaps it could have been more explicit, but I don't
think it is ambiguous. I know of no standards (Internet, ISO, or
otherwise) that are completely free of ambiguity, but we did try hard
to do a good job with PEM and, compared to many other Internet
standards I feel PEM is pretty good. However, your characterization
of my explanation as an attempt to justify what I want to be true,
irrespective of what the spec says, is not supported by the cited
text. As for whether MIME-PEM mimics 1421 in this regard, I think
that may be hard to tell from the curent spec. The problem with
writing this spec as a delta to 1421 is that there are enough changes
to make it hard to tell where the constraints of 1421 apply and where
they have been supercered.
Ned, I think the point of this discussion has been lost. I
merely stated that a generic provision for multiple signatures,
without explicit provision for interpreting them (dare I use the term
"semantics" any more?) are a bad idea. In PEM, we tried to provide a
secure verison of email, in which the many (though not all) of the
security services that one might ascribe to a benign email environment
would be available in a hostile environment. There are no signatures
in vanilla email! The purpose of signatures in PEM is to authenticate
the sender of the message, the identity that one would nromally
associate with the From or Sender field in a message. There was no
intent to introduce new semantics (whoops, I used the word anyway)
through signatures. Nested signatues are provided in PEM specifically
to allow for forwarding of signed messages.
I did not say, at the beginning of this thread, that it is
inappropriate to create a facility to support multiple, parallel
signatures. But I don't know how to relate such signatues to vanilla
email. If such signatures do not parallel an existing facility in
email, then I think it is appropriate to explicitly define the meaning
of such signatues, since the facility represents a new capability. As
I noted elsewhere, in other applications, applications that may be
mail-enabled, there are well-defined sematics (oops, there I go again)
for multiple signatures. However, it is not clear that relying on a
MIME-PEM facility to provide such signatures is the right solution for
these apllications, since that would unduly tie the application to the
use of email.
I must admit that I have slowly changed my view in this area
over time. I still view secure email as an excellent vehicle for
providing a base level of security for some classes of applications,
but I no longer feel that these applications should become too tightly
bound to the security features of email. Ongoing work in the area of
object-oriented security mechanisms, and work in other venues with
similar goals, moves in the direction of providing flexible security
facilities that are not email-oriented and thus can avoid some of the
pitfalls of trying to be everything to everybody.
You also argue that if PEM prohibits multiple signatures by
different signers (without nesting), then it is too limited to be of
use. Well, how can I say this politely? BULLSHIT? Yes, I think that
captures the flavor without being unduly harsh.
Steve