rnold G. Reinhold" [EMAIL PROTECTED]
To: Lynn Wheeler/CA/FDMS/FDC@FDC
cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Public Key Infrastructure: An Artifact...
At 11:17 AM -0800 11/23/2000, [EMAIL PROTECTED] wrote:
Basically cetificates are an implementa
On Mon, Nov 27, 2000 at 10:58:23AM -0800, [EMAIL PROTECTED] wrote:
Hi Lynn!
problem is that consumer don't normally know that they want to check on a
particular merchant's CRL entry until they realize that they want to go to that
merchant site. in general, the consumer's aren't going to
At 11:17 AM -0800 11/23/2000, [EMAIL PROTECTED] wrote:
Basically cetificates are an implementation of R/O partial replicated
distributed data that were intended to address availability of
information in a
predominately offline environment.
In the SSL server certificates, distribution of CRLs
On Fri, 24 Nov 2000, John Kelsey wrote:
At 04:47 PM 11/22/00 -0800, Bram Cohen wrote:
Once again, the solution to the problems of offline
operation appears to be online operation.
And the annoying thing about this is that once we go to
needing an online trusted third party to allow us
I would like to get further information as to why you don't think revocation does
not work? I'll admit that in the case of the revocation of Sun's certificates, it
was very apparent that the notification process was weak. The other piece, the
browser checking of expired/revoked certificates is
d"
[EMAIL PROTECTED], Ben Laurie [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Public Key Infrastructure: An Artifact...
I would like to get further information as to why you don't think revocation
does
n
[EMAIL PROTECTED],
"Arnold G. Reinhold" [EMAIL PROTECTED], Ben Laurie
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Public Key Infrastructure: An Artifact...
[EMAIL PROTECTED] writes:
The other solution is to
[EMAIL PROTECTED] writes:
The other solution is to go online and do real-time checks ... but
doing real-time checks invalidates basic design decision trade-offs
associated with choosing a R/O partial replicated distributed data
implementation in the first place.
Have you looked at the design
On Wed, 22 Nov 2000 [EMAIL PROTECTED] wrote:
the other scenerio that some certification agencies have expressed (i.e.
licensing bureaus, bbb, consumer report, etc operations) is that in the online
world ... that they would provide an online service rather than
certificates designed for
On Sat, 18 Nov 2000 [EMAIL PROTECTED] wrote:
Bram Cohen [EMAIL PROTECTED] writes:
Unless that problem is fixed, man in the middle is hardly made more
difficult - for example, Mallory could break into some random machine on
the net and steal it's public key, then hijack local DNS and
At 12:08 PM + 11/19/2000, Perry commented:
[I see you've never paid attention to how easy it is to get a
certificate, Ben. I suspect I could get one in the name of any company
with about 20 minutes of unskilled forgery. The level of checking done
is trivial. This wouldn't be a problem except
At 12:10 PM -0500 on 11/20/00, Arnold G. Reinhold wrote:
If CAs
included a financial guarantee of whatever it is they are asserting
when they issue a certificate, then all these problems would go away.
Right.
Like Ellison (and Metzger :-)) have said for years now, the only
"assertions"
as pure asside ... any SSL server certificate signed by any CA in my browswer's
CA list is acceptable.
for list of current valid signing CA's in a typical browswer see:
http://www.garlic.com/~lynn/aepay4.htm#comcert14
http://www.garlic.com/~lynn/aepay4.htm#comcert16
my broswer makes no
On Mon, 20 Nov 2000 [EMAIL PROTECTED] wrote:
as pure asside ... any SSL server certificate signed by any CA
in my browswer's CA list is acceptable.
my broswer makes no distinction on which CA signed what ...
and/or even what they signed. If I get a certificate signed
by any CA in my
On Sun, 19 Nov 2000 [EMAIL PROTECTED] wrote:
When the user goes to www.amazon.com, they get a plaintext http redirect
to amazon.hackeddomain.com, which does check.
Still confused...
The original connection to www.amazon.com is an SSL connection, right?
We are following an https: URL?
At 1:25 PM -0500 11/20/00, R. A. Hettinga wrote:
At 12:10 PM -0500 on 11/20/00, Arnold G. Reinhold wrote:
If CAs
included a financial guarantee of whatever it is they are asserting
when they issue a certificate, then all these problems would go away.
Right.
Like Ellison (and Metzger
On Mon, 20 Nov 2000 [EMAIL PROTECTED] wrote:
as pure asside ... any SSL server certificate signed by any CA in my browswer's
CA list is acceptable.
for list of current valid signing CA's in a typical browswer see:
http://www.garlic.com/~lynn/aepay4.htm#comcert14
On Mon, 20 Nov 2000 [EMAIL PROTECTED] wrote:
So what is the acceptable threshold of errors? 1 in a 100? What if
that 1 is the invalid certificate that allows your bank account to be
compromised. CA's should either be 100% or 0% trustworthy. I do agree that
there needs to be a protocol
[EMAIL PROTECTED] wrote:
On Sat, 18 Nov 2000 [EMAIL PROTECTED] wrote:
Bram Cohen [EMAIL PROTECTED] writes:
Unless that problem is fixed, man in the middle is hardly made more
difficult - for example, Mallory could break into some random machine on
the net and steal it's
: Public Key Infrastructure: An Artifact...
On Mon, 20 Nov 2000 [EMAIL PROTECTED] wrote:
as pure asside ... any SSL server certificate signed by any CA
in my browswer's CA list is acceptable.
my broswer makes no distinction on which CA signed what ...
and/or even what they signed. If I get
On Mon, 20 Nov 2000, Arnold G. Reinhold wrote:
Perry's last sentence gets to the heart of the matter. If CAs
included a financial guarantee of whatever it is they are asserting
when they issue a certificate, then all these problems would go away.
They aren't going to.
-Bram Cohen
[EMAIL PROTECTED] wrote:
actually ... not really ... this was discussed early this summer as to what they
actually check ... and how trivial it is to fabricate necessary details to pass
such checking
random ref:
http://www.garlic.com/~lynn/aadsmore.htm#client3
in general it is
PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Public Key Infrastructure: An Artifact...
[EMAIL PROTECTED] wrote:
actually ... not really ... this was discussed early this summer as to what
they
actually check ... and how trivial it is to fabricate
Of relevance to SSL and trust in DNS...
Even without stealing keys, there are unconventional ways of
circumventing SSL server authentication. That is, pretending to be an
SSL server that you are not.
For instance, a client might forget to verify in a resumed SSL session
that the server
oh yes, as to the other kinds of certificates.
basically this is an issue of trust establishment. there are various forms of
trust establishment, advertisement, brand, word-of-mouth, previous history, etc
... not just BBB or consumer report like stuff.
Transactions are highly skewed ... with
PROTECTED] on 11/19/2000 04:08:39 AM
To: Lynn Wheeler/CA/FDMS/FDC@FDC
cc: Bram Cohen [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Public Key Infrastructure: An Artifact...
[EMAIL
Bram Cohen wrote:
On Sat, 18 Nov 2000, Ben Laurie wrote:
[EMAIL PROTECTED] wrote:
In any case, the domain name infrastructure has been looking at ways to beef up
the integrity of its operation ... like having public keys registered as part of
domain name registration.
How
Bram Cohen [EMAIL PROTECTED] writes:
Unless that problem is fixed, man in the middle is hardly made more
difficult - for example, Mallory could break into some random machine on
the net and steal it's public key, then hijack local DNS and when someone
goes to amazon.com redirect them to
Bram Cohen [EMAIL PROTECTED] writes:
Unless that problem is fixed, man in the middle is hardly made more
difficult - for example, Mallory could break into some random machine on
the net and steal it's public key, then hijack local DNS and when someone
goes to amazon.com redirect them to
On Sat, 18 Nov 2000, Ben Laurie wrote:
Bram Cohen wrote:
And if you build a protocol which is a pain to use, noone will use it.
What, like SSL, for example?
SSL is not a pain to use, and it isn't effective against man in the middle
attacks, since an attacker could simply make the end
PROTECTED] (bcc: Lynn
Wheeler/CA/FDMS/FDC)
Subject: Re: Public Key Infrastructure: An Artifact...
On Sat, 18 Nov 2000, Ben Laurie wrote:
Bram Cohen wrote:
And if you build a protocol which is a pain to use, noone will use it.
What, like SSL, for example?
SSL is not a pain to use
On Sat, 18 Nov 2000 [EMAIL PROTECTED] wrote:
note also that current SSL infrastructure is vulnerable to things like domain
name hijacking; aka, at least part of SSL protocol is to make sure that you
really are talking to the host that you think you are talking to ... i.e. the
SSL certificate
[EMAIL PROTECTED] wrote:
note also that current SSL infrastructure is vulnerable to things like domain
name hijacking; aka, at least part of SSL protocol is to make sure that you
really are talking to the host that you think you are talking to ... i.e. the
SSL certificate contains
Bram Cohen wrote:
On Sat, 18 Nov 2000 [EMAIL PROTECTED] wrote:
note also that current SSL infrastructure is vulnerable to things like domain
name hijacking; aka, at least part of SSL protocol is to make sure that you
really are talking to the host that you think you are talking to ...
On Sat, 18 Nov 2000, Ben Laurie wrote:
Bram Cohen wrote:
Unless that problem is fixed, man in the middle is hardly made more
difficult - for example, Mallory could break into some random machine on
the net and steal it's public key, then hijack local DNS and when someone
goes to
Bram Cohen wrote:
On Sat, 18 Nov 2000, Ben Laurie wrote:
Bram Cohen wrote:
Unless that problem is fixed, man in the middle is hardly made more
difficult - for example, Mallory could break into some random machine on
the net and steal it's public key, then hijack local DNS and
The problem with all of these things is that they are still based on
creating an association between a domain name and a key, when in fact what
you want is an association between some abstract concept of a counterparty
which exists in an end user's mind (like, say, amazon) and the ownership
On Sat, 18 Nov 2000, Ben Laurie wrote:
Bram Cohen wrote:
Unless that problem is fixed, man in the middle is hardly made more
difficult - for example, Mallory could break into some random machine on
the net and steal it's public key, then hijack local DNS and when someone
goes
(bcc: Lynn Wheeler/CA/FDMS/FDC)
Subject: Public Key Infrastructure: An Artifact...
http://www.anu.edu.au/people/Roger.Clarke/II/PKIMisFit.html
Public Key Infrastructure: An Artifact Ill-Fitted to the Needs of the
Information Society
Abstract
It has been conventional wisdom that, for e-com
On Sat, 11 Nov 2000, R. A. Hettinga wrote:
Conventional, hierarchical PKI, built around the ISO standard X.509, has
been, and will continue to be, a substantial failure. This paper examines
that form of PKI architecture, and concludes that it is a very poor fit to
the real needs of
On Thu, 16 Nov 2000 [EMAIL PROTECTED] wrote:
Bram Cohen writes:
In the vast majority of cases, preventing man in the middle attacks is a
waste of time.
In the sense that, in the vast majority of communications, there is no
man in the middle attack being mounted?
Yes.
Couldn't the
41 matches
Mail list logo
