However, I think it is perfectly acceptable to leave the meaning of
multiple signatures up to the recipient.
It is acceptable, but the present scheme allows for other approaches, at least
as far as some aspects of "meaning" are concerned. Suppose I as a sender and
co-signer of a message make some sort of assertion as to the meaning of
multiple signatures. Such an assertion has to appear within the content of a
signed object in order to be of any value, since any such assertion that is
added outside signed content could have come from (or be removed by) anyone.
Given that such assertions have to be part of the signed content, they really
are quite independent of the outer security framework that carries the actual
signatures. As such, their definition can be (and should be) separate from the
outer security framework. And a wide variety of assertion formats are possible,
including things as simple as a sentence stating that "this has to be signed by
both X and Y to be valid" or as complex as a MIME object that is defined to
carry such information in a machine readable format.
However, all this borders on the often-discussed question of what a given
signature or set of signatures actually mean in terms of the model of trust.
Just because something is signed by two parties and internally asserts that it
needed to be signed by two parties doesn't mean I should trust it more than
something with only one signature.
I disagree with this statement. I think a general solution for
signature handling of objects/messages must allow a user to
unambiguously assert the meaning of signatures applied to collections
of information and other signatures. This is particularly
important if mime-pem is to serve as a building block for protected
objects.
This has nothing to do with multiple signatures per se -- it is entirely a
trust model issue. And in fact I would tend to disagree with your assessment
that assertions require detailed treatment before MIME-PEM can be used as a
building block. A detailed treatment is in fact the last thing we need, since
once we specify one particular meaning or set of meanings (especially ones
based on zero experience with the protocol) we implicitly restrict the scope of
MIME-PEM and lessen its value as a building block quite dramatically.
This is not to say that assertions as to the meaning of signatures can simply
be ignored. But I firmly believe we must learn more from operational use of
these mechanisms before we'll be able to say anything useful in this area.
In light of Jim's comment on flexibility for multipart signature
and your comments above, I think it is useful to explore defining
(or exploring the ability to define) other unambiguous structures
which represent signature intent. The ability to do so is, I
believe, an essential element in validating the base proposal.
I have no problem whatsoever with trying to define structurs to specify
signature intent. However, I have a MAJOR problem with tying this to the
"validation of the base protocol". It is a separate matter, and moreover one
that can only be done in a meaningful way once the base protocol is in place.
The other architectural issue, which may more properly belong in the
MIME discussion forum, is the need/ability to uniquely identify
objects/parts/messages and to explicitly indicate such linkages in a
candidate alternative signature structure.
I have already commented on this in my previous response.
I think this topic is largely complementary to the core pem discussion
and may move to an object security discussion, but I believe the
utility of the basic approach can be enhanced if we all agree
on common, unambiguous ways to representy common semantics.
I am in complete agreement with the idea that this is complementary to the
core PEM discussion. However, I cannot reconcile your assement that this is
necessary to validate the base protocol with the idea that the two things
are complementary.
Ned