RFC 1847:
The signature in a multipart/signed only applies to the material that
is actually within the multipart/signed object. In particular, it
does not apply to any enclosing message material, nor does it apply
to entities that are referenced (e.g. via a MIME message/external-
body) by rather than included in the signed content.
also see:
http://www.netscape.com/assist/net_sites/dynamic_docs.html
As a potential multipart/signed developer, once again Ive been considering the
interaction of multipart/signed and an SSL/HTML protocol. You may wish to
refer to
a previous thread on embedded secure URL and a discussion of non-repudiability
of message content origination proofs. The protected message content
can be financial or payment transactions, else dynamic or static
compound documents, else a host of more simple mime content types.
Consider the WWW browser developments from Netscape in which, by
collecting up all the https referenced parts of the compound HTML
document, a user can be made aware of the security status of the
https-sourced document. This information comes to users in the form
of (a) a summary status for the document, including its references to
elements (b) detailed security attribution for each logical
element of the specific document.
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.
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.
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.
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?
My own answer to my own questions is (perhaps wrongly) that this
interplay specifically lies outside the semantics of multipart/signed.
(for anyone who is interested in fun: the problem being faced is to bridge
ssl-authentication and message-based proof of origin with non-repudiation
services. Consider the circumstance where I accept a stock quote, from
a WWW server which uses dynamic html META document elements to update pricing
info. And now the broker wishes to prove (after a dispute) the price acceptance
terms in the consumers signed message used to convey the payment instructions
and time-stamped offer/acceptance contract terms.)