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.
Not that it matters, but I don't think what you're asking for now is what you
asked for previously.
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 see. In other words, you want the content of the message to provide an
indication of what source is allowed to provide the reference. You want to
qualify the source in some way without depending on a checksum of a specific
document.
I agree that this isn't the service content-md5 provides, but it seems to me
that the service you're after isn't especially difficult to define. All that's
needed is either a way to associate a service identity with a reference or else
a way to put the information directly into the reference.
I would tend towards the latter, given your apparent desire to be able to embed
this inside of an HTML document (and presumably other sorts of documents as
well).
This then leads me to the conclusion that this particular service really isn't
part of MIME at all. You need the ability to qualify a URL with specific
information as to what identity the server must have in order for the URL to
resolve. This could be done based on information that is already in the URL or
by adding additional information to the URL. The URL is then signed (perhaps
via a MIME-based security service, or perhaps not) to insure that it cannot be
tampered with and the qualification removed.
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.
I think your focus on email as a means of delivering this service is
inappropriate. The delivery of this service seems to me to be linked to the
reference itself rather than to the environment the reference is embedded in.
Making this service part of the environment necessitates that the references
themselves be called out as active components in that environment (e.g.
multipart/external-body). There's nothing wrong with multipart/external-body,
but its an awkward mechanism to have to use every time a URL appears in a chunk
of HTML in a message. (It can be done, BTW, by using a content-id URL to point
at a message/external-body, which in turn is somehow amended to contain the
server qualification information.)
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.
Well, it depends on what you mean by "authenticate the source". If by this you
mean that the presence of a signature somehow activates additional checks that
would not otherwise be done, the answer is that it does no such thing. Nor is
there any reason for it to activate additional checking. There is nothing about
a MIME signature that assumes you will make additional checks when retrieving
an external reference.
On the other hand, if the request for additional verification is built into the
reference itself, then the check will be made regardless of whether or not the
URL appears in a signed context. The signature simply guarantees that the
server identity requirement cannot be removed from the URL without your
knowledge.
So in order to insure that you're talking to the right server the reference
needs to include something that can be used to check out the server. Something
like the public key, for instance, that the server uses to sign its documents.
Or something that can be used to obtain a public key for the server.
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?
The problem with this approach is that it assumes a tight coupling between DNS
names and any qualification of servers you want to do. Such a coupling may be
viable in some cases but I doubt very much it will be viable in all cases. I
think you're going to run into cases where you need to have a way to
additionally qualify the URL directly with public key information the server
must use -- information that's independent of the particular DNS name that
happens to appear in the URL.
I also think that reliance on a particular certificate hierarchy that isn't
tied to the message in any way is inappropriate. It seems likely to me that
multiple hierarchies will appear, that context-free server identity checking
will have to support more than one, and that creators of such messages will
want a way to specify which hierarchies can actually provide a valid server.
Consider the following scenario. Suppose I want to fake you out and provide a
bogus document in response to your server request. I know that your URLs
reference foo.bar.com and I know that foo.bar.com is registered with hierarchy
A. Suppose also that hierarchy A, a high assurance hierarchy cross-certifies
heirarchy B, a low-assurance hierarchy, and that B has never heard of
foo.bar.com. I register foo.bar.com with B and they give me a certificate
without checking to see if the same name was registered to A.
I then spoof the DNS or whatever and grab your connection. I send back the
bogus response signed with the credentials I got from B. Your client validates
the certificate chain and finds that its legal. The fact that there was a
requirement that the chain only involve A wasn't passed from the message to the
client.
Its a cute approach though, and has the advantage that it will work without
any additional infrastructure.
Ned