This service is already offered in the form of a messasge/external-body that
includes an RFC1544 content-md5 header field (there's an important limitation,
however, that's described below, along with one way to lift it). However, this
isn't the service that the original dicussion was about -- that service was one
where the content could be updated by the signer without invalidating the
signature on the message. Such a service requires that the message contain
contain a reference to an object which has its own signature, as well as
information about what keys can be used to sign this external object.
Using the Content-MD5 header for the simpler case of an entirely static
reference is quite straightforward. Since the headers of the external object
are part of the message, not the object itself, all you have to do is include a
content-md5 header computed over the object. Simply, easy, and very effective.
There is one problem, however. As currently specified, a content-md5 header can
only apply to a leaf (atomic) object. In particular, it cannot apply to
multipart object or message/rfc822 objects, which in turn means that
there's no digest facility currently defined for external objects of these
types.
A related problem is that you really don't want the separation between the
headers and the body that message/external-body insists on when you're dealing
with multipart and message objects. It is far better for this material to be
grouped together when dealing with static but composite objects, and it is
essential if any scheme that allows for dynamic replacement. Note, however,
that the current scheme works is what you want for static and atomic
objects.
Both of these problems are solved by introducing a new subtype of either
application or message whose contents are themselves defined to be a
MIME object of some sort. This is quite different from message/rfc822, where
the contents are an RFC822 message, which in turn may contain a MIME
object.
This new type, which is what I was referring to in my earlier messages, would
explicitly allow for a content-md5 header, and thus both problems would be
resolved.
Ned
That seems pretty neat. I'm unclear, however, whether this would take the form
of a
change to PEM/MIME, or to MIME itself. Are you proposing or prepared to add this
this at this time?
Do you intend to address the issue of the trusted bind/reference to a remote
object
at the same time? (And again, I'm not sure exactly where the changes would go.)
Bob