[16] in WWW Security List Archive
Re: Kerberos authentication for X-Mosaic 2.4 and NCSA HTTPD
daemon@ATHENA.MIT.EDU (Jeff Hostetler)
Mon Aug 15 15:20:01 1994
From: jeff@spyglass.com (Jeff Hostetler)
To: John Ludeman <johnl@microsoft.com>
Cc: www-security@ns1.rutgers.edu
In-Reply-To: (Your message of Fri, 12 Aug 94 12:32:31 T.)
<9408121950.AA03302@netmail2.microsoft.com>
Date: Mon, 15 Aug 94 11:04:11 -0600
> I would strongly suggest taking this so far as to allow multiple
> pluggable security providers using Dynamic Link Libraries. Virtually
> every platform of interest supports some form of DLLs. This would
> allow a corporation to customize for their particular authentication
> scheme or allow RSA to provide a commercial encryption algorithm
> without having to munge the sources and compile (which I suspect is
> beyond the capabilities of many potential customers) or better yet, if
> the security provider standard is done right and is well written, plug
> into any commercial Web viewer. This also allows wide adoption of
> trade secret sensitive algorithms without having to give out the source code.
>
> In my mind, this is definately the direction the Web should head to
> guarantee its longevity.
>
> Modularizing the library is the first step. Using DLLs is the second
> and the last step is allowing for multiple providers.
>
yes. yes. yes. i agree that we want to work towards a 'plug-in'
architecture. it would let the web browser folks concentrate on
adding value to their user-interface, while letting the web-community
and the standards process get the security stuff done right.
it also would let the distribution channel concentrate on which
security modules are necessary/legal for a particular end-user.
a free-with-copyright browser could still exist and be distributed
on the net -- security-enabled, but with no plug-in's provided.
jeff hostetler
spyglass, inc.
