In article <[EMAIL PROTECTED]>, David Gerber
<[EMAIL PROTECTED]> wrote:
> On 30-Avr-99 13:39:20, Holger Kruse wrote:
>
> > Just a few corrections to some recent mails regarding SSL:
>
> Which do not really belong to this mailing-list which was talking about SSH
> and SSL ports. But it's better to do some propaganda I guess.
I was directly responding to three emails on this list which made
incorrect statements regarding SSL, one of which could be considered
slanderous. You may know that I am required to make reasonable
attempts to correct incorrect statements or I may lose legal
recourse. I am hereby doing so.
As to propaganda: you should direct that accusation towards
those people who make knowingly false statements. None of the
statements I made went beyond the bare facts, i.e. they are by
definition not propaganda, and it was not me who brought
MiamiSSL (my product, after all), into this discussion in the
first place.
> TCP/IP doesn't fit very well in the OSI model.
That problem only affects the network/transport distinction, but
not other parts of the model. TCP/IP fits OSI well enough to
document how SSL fits into it, or SSL's successor, TSL, which
even stands for "*Transport Layer* Security". It does not get any
clearer than this: the "Transport Layer" is by definition part of
the stack.
> It shouldn't belong in the stack but as an external package like it is on
> other platforms.
That's what MiamiSSL is: an external package on top of the stack,
that extends the transport layer and API of the stack.
> Do you know any other stack except Miami which comes with
> SSL built in ? No. You usually install SSLeay (OpenSSL now) as either a link
> lib or as a shared library and you link your applications with it, either
> statically or dynamically.
Exactly, same as with MiamiSSL. It is a separate package, on top of
the stack, i.e. an extension of the stack (as opposed to being a
plug-in for an application). That's exactly the same situation as
in Unix, where e.g. libssl.a extends the API of libsocket.a.
The reason why MiamiSSL only works with the registered version of
Miami is of a legal kind: US Federal Law requires me to keep track
of addresses and other information of all recipients of encryption
code. The easiest and quickest way to do this was by using the
existing registration database of Miami, so MiamiSSL had to be
compiled in such a way that it would only work with registered
Miami.
MiamiSSL was initially released in cooperation with Olli, and for
a single purpose only: to give *Voyager* users in the US a legal
implementation of SSL (which is why I don't really understand why,
of all people, some Voyager users get so aggressive over this
issue and seem to imply ulterior motives -- there simply were none).
Support for other browsers was added much later.
At the time I wrote MiamiSSL Voyager was about to be released,
and there was simply no time left for me to write, test and deploy
a lot of additional address collection, registration and licensing
software, just for a US SSL package. I had to use the tools that I
already had in place, or Voyager users would not have been able to
use SSL.
There is no technical reason whatsoever why MiamiSSL should not work
with Genesis. Just recompiling with a different compiler option, to
bind MiamiSSL library against genesis.library instead of miami.library
would do the trick. I have repeatedly offered to grant licenses, but
not heard of any interest so far. Of course the licensee would have
to solve the US/Canada distribution problem, link the intl version,
as Olli did, and take legal responsibility for the package, i.e.
hold me harmless from legal claims.
> MiamiSSL only works with Miami. That's probably why all the Amiga browsers
> decided to use their own implementation of SSL.
Actually AWeb does not have its own SSL implementation.
> So yes, it limits the browser
> regarding MiamiSSL since you need Miami (and it's a serious limitation IMHO).
Then instead of having all authors of web browsers reinvent the
wheel, don't you think it would be more suitable to find a way
to get compatible SSL implementations at the stack level deployed ?
I have made offers and am open to suggestions.
FYI: The authors of I-Net 225 have already indicated that they will
add SSL to their stack in a future version, and contacted me to
ensure as much compatibility to MiamiSSL as possible. A step in the
right direction IMHO...
--
Holger Kruse [EMAIL PROTECTED]
http://www.nordicglobal.com
NO COMMERCIAL SOLICITATION !
____________________________________________________________
Genesis Mailing List - Info & Archive: http://www.vapor.com/
For Listserver Help: <[EMAIL PROTECTED]>, "HELP"
To Unsubscribe: <[EMAIL PROTECTED]>, "UNSUBSCRIBE"
