Now lets say, someone mails me the same document as a mime message using
content type text/html interchange format. And then we all use the
multipart/signed infrastructure to digitally sign/verify the message.
The mime/HTML UA then presents the document to the user.
AS I understand it, for references in the html content (as with references in
any mime externalbodypart content types) the digital signature service
makes no asssertion ( and never, ever can, by definition) regarding the
properties of the html document and its own secured compound architecture.
So even if the browser goes off an obtains the document elements,
the signature shall make no statement regarding the element content,
or the reference.
This is probably correct in the case of a URL, since I don't know how to
associate any sort of checksum with a URL. (There may in fact be a facility to
do this in a URL but it exists I don't know what it is.)
But this is *not* the case with message/external-body. I've tried to make
this clear, but apparently I have failed to do so.
Specifically, the content-md5 field (RFC1544, with the draft standard version
approved and awaiting RFC publication) can be used to provide a checksum of the
referenced object. This field and its associated checksum value appears
*within* the signed content so it cannot be tampered with without causing an
alarm.
There is now text in the content-md5 document that specifically describes
this usage.
In other words, there's a two step process here. The content-md5 header
provides a checksum of the referenced material, and in turn is incorporated
into the signed material. You cannot change the referenced material without a
checksum mismatch, and you cannot change the checksum without breaking the
signature.
There are two limitations placed on this mechanism:
(1) It is not well defined for references to multipart entities. This is a
result of content-md5 only being technically valid for a leaf entity.
Extending it to handle external-body references to composite objects would
not be at all difficult, but it hasn't been done.
(2) Content-MD5 is bound to a single checksum scheme (MD5 obviously). Should a
need arise to use a different scheme (e.g. SHA) a new field would have to
be defined for this purpose.
I do not believe either of these limitations are especially important in
practice. (1) can be worked around by putting the structure in the message
proper and only referencing leaves as external bodies. I believe this is the
right way to do it anyhow. And (2) only becomes cricical in the event of
a flaw being located in MD5. This has not happened to the best of my
knowledge.
Is this true, by specific intent of the designers? AS I understand
the designers' intent, all html2&3/message interplay scenarios are
specifically
excluded from the multipart/signed architecture. I infer this from the quoted
text above.
The intent of the designers was to have the multipart/signed signature only
cover the material in the message *directly*. There are a variety of reasons
for this, the most important being that it should be possible to verify the
signature without retrieving all external objects. Suppose you have a
multpart/alternative inside the signed object, each part of which consists of a
different external entity, and access to either of the external entities is
mutually exclusive, that is, some can reference one alternative, others can
reference the other alternative, but practically nobody can reference both.
(This is actually not that uncommon of a case.) If external bodies were
included in the signature the result would be a signature that nobody can
verify. This is clearly not good.
But since that material can itself include checksums on external material,
thus providing an *indirect* signature, its easy to extend things so that the
signature effectively covers more than just what is present in the body. And
the mechanisms are already in place to do exactly this in the case of
message/external-body. In fact this mechanism is already well down the
standardization path -- multiple interoperable implementations have already
been demonstrated as a prerequisite to obtaining draft standard status. (PMDF
was one of the interoperating implementations.)
To the concrete example, then, it is not the case that the digital
signature on the message has the same authentication/origination semantics as
the authentication of the document originated in the protocol I
described above?
This is what I understand from the MOSS RFC. Please correct if
wrong. Im trying to understand the implications of that piece of quoted
text in the context of both dynamic and static documents expressed using
multipart/mixed and multipart/alternative.
Peter, I've tried to explain this to you at least three times. I must be
doing something wrong here since its obvious you still don't see what I'm
getting at.
The use of a URL inside of an HTML document is an interesting case we haven't
looked at before. In order for the content the URL references to be secured by
the message signature there would have to be a way to embed the expected
checksum value inside of either the URL or else the HTML document containing
it. I would like to see a sort of meta-URL defined that included a checksum
and a conventional URL inside of that.
Particularly Im trying to understand the implications of MOSS
with regard to multipart/mixed where a mixed bodypart can
be a dynamic document. Whilst it seems unlikely that any store-and-forward
message signature process will ever authenticate a dynamically
changing content, the issue is: what relationship is there between
the message signature and references in the multipart/signed
architecture?
See above. The relationship in the case of a message/external-body is what you
make it. If you don't provide a checksum the external document can change
without there being any indication of that change. If you do embed a checksum
the external document cannot change without invalidating that checksum.
Note that this isn't always good -- HTTP in particular provides a means by
which different documents can appear as a result of deferencing a single URL.
Similarly, a CGI script is likely to vary every time, so a checksum for it is
meaningless.
My own answer to my own questions is (perhaps wrongly) that this
interplay specifically lies outside the semantics of multipart/signed.
It lies outside of the direct semantics of multipart/signed, but not outside
the semantics of MIME in general. And since multipart/signed signs MIME objects
in toto (and so does S/MIME for that matter) the semantics of MIME are
indirectly inherited by multipart/signed, including those of content-md5.
Ned