[171] in WWW Security List Archive
Re: OBCSCR
daemon@ATHENA.MIT.EDU (hallam@dxal18.cern.ch)
Fri Sep 30 22:21:26 1994
From: hallam@dxal18.cern.ch
To: rosenthl@mcc.com (Doug Rosenthal), www-security@ns1.rutgers.edu,
www-buyinfo@allegra.att.com
Cc: hallam@dxal18.cern.ch
In-Reply-To: Your message of "Fri, 30 Sep 94 09:57:23 CDT."
<9409301457.AA06193@krypton.mcc.com>
Date: Fri, 30 Sep 94 21:14:46 +0100
Reply-To: hallam@dxal18.cern.ch
> If there is consensus that this is an interesting idea, I'd like to
> see if we can mutually develop an OBCSCR not tied to one vendor's
> proprietary hardware or software.
I just want to put in my "vote" that this is indeed an interesting idea. I
don't think overloading HTTP will work out well -- it simply wasn't
meant for the uses which we're discussing. One of the beauties of
HTTP is that it's relatively simple. Separating out the security
concerns makes sense for all the reasons you list. Also, it allows
different people to set different levels of security, depending on
what they trust and personal choice and all. I think this is very
important.
I think people are missing the point about HTTP. Plain HTTP is simply an
encasulation of the basic methods for operating with a filesystem GET,
PUT, POST, DELETE, HEAD. The as yet un-specified but prototype Multi-Method
HTTP adds transaction primitives START, ROLLBACK, COMMIT and there is
also our favourite NULL method. (Some people want to have SKIP and STOP
instead because STOP has nice mathematical properties).
Security mechanisms were part of the original HTTP spec but they were not
implemented because other things came along. Plus we have a chicken and egg
situation, many of the security area ideas require extensions of the
basic technology. This is easier if you only have a single task to consider
like home shopping. We want to also permit secure conferencing over HTTP.
Because HTTP is simple it is easy to encapsulate other protocols. I don't
think the GSS API work has much relevance though. It is higher level than
HTTP, it is not something you build HTTP (or like aparatus) upon.
I don't know where you got the idea about what HTTP was `meant' to do.
Have you spoken to the developers or creators? We certainly intend to keep
it simple. But we also intend to extend its functionality.
I would liken HTTP to a `RISC' protocol. FTP and the like are CISC, lots of
operations. Regard load-modify-store as the equivalent of the session based
connection for atomic actions. Now just as several RISC architectures (eg
AXP) have quite a few instructions and even some quite fancy ones there
is a clear notion of some `abstract' simplicity. That is what we intend to
keep.
Phill H-B
