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.
Ned, thanks for the time spent to write the long memo on the notion
of content-md5 and the external-content integrity service it provides.
Let me try one final time to distinguish between this integrity assertion,
and what Im after - which is an "origination assertion" for the document
components. After this, I shut up on pem-dev about this topic.
When I assert in a signed message that a bodypart is to use an access method
to communicate with www|ftp.cs.ucl.ac.uk to retrieve data source
pub/price.rtf, it is the proof that pub/price.rtf is supplied by
www|ftp.cs.ucl.ac.uk that I wish to check/audit. (Yes, here I assume my access
method provides for server authentication). (See "a simple hole" debate
on ssl-talk for ongoing context here)
And I dont want the signature on the enclosing memo to validate, until the
origination of each of the consituent components has been proven to
that of the servers/sources originally quoted. That is, the proven sources
(www|ftp.cs.ucl.ac.uk) shall be - in realtime fact - the same as the values
in the
parmeters of the external bodyparts.
I already have this service with Netscape and multi-session SSL. Now I want
it with protected email documents bundled all together with the Netscape
stuff. We have modern RFCs for email security now, so therefore I try to
*use* them to build a system we are interested in commercially.
Here is a specific example:
copper broker sends offer to client saying Ill deliver 1 tonne of copper
next week, if we agree on a 104.987% * price per tonne established by the
commodity
copper exchange noted in this offer document. I want that the email system
to only
assert that the signature on the offer validates (and if the offer is encrypted,
to only then present the offer cleartext to the user) when the copper exchange
denoted in the offer sucessfully authenticates itself in realtime as *the*
source of the pricing element of the document. I dont care
about the (variable) price text itself, only the source of the document
component; and I dont care if the user chooses to ignore the memo by
refusing to authorize the externalbodypart referral. Like navigator, I
want originator match to go without special user indication, whilst non-match
to be flagged to the user for special further evaluation.
If I choose to combine a MIME protection service with a MIME
content type which refers to some source, I understand this to mean
that the source must be authenticated before the memo signature can be
validated; with, or without, the additional integrity service of
content-md5. Otherwise, you have the DNS spoofing attack outlined
by
I promise now to shutup and leave you in peace (on this topic, anyway).
Peter.
From: marcvh(_at_)spry(_dot_)com (Marc VanHeyningen)
To: ssl-talk(_at_)netscape(_dot_)com
Subject: Re: Simple hole?
Date: Sat, 21 Oct 1995 15:27:22 -0700
Sender: mvanheyn(_at_)pellet(_dot_)spry(_dot_)com
Resent-Message-ID: <"0-zgt1.0.P73.bHNYm"@neon>
Resent-From: ssl-talk(_at_)netscape(_dot_)com
X-Mailing-List: <ssl-talk(_at_)netscape(_dot_)com> archive/latest/1130
X-Loop: ssl-talk(_at_)netscape(_dot_)com
Resent-Sender: ssl-talk-request(_at_)netscape(_dot_)com
Thus wrote: Jeff Weinstein
Marc Horowitz wrote:
We check the name that is in the hyperlink that the user clicks
on or the URL that they type. If a user types home.netscape.com,
and you spoof DNS to grab the connection, you will still not have
a certificate from a trusted CA that says you are 'home.netscape.com',
so the user will see my warning dialog. Am I missing something?
On the other hand, if the user types "www.netscape.com" the user will
also see a warning dialog because the certificate says you are
"home.netscape.com". Or am I missing something? Can you get a
certificate with a CN of "*.netscape.com" or something like that,
per VeriSign's wildcard rules?
- Marc
Marc VanHeyningen <marcvh(_at_)spry(_dot_)com> Spry/CompuServe Internet
Division
Software Engineer, UNIX Server Group Seattle, Washington