Hello all.
Since S/MIME is based on top of MIME and HTTP is meant to be MIME based
these days S/MIME is clearly one vehicle for signing an HTTP page. This even
works today if one uses Navigator (well sortof).
Should we be explicitly considering HTTP as a transport for S/MIME? In
particular the ability to sign documents in a manner compatible with
existing browsers would be handy.
A particular application in mind being the VeriSign repository. I would
like folk downloading the CPS to always get a signature. This would
facilitate remote checking of the service to check that the server had not
been hacked.
Note that this is a completely different requirement to SSL which is
basically oriented towards session confidentiality. If Kevin Mitnick
captures your server it will serve up the new pages regardless...
Essentially I am arguing that a webmaster in charge of a sensitive site
is likely to want to have the signing key for content stored offline (e.g.
its on a smartcard she carries arround her neck). Gosh - they would need a
second certificate!
A really paranoid Webmaster would probably want the server to check the
signature of pages internally before publishing them. Folk can work out the
obvious means of caching the publishing authorization themselves...
The simplest mechanism for achieving this objective consistent with the
PKIX, S/MIME base already present in the browser is a new header to carry a
pkcs #7 detached signature. ie:
GET /fribble.html HTTP/1.1
Hostname: fool.com
Date: 1-Apr-1997
HTTP/1.1 201 O.K. (sort of)
Content-Type: text/html
Content-Signature: a+slekruaseoituaaweyqwpoetoqsweytluqwetgyqwerty
qwliue/qwetluyqwietyqwieytoiqweytoiqwyetoiuqwyetoiuqyw
etouyqweoty
Content-Length: 1034
<HTML>
... etc
The advantages of this approach are that the signature causes no problem
if it is recieved by IE 3.0 or Navigator 3.0. There is a risk that a proxy
might fish out the content signature header but this should just be a matter
of configuring the firewall.
Questions
1) is there an interest in this application?
2) are there other considerations.
3) How/where should it be described? In the S/MIMEv3 description? As a
separate draft?
Altertnatively we can wait to see if whatever comes out of the W3C
PICS/DigSig proposal is acceptable. At this point however I think the
existing investment in PKCS#7 infrastructure makes its use as an envelope
format here (albeit in detached form) a slam dunk.
What I would like to do with the DigSig work is to take the assertion model,
issue it an OID and wrap it up in PKCS#7 and X.509v3. The SPKI/SDSI stuff
looked a good idea two years ago when that project was kicked off but I
don't think its viable at this point. With the CDA dead the momentum behind
PICS is flagging and it appears many see it as a future liability, possibly
allowing a censorship bill to be passed more justices would find
constitutional (cf the Lessig argument picked up by O'Connor). Hence the
DigSig links to the PICS censorship scheme is also a liability.
Phill