Phill,
You might like to read
ftp://ftp.ietf.org/internet-drafts/draft-ietf-wts-shttp-05.txt
Thank you, I commented on the first draft back in early 1994.
I think that the basic premise for S-HTTP has to be entirely
re-evaluated in the light of ubiquitous S/MIME support in the
basic Internet support code for the clients. I see transaction
level signatures as being much more important than
transport level encryption which offers little more than a
small caching advantage over transport layer security
Given the fact that the browser vendors seem to have little
interest in transaction level security I am simply proposing
that we consider a very minor change to the HTTP spec
that would obtain 80% of the value of security at the
transaction layer with a tiny fraction of the cost of implenting
S-HTTP.
One scenario for using this protocol would be: user is
presented with a contract offer, user fills in some details
and sends a signed response back.
Netscape has already provided a feature of this sort with
its 'form signing technology' in Navigator 4.04. What I am
proposing is essentially similar but covering more than
just form signing and using headers alone, not cookies or
anything else.
http://developer.netscape.com/one/security/formsign/formsign.html
<digression relevance="some">
As a separate matter I would like to define a number of OIDs
to express some HTTP/HTML specific signing scenarios.
For example a user obtains a signed form with an anchor
with a cryptopts="signed" attribute. There are obvious security
problems in having the user sign responses automatically and
informed consent is hard to achieve for anything beyond
plaintext. One means of addressing these security problems
would be to incorporate a hash of the signed 'offer' document
into the signature.
</digression>
I think these scenarios are already implicit in S/MIME since
HTTP and SMTP are both layered on MIME. We already have
a rack of compromises to cope with SMTP junk I am simply
suggesting we make an additional one to cope with HTTP
installed base "junk".
Also note that it might well be sensible to state that a browser
recieving a header signature that supports offline storage
'should' assemble an S/MIME wrapper out of the parts to allow
the signature to be saved.
What this buys us is the ability to do most of the high value
transaction layer security tricks without folks slaving over
reams of code and without having to make sure that a
particular browser can cope with the extension. Unfortunately
the only mechanism we have for this in HTTP is the
user-agent field which was not my choice but is what we
are stuck with.
Phill