// COMPLETE THREAD

Re: HTTP security

2 expanded posts ยท every known parent and child

NODE 9718ee63Re: HTTP security
> 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
-----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-----