On Wed, 09 Sep 2009 15:42:34 +1000
"James A. Donald" wrote:
> Steven Bellovin wrote:
> > Several other people made similar suggestions. They all boil down
> > to the same thing, IMO -- assume that the user will recognize
> > something distinctive or know to do something special for special
> > s
Steven Bellovin wrote:
Several other people made similar suggestions. They all boil down to
the same thing, IMO -- assume that the user will recognize something
distinctive or know to do something special for special sites like
banks.
Not if he only does it for special sites like banks, but
On Sep 7, 2009, at 8:58 AM, Jerry Leichter wrote:
...standard Mac OS GUI element to prompt for passwords ...
I should expand on that a bit: This GUI element is used for all kinds
of things tied to a window, not just passwords. For example, if you
try to close a window that contains stuff yo
On Sep 3, 2009, at 12:26 AM, Peter Gutmann wrote:
This returns us to the previously-unsolved UI problem: how -- with
today's
users, and with something more or less like today's browsers since
that's
what today's users know -- can a spoof-proof password prompt be
presented?
Good enough to s
Steven Bellovin writes:
>Peter, I'm not sure what you mean by "good enough to satisfy security geeks"
>vs. "good enough for most purposes". I'm not looking for theoretically good
>enough, for any value of "theory"; my metric -- as a card-carrying security
>geek -- is precisely "good enough for m
On Sep 3, 2009, at 12:26 AM, Peter Gutmann wrote:
Steven Bellovin writes:
This returns us to the previously-unsolved UI problem: how -- with
today's
users, and with something more or less like today's browsers since
that's
what today's users know -- can a spoof-proof password prompt be
Ian G writes:
>If one is trying to solve the whole thing, then using the much-commented
>secure-bookmarks model would do this. Within the secure bookmark, record the
>user's certificate and cache enough info on the server's cert to deal with
>replacements (like, cert, name, CA).
There's a varia
On Thu, Sep 03, 2009 at 04:26:30PM +1200, Peter Gutmann wrote:
> Steven Bellovin writes:
> >This returns us to the previously-unsolved UI problem: how -- with today's
> >users, and with something more or less like today's browsers since that's
> >what today's users know -- can a spoof-proof passwo
Steven Bellovin writes:
>This returns us to the previously-unsolved UI problem: how -- with today's
>users, and with something more or less like today's browsers since that's
>what today's users know -- can a spoof-proof password prompt be presented?
Good enough to satisfy security geeks, no, be
Steven Bellovin wrote:
This returns us to the previously-unsolved UI problem: how -- with
today's users, and with something more or less like today's browsers
since that's what today's users know -- can a spoof-proof password
prompt be presented?
When the user clicks on a button generated by
On Aug 26, 2009, at 6:26 AM, Ben Laurie wrote:
On Mon, Aug 10, 2009 at 6:35 PM, Peter Gutmann> wrote:
More generally, I can't see that implementing client-side certs
gives you much
of anything in return for the massive amount of effort required
because the
problem is a lack of server auth, n
Ben Laurie wrote:
> If the problem you are trying to solve is client
> authentication then client certs have some obvious
> value.
But if client certs are Certificate Authority centric,
then they prove that so and so's true name is so and so.
They don't prove that so and so is one of our gang,
wh
There is an approach to this that currently is being standardized in the
IETF PKIX group. The certificate image work
(draft-ietf-pkix-certimage-01.txt)
The current draft is available from:
tools.ietf.org/html/draft-ietf-pkix-certimage-01
The technical idea behind this is very simple. Instead of t
On Mon, Aug 10, 2009 at 6:35 PM, Peter Gutmann wrote:
> More generally, I can't see that implementing client-side certs gives you much
> of anything in return for the massive amount of effort required because the
> problem is a lack of server auth, not of client auth. If I'm a phisher then I
> set
On 08/20/09 00:11, Ray Dillinger wrote:
No. This juvenile fantasy is complete and utter nonsense, and
I've heard people repeating it to each other far too often. If
you repeat it to each other too often you run the risk of starting
to believe it, and it will only get you in trouble. This is a
[Moderator's note: this is getting a bit off topic, and I'd prefer to
limit followups. --Perry]
On Wed, 2009-08-19 at 06:23 +1000, James A. Donald wrote:
> Ray Dillinger wrote:
> > If there is not an existing relationship (first time someone
> > uses an e-tailer) then there has to be a key depos
"James A. Donald" writes:
>I cannot see how you could create a bank web page without a web application
>framework (counting mod-php as a very primitive web application framework)
>and scripting and a database, which scripting and database has to know who it
>is is that logged in
We really are ta
"James A. Donald" writes:
[Incredibly complicated description of web scripting plumbing deleted]
Peter Gutmann wrote:
We seem to be talking about competely different things here. For a typical
application, say online banking, I connect to my bank at www.bank.com or
whatever, the browser requ
"James A. Donald" writes:
>[Incredibly complicated description of web scripting plumbing deleted]
We seem to be talking about competely different things here. For a typical
application, say online banking, I connect to my bank at www.bank.com or
whatever, the browser requests my credential info
James A. Donald wrote:
For password-authenticated key agreement such as TLS-SRP
or TLS-PSK to work, login has to be in the chrome.
Regrettably, login in the (non-customizable) chrome is unusable; this is
why *everyone* now uses cookies instead of HTTP authentication. Just
asking the user for
"James A. Donald" writes:
> > [In order to implement strong password based
> > encryption and authentication] on the server side,
> > we need a request object in the script language that
> > tells the script that this request comes from an
> > entity that established a secure connection using
> >
Thomas Hardjono wrote:
> I'm not sure if the Chrome folks would be prepared to
> ship their browser without any CA certs loaded,
Excessive distrust is inconvenient, excessive trust is
vulnerable. It is better to remedy flaws by expanding
functionality rather than restricting it.
On the one hand
>
> From: James A. Donald [jam...@echeque.com]
> Sent: Sunday, August 09, 2009 1:21 AM
> To: Thomas Hardjono
> Cc: Ben Laurie; Cryptography
> Subject: Re: Client Certificate UI for Chrome?
>
> Thomas Hardjono wrote:
> >
"James A. Donald" writes:
>This, however, requires both client UI software, and an api to server side
>scripts such as PHP, Perl, or Python (the P in LAMP). On the server side, we
>need a request object in the script language that tells the script that this
>request comes from an entity that est
[Moderator's note: top posting considered harmful:
http://www.mail-archive.com/cryptography@metzdowd.com/msg09287.html
--Perry]
Just to complicate things a little... we're working with a number of
groups now who are using onlineCAs that issue short-lived x509 certs
derived from a prim
--
> "James A. Donald" writes:
>> For password-authenticated key agreement such as
>> TLS-SRP or TLS-PSK to work, login has to be in the
>> chrome.
Peter Gutmann wrote:
> Sure, but that's a relatively tractable UI problem
Indeed. You know how to solve it, and I know how to
solve it, yet th
"James A. Donald" writes:
>For password-authenticated key agreement such as TLS-SRP or TLS-PSK to work,
>login has to be in the chrome.
Sure, but that's a relatively tractable UI problem (and see the comment below
on Camino). Certificates on the other hand are an apparently intractable
busin
Thomas Hardjono wrote:
Having worked at a large CA for along time (trying to push for client-side
certs with little luck), here are some thoughts on what Chrome could provide:
There are use cases where a centralized authority is useful.
Client side is not one of them.
Typical usage is "is thi
Peter Gutmann wrote:
> This is predicated on the assumption that it's
> possible to make certificates usable for general
> users. All the empirical evidence we have to date
> seems to point to this not being the case. Wouldn't
> it be better to say "What can we do to replace
> certificates with
Ben,
Having worked at a large CA for along time (trying to push for client-side
certs with little luck), here are some thoughts on what Chrome could provide:
(a) Association with net identities: Provide some way for the user to associate
his/her X.509 cert with an "internet identity" string (eg
On 08/06/09 07:33, James A. Donald wrote:
The fundamental problem with certificates is getting them.
digital certificate design point supposedly was the dial-up email of the early
80s,
dial-up, exchange email, hang-up ... and then faced with how to deal with first
time email from complete stra
Ben Laurie writes:
>So, I've heard many complaints over the years about how the UI for
>client certificates sucks. Now's your chance to fix that problem -
>we're in the process of thinking about new client cert UI for Chrome,
>and welcome any input you might have. Obviously fully-baked proposals
Ben Laurie wrote:
So, I've heard many complaints over the years about how the UI for
client certificates sucks. Now's your chance to fix that problem -
we're in the process of thinking about new client cert UI for Chrome,
and welcome any input you might have. Obviously fully-baked proposals
are m
33 matches
Mail list logo
