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 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)
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.
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. I believe that Ned mentioned offline some
possibility of addressing boundary issues in the general MIME context.
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.
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?)
Dave