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,
On Wed, 09 Sep 2009 15:42:34 +1000
James A. Donald jam...@echeque.com 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
On Thu, Sep 03, 2009 at 04:26:30PM +1200, Peter Gutmann wrote:
Steven Bellovin s...@cs.columbia.edu 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
Ian G i...@systemics.com 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).
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
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
On Aug 26, 2009, at 6:26 AM, Ben Laurie wrote:
On Mon, Aug 10, 2009 at 6:35 PM, Peter Gutmannpgut...@cs.auckland.ac.nz
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
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
Steven Bellovin s...@cs.columbia.edu 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
On Mon, Aug 10, 2009 at 6:35 PM, Peter Gutmannpgut...@cs.auckland.ac.nz 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
[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
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
James A. Donald jam...@echeque.com 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,
James A. Donald jam...@echeque.com 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
James A. Donald jam...@echeque.com 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
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
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:
In this UI discussion, I think its less
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,
James A. Donald jam...@echeque.com 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
James A. Donald jam...@echeque.com 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
--
James A. Donald jam...@echeque.com 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
[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
James A. Donald jam...@echeque.com 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
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
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
Ben Laurie b...@google.com 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
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
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.
28 matches
Mail list logo
