Some of the recent traffic has raised the question of using the
pem-mime draft as the basis of protecting both mail and other
objects. In addition, one of the goals (I believe) of this
pem-mime approach was to provide greater flexibility in
handling signature and encryption "transformations/encapsulations"
(along with the flexibility in name-forms and canonicalization).
It appears in reading the drafts that the goal of providing
this flexibility is not met. The definitions for the multipart/signed
and encrypted types still rely on sequential encapsulation, as with
RFC1421 pem. The ability to apply two signatures to an object (or part)
seems to require one multipart/signed structure encapsulating a
second multipart/signed structure.
This is simply not the case. As Jim already pointed out, all you have to do is
specify a signature protocol that provides for multiple simulteneous
signatures. I would actually prefer to see this done using a generic MIME
structure, however, rather than by defining a composite signature type. The
problem with atomic objects containing composite signatures is the potential
for a combinatoric explosion of them if the number of signature mechanism gets
large.
For example, you could have something like this:
Content-type: multipart/signed; micalg="a,b,c...";
protocol="multipart/multiple-signatures"
--outer-boundary
Signed object
--outer-boundary
Content-type: multipart/multiple-signatures
--inner-boundary
Content-type: first-signature-type
First signature.
--inner-boundary
Content-type: second-signature-type
Second signature.
--inner-boundary--
--outer-boundary--
The really interesting question about this sort of stuff is what the semanics
of it are. Is the object considered to be signed is the recipient can only
verify one signature and lacks the software to verify the other? What does it
mean if one signature verifies and the other fails verification? I presume
these semantics would be specified as part of the definition of the
multipart/multiple-signatures object. (Note, however, that use of parameters to
specify the sematics is NOT a good idea, since the semantics specified this way
are not themselves protected by the security wrapper.)
This limits both the semantic
and operational capabilities, especially for general object protection,
and also for messaging. For example, if I create a document with
another author and we want to both sign the document while also
obtaining a timestamp from some server, it seems difficult/impossible
to convey this within the mime/pem spec without either imposing
sequentiality or replicating the signed data.
Case A (current spec) ((((Doc) time signature) author1 sig) author2 sig)
Case B (goal?) Doc (id=1), time sig (1), author1 sig(1), author2 sig(1)
Frankly, I think that in this case the best approach would be to sign the
document sequentially. In particular, it seems to me that the time stamp should
itself sign over the author's signatures, since if it doesn't you have no idea
when the authors actually signed the object. You do know that the object
existed at the time the timestamp was applied, but most uses of timestamps I'm
envision are to show that something was signed at a particular time, not that
it simply existed at a given time.
But the existing MIME-PEM specification most certainly does not prohibit the
scheme you describe.
Other scenarios involve cases where a signed message is sent and
several others want to add comments/annotations with signatures
covering the original message, original signature, and new
comment. Again, it appears difficult to represent these cases.
This really has nothing to do with the signature mechanism per se, but as
a matter of fact MIME does provide for this sort of thing. In particular,
MIME supports the idea of references between parts of a message. This basic
mechanism could then be used to build an annotation/commentary facility, where
pointers into an inner signed object are used to get the desired effect
without disturbing the checksum of that object.
Some of these limitations seem to arise from MIME's treatment of
boundarys. A solution which assigned unique identifiers to parts of
messages combined with explicit listing of those identifiers in the
signature part could greatly expand the utility and flexiblity of the
MIME/PEM concept.
As a matter of fact I've looked at this approach in some detail, and while it
is slightly more flexible than the present scheme it has a large number
of undesireable attributes that render it unworkable in practice. These
include:
(1) Processing is vastly more complex, involving an arbitrary number of passes
over the message. I view this as an extremely major limitation.
(2) The resulting entities are so complex users will not be able to understand
their semantics. The present MIME-PEM scheme is bad enough in this regard,
in that describing the nature of a multi-leveled security enhancement to
users in a comprehensible way is fairly problematic. When you add the
ability to sign multiple parts on a part by part basis, in any order,
with multiple partially overlapping signatures, things gets REALLY messy.
(3) There are problems protecting headers. I don't want to get into the
details of this unless someone really cares, but suffice it to say that
the only way I could see to get the necessary flexibility in this regard
was to use even more encapsulation levels and multipart structures.
(4) There are MAJOR problems with MTAs and gateways. Again, it is not beyond
possibility that the existing specifications will prove to be problematic,
in that we're asking gateways to treat multipart/signed objects (and
preferably multipart/encrypted objects) as atomic. There are very real
deployment issues here with the present scheme, and only time will tell
whether or not it is workable. But complicating things to the point where
you have to scan the entire message looking for signature objects, then
examine those objects to see what parts they protect and treat those parts
as immutable goes much too far. As a matter of fact, there are cases where
gateway will never know what to do -- suppose you encrypt one of these
signature so its contents are not visible to the gateway. What does the
gateway do in this case?
I believe that Ned mentioned offline some
possibility of addressing boundary issues in the general MIME context.
Quite possibly.
The questions I would like to raise (and started to raise at the
PEM WG mtg) are:
1) Is there a flexibility contained in the MIME/PEM or general MIME
specifications which I'm missing.
Yes. Lots of it.
2) If not, is it important to try to incorporate such flexibility into
the approach, especially if wider applicability (beyond messaging) of
the draft is intended. (note: I think this question is closely tied
to the object security requirements question?)
I would like to reiterate Dave Crocker's comment at this point. We are late.
In fact, we are very very very late. We need to get something out that is
workable, and we need to do it now. It is nice to sit around and think about
vastly more complex and flexible security mechanisms, but we need something
that can be implemented now that solves a reasonable subset of the problems
we face.
One final point. There is nothing to prevent the definition of a MIME
security mechanism along the lines you propose that could exist in parallel
with multipart/signed and multipart/encrypted. As such, if you are really
interested in definining such a thing, I think the proper course would be
to go ahead and do so and see how it turns out. But we need to proceed with
the existing MIME security facilities regardless of how such an advanced
effort turns out.
Ned