[Moderator's note: Forwarded anonymously at the sender's request, so
if you reply to this, please cut my name out of it, it isn't my
message --Perry]
--
Perry, please forward anonymously.
On Friday, Oct 10, 2003, at 22:48
Peter Clay wrote:
On Thu, 9 Oct 2003, Peter Gutmann wrote:
I would add to this the observation that rather than writing yet another SSL
library to join the eight hundred or so already out there, it might be more
useful to create a user-friendly management interface to IPsec implementations
On Thu, 9 Oct 2003, Peter Gutmann wrote:
I would add to this the observation that rather than writing yet another SSL
library to join the eight hundred or so already out there, it might be more
useful to create a user-friendly management interface to IPsec implementations
to join the zero or
Peter Clay [EMAIL PROTECTED] writes:
If you want a VPN that road warriors can use, you have to do it with IP-over-
TCP. Nothing else survives NAT and agressive firewalling, not even Microsoft
PPTP.
IP-over-TCP has some potential performance problems, see
Peter Clay [EMAIL PROTECTED] writes:
Having spent much of the past few weeks trying to sort out a workable VPN
solution, I think this is a good but doomed idea. http://vpn.ebootis.de/
has the best free windows IPsec configuration tool I've found, but that
doesn't help. Why? Because IPsec
On Thu, Oct 09, 2003 at 01:56:47AM +1300, Peter Gutmann wrote:
I would add to this the observation that rather than writing yet another SSL
library to join the eight hundred or so already out there, it might be more
useful to create a user-friendly management interface to IPsec implementations
Jill Ramonsky wrote:
Too late. I've already started. Besides which, posts on this group
suggest that there is a demand for such a toolkit.
I think there's demand in the sense that there's demand for free
lunches. People would like the inherent complexity to go away, because
they can see that
PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Open Source (was Simple SSL/TLS - Some Questions)
I think that rather than spending time on deciding what to call this
library that is to-be-written, and how to license this library that is
to-be-written, that time should be spent on, well, writing
: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 08, 2003 1:57 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Open Source (was Simple SSL/TLS - Some Questions)
Rich Salz [EMAIL PROTECTED] writes:
I would add
I took the initial view that closed source and trustable
crypto are mutually incompatible
Of course this isn't true. When is the last time you built your
own ATM or credit-card POS terminal?
Claims such
as Download this app and you will be secure should definitely need to
be proven, and
| From: Jill Ramonsky [EMAIL PROTECTED]
| From: Ian Grigg [mailto:[EMAIL PROTECTED]
|
| The only question I wasn't quite sure of
| was whether, if I take your code, and modify it,
| can I distribute a binary only version, and keep
| the source changes proprietary?
|
| You can't
On Mon, 6 Oct 2003, Ian Grigg wrote: (answering Jill's questions)
The only question I wasn't quite sure of
was whether, if I take your code, and modify it,
can I distribute a binary only version, and keep
the source changes proprietary?
I'd strongly recommend to think about some code-signing
Jill Ramonsky [EMAIL PROTECTED] writes:
Eric raised some points which I should address. First, he asked me
You have read the RFC, right?. Well I guess I should be honest here
and say no, I hadn't done that yet. Maybe that's where I went wrong,
and would have asked fewer dumb questions if I
Jill Ramonsky [EMAIL PROTECTED] wrote:
I confess ignorance in matters concerning licensing. The basic rules
which I want, and which I believe are appropriate are:
(i) Anyone can use it, royalty free. Even commercial applications.
(ii) Anyone can get the source code, and should be able to
Florian Weimer [EMAIL PROTECTED] writes:
Jill Ramonsky wrote:
My question is, how much of a problem is this for the embedded market?
Have you looked at GNU Pth? It's a non-preemptive threading package
which should be reasonably portable.
I don't know the TLS/ASN.1 formats by heart, but
Jill Ramonsky wrote:
First, the primary design goal is simple to use.
This is the highest goal of all. If it is not simple
to use, it misses out on a lot of opportunities. And
missing out results in less crypto being deployed.
If you have to choose between simple-but-incomplete,
versus
On Fri, Oct 03, 2003 at 05:55:25PM +0100, Jill Ramonsky wrote:
Having been greatly encouraged by people on this list to go ahead with a
new SSL implementation,
That's a pretty good idea, I also encourage you (and volunteer to
support).
The main
point of confusion/contention right now
Rich Salz wrote:
You know about Wei's Crypto++, right?
I use it and like it. I don't have to dig into the guts very often, which is
good because I don't like mucking around in C++.
You have to understand templates to understand the API. The docs are spartan,
but the design is clean so it
Having been greatly encouraged by people on this list to go ahead with a
new SSL implementation, it looks like I am going to go for it, but I'd
kinda like to not make any enemies in the process so I'll try to keep
this list up to date with progress and decisions and stuff ... and I
will ask a
Jill Ramonsky [EMAIL PROTECTED] writes:
Now - SSL or TLS - this confuses me. From what I've read in Eric's
book, SSL version 3.0 or below is called SSL, wheras SSL version 3.1
or above is called TLS.
I wouldn't use quite that terminology. Noone talks about SSL version
3.1, but rather TLS 1.0.
20 matches
Mail list logo
