NODE 9718ee63Re: HTTP security
"Amanda Walker" <amanda@intercon.com>Tue, 13 Dec 94 07:46:45 PST
> This seems a very relevant criticism: Has Amanda, or anyone else
> proposed an extension to HTML that would incorporate such things?
Actually, it's not an extension to HTML, but to MIME (whose formats HTTP uses
top tag and label data), and it just went to Proposed Standard (the last step
before Internet Standard). The MIME multipart/signed and multipart/encrypted
body parts allow anything using MIME encapsulation to sign and/or encrypt
arbitrary body parts. Since it's at the document layer, it requires no
special transport software, works with existing proxies and caching servers,
and allows secure HTTP software to share code with secure email software
(since it would use exactly the same formats). The framework is general
enough to allow use with either PEM-compliant signatures and encryption or
others (such as PGP). I believe that can also be used with symmetric key
management, which could be useful for special purpose applications.
EInet's secure SHTTP proposal is also an end-to-end security framework.
Amanda Walker
InterCon Systems Corporation
NODE c3f80c39Re: HTTP security
Bill Sommerfeld <sommerfeld@orchard.medford.ma.us>Tue, 13 Dec 94 08:28:24 PST
-----BEGIN PGP SIGNED MESSAGE-----
> > This seems a very relevant criticism: Has Amanda, or anyone else
> > proposed an extension to HTML that would incorporate such things?
>
> Actually, it's not an extension to HTML, but to MIME (whose formats
> HTTP uses top tag and label data), and it just went to Proposed
> Standard
Not just yet; they're currently arguing about this on the pem-dev
list...
> (the last step before Internet Standard).
Nope, the IETF stds track is Proposed Standard -> Draft Standard -> Standard
> EInet's secure SHTTP proposal is also an end-to-end security framework.
Right, but with its preoccupation with negotiation, it seems to be
more oriented towards securing the *transaction* rather than the
*document*.
There are at least three different layers at which HTTP and "the web"
can be secured:
1) - the *transport* (and lower) -- secured by IPSP and/or SSL
2) - the *transaction* (e.g, authentication for access control)
3) - the *document* (e.g., authentication by the document's author)
The difference between (1) and (2) becomes obvious when proxies are
involved. Doing (2) complicates distributed caching, while (1) and
(3) don't really get in the way of caches.
Frankly, I think that the web needs (3), then (1), and only later (2).
- Bill
-----BEGIN PGP SIGNATURE-----
Version: 2.6.1
iQCVAwUBLu3IfrT+rHlVUGpxAQH8PQP/S1L6M56E0RZxMymL13YeIT4wdDdcgE39
NvYz1IanrDRkStIgDCeNrDPIL0fOhuyx04RqC+BUHKu5qTjcWu8oJTcRIe3W64kw
sRFa/BmEJh/T/RwdIXTQdxsbTbs6aa6JS2DIVuIpGzofIkOB5namiU9juYu5QSiO
SFxS/Rbyc3o=
=BKdJ
-----END PGP SIGNATURE-----