In the case of a quasi-static relationship, e.g., a baseline document,
source
code, etc., the connection between the "message" (the linkage editor include
cards, by analogy) and the individual objects could be established and
confirmed by referencing the message digest of the individual signed
objects,
so that ultimately you could build a digitally signed and verifiable bill of
materials for an entire software build, for example.
PKCS #7 offers a good precedent for using a message digest to refer to
an external part. This appears when signed attributes are used. If
you have some text, but want to add attributes like signing time, you
create an attributes object which has the signing time as well as a
*digest* of the associated text. Then the signature is computed
simply on the attributes object, and the text is implicitly signed via
the digest. In this analogy, the attributes object would be like the
main form and the text would be referenced and authenticated by
including its message digest.
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