I still think you are just blowing smoke wiht all the "very powerful"
nonsense.
more powerful, yes; very powerful, no. You misquote me.
First of all, I must say that I agree with Donald Eastlake's response to this.
Not only did he not misquote you, he's right in saying that this discussion
shifts to new ground with every posting you make. There is every indication
of major misunderstanding on your part.
However, you do bring up some interesting matters here that I would like to
address. None of this has anything to do with S/MIME versus security multiparts
and MOSS, but its interesting stuff neverthless.
Anyway, I learned yesterday that the correct internet term for whats going on,
which I described with "referral/hypermedia model", is a "embedded secure
URL".
Its news to me that the "correct internet term" is "embedded secure URL". Is
there someone in authority who decides these things? I don't think so...
Anyway, an "embedded secure URL" could mean several things. The most obvious
is simply the specification of a URL within a secured object. This is possible
with any service that supports transmission of text and hence is not
interesting.
More interesting is the idea of a URL that's actively visible to MIME. A
specification for this is already in the works under the auspices of the
MAILEXT working group -- I'm the author of this. It extends the
MIME external-body mechanism to cover URLs.
Even more interesting than this is the idea of being able to sign the content
of the URL in a message, so that people know they're retreiving the right
thing. And it turns out that once the URL access-type is in place this
capability simply falls out of existing mechanisms -- a content-md5 header can
be used to provide a checksum of the content of the URL within the context of
a signed message.
Its also possible to use either security multiparts or S/MIME to sign or
encrypt the content a given URL points at.
As far as I can tell this pretty much covers all the meanings that can be
attached to "embedded secure URL". And note that in all cases the work to
make this possible has been done or is being done in the IETF, not by
RSA. (Unless they're working on it privately -- a definite possibility...)
The business semantics we are after are these: non-repudiation, or proof of,
submission and/or delivery and/or receipt. These security services are not, to
my knowledge provided by any of PEM, multipart/MOSS, or PKCS7. A fair
attempt at some of them is provided by MSP and EDIFACT. When MSP is layered
upon a Peer Access Enforcement function at the originator, then controlled
submission is also effected. But, so Im told, thats all DoD vapourware. If
one believes in the assurances of VANs, then its also provided by EDI. In NATO
secure X.400 deployment, and probably in Nortel/Entrust products also, such
assurances are credible.
(These smokey services are defined in X.400)
You've mentioned a bunch of different services here. Let's take them one at a
time:
(1) Non-repudiation of or proof of delivery. This is about to become possible
on the Internet once work on delivery notifications is completed. (The
documents are finishing up in last call.)
Specifically, an agent can use a security multipart to sign a delivery
receipt. Since that receipt can include the message that was delivered, it
makes both non-repudiation and proof of delivery services possible.
Now, while this mechanism will work once the basics are in place, its
really not acceptable for production use. Why? Because it requires that
the original message be returned in its entirety in the receipt. This
constitutes 100% overhead (much more if you use S/MIME) which I regard as
intolerable. We need to define some extensions to the basic delivery
report format once its stable to allow for the return of just the signature
on the original message. This will be easy to do given the nature of
the format for delivery reports.
(2) Non-repudiation of or proof of submission. This is harder -- it would
require extensions at the SMTP level. Fortunately, at least part of the
necessary mechanisms for this are beginning to fall into place, in the
form of the SMTP extensions for signed or encrypted transport. (The drafts
for this have been posted to the CAT working group list by John Myers.)
(3) Non-repudiation of or proof of receipt. This is basically the same service
as proof of delivery, the difference being that an appropriately
constructed read receipt is signed by the recipient rather than a delivery
receipt being signed. Work is already underway to define the formats for
read receipts. (A new working group is being formed and I expect a draft
specification to appear as an Internet Draft any time now.)
RSA DSI and partners seem willing. The market is using it. applications and
working code is available. All we need is the forum to take spec to standard
based on a technical consensus process.
Bzzt! Wrong! Thank you for playing. Work on all these elements is well underway
all right, but its the poor old IETF that's doing it all. RSA DSI and partners
may be closeted somewhere doing something similar, but I've yet to see any
public proposals. I have zero interest in security facilties developed in a
closet somewhere -- peer review is *crucial* in developing viable security
systems, as the flows in S/MIME, to say nothing of the troubles Netscape has
had recently, serve to indicate.
If you're serious about pursuing any of this, you need to start by checking out
what's already being done and how it can be used. Then, once you understand
what's available, we can engage in a useful dialogue about what's missing and
how to provide it.
Ned