Tim Dierks wrote:
...
the fact that the private key, is, in essence, escrowed by the trusted
third party, causes me to believe that this system doesn't fill an
important unmet need.
I'm not sure that's the case!
There are some markets out there where there are some
contradictory rules. By
On Tue, Jul 08, 2003 at 05:31:45PM -0700, Eric Rescorla wrote:
All else being equal, a protocol which provides more security
is better than a protocol which provides less. Now, all things
aren't equal, but if you can offer substantially more security
with only a modest increase in code
From my very practical position ( I was the CTO of Authentica and
responsible for their email and web technology) there are truths to the
email from Ian. Though I will also state that their is a very real
segment of the marketplace which does require a user to have secure
messaging while the
Actually i would imagine that banks could have such a trusted position.
They haven't done anything in the space but I am sure they will at some
time.
The problem isn't them holding the key but once it is in the hands of a
third party it could easily be gotten to by the government (through a
- Original Message -
From: Whyte, William [EMAIL PROTECTED]
[...]
But you don't have to contact the CA to get someone's certificate.
A standard way is to send them an email saying can you send me
a signed message?
Yes, that works. When I want someone to send me confidential
email,
On Mon, 7 Jul 2003, Hack Hawk wrote:
So what they're saying is that your PRIVATE key is stored on a server
somewhere on the Internet?!?!
No, this (like Kerberos) works best in a federated model. Each
organization (or group of organizations that trust a common third
party and have mechanisms
Eric Rescorla wrote:
You keep harping on certs, but that's fundamentally not relevant to
the point I was trying to make,
OK!
which is whether or not one provides
proper message integrity and anti-replay. As far as I'm concerned,
there are almost no situations in which not providing those
I wouldn't say that this is a good reason to take
these features out of SSL. But assuming they are
needed is a cautious assumption, and assuming
that SSL meets the needs for replay integrity
makes even less sense when we are dealing with a
serious top-to-bottom security model.
[ ... ]
tom st denis [EMAIL PROTECTED] writes:
--- Eric Rescorla [EMAIL PROTECTED] wrote:
This is all fine, but irrelevant to my point, which is that
if you're designing a channel security protocol it should
provide channel level integrity and anti-replay unless there's
some really good reason
Integrity: Financial protocols that use crypto
(as opposed to ones abused by crypto) generally
include signed messages. The signature provides
for its own integrity, as well as a few other
things.
I don't believe that is enough. Take for example
the SSL 2.0 ciphersuite rollback
An excellent site for those interested in tunneling, covert channels,
network related steganographic methods developments.
http://gray-world.net/
There is no protection or safety in anticipatory servility.
Craig Spencer
-
The
11 matches
Mail list logo
