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.
Sigh. I cannot believe the direction this debate has taken. Now you're saying,
in effect, "Well, it may be somewhat ambiguous about this, and you have to read
the entire thing and then try to figure out what the intent of the authors way,
but hey, its better written than some other documents that have become
standards."
Excuse me, but this is bullshit of the highest order. The fact that other
standards documents are poorly written is totally irrelevant, and does not
excuse this one being ambiguous in this way. I am again amazed that someone who
purports to seek clarity and precision in specifications would have the
unmitigated gall to say such a thing.
But this entire discussion is completely irrelevant anyhow. Let's suppose for a
moment that I buy your argument, and agree that multiple signatures are
precisely defined in the classic PEM specifications.
It then follows that since the mechanisms currently (note this word) provided
by the MIME/PEM specification are precisely defined as well, since they are
simply a repackaged version of classic PEM. There is no, repeat NO, additional
multiple signature mechanism provided by MIME/PEM that isn't already in classic
PEM. Period!
As such, you are effectively arguing that the mechanisms in MIME/PEM are
specified well enough -- you're arguing against the position you took that
started this entire thread.
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.
Well, I could say that you have now presented arguments to the effect that
this sort of thing is perfectly acceptable.
However, the reality is that I absolutely disagree with this assessment. I
think the new specifications are absolutely clear about what has changed and
what has not. There is even a section that describes each change specifically.
If you think this is unclear, then you need to suggest specific areas where
it is unclear that need to be addressed. Additional, given that this is
last call, I think it is only appropriate for you to additionally write
the specific prose you think needs to be included to clarify these matters.
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.
On the contrary, this is exactly the point I keep coming back to. My counter is
simply this: The MIME/PEM specifications currently (note the word) don't
provide any multiple signature mechanisn that isn't in classic PEM. So where's
the problem?
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!
Please. This is obvious. I am not an idiot, you know.
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.
And this is precisely the intent of the current MIME/PEM specification as
well.
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.
And this is all irrelevant since there is no such facility currently (note
the word) in MIME/PEM. There may be such a service in the future, at which
point these issues can be dealt with.
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.
In case you haven't noticed, MIME isn't just for email. By allowing the
insertion of modular security elements into MIME we provide exactly the sort of
building blocks you're talking about here.
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.
It is not bullshit and you know it. You know as well as I do that the
forwarding of signed objects is an absolutely essential service in secure
email. Secured messages that cannot travel through regular email channels
simply are not generally useful. As such, at least some level of nesting has to
be allowed or the service is uninteresting to say the least. Classic PEM
*specifically* condones such usage. It has to. And MIME/PEM provides the same
sort of nesting. It has to as well.
Ned