Philipp Gühring wrote:
I had the feeling that Microsoft wants to abandon the usage of client
certificates completely, and move the people to CardSpace instead.
But how do you sign your emails with CardSpace? CardSpace only does the
realtime authentication part of the market ...
It's not
Thierry Moreau [EMAIL PROTECTED] writes:
At first, it seems neat. But then, looking at how it works in practice: the
client receives an e-mail notification soliciting him to click on a HTML link
and then enroll for a security certificate, the client is solicited exactly
like a phishing criminal
Leichter, Jerry wrote:
While trying to find something else, I came across the following
reference:
Title: Sender driven certification enrollment system
Document Type and Number: United States Patent 6651166
Link to this page:
On Feb 11, 2008, at 8:28 AM, Philipp Gühring wrote:
I had the feeling that Microsoft wants to abandon the usage of client
certificates completely, and move the people to CardSpace instead.
But how do you sign your emails with CardSpace? CardSpace only does
the
realtime authentication part of
Imagine if a website could instruct your browser to transparently
generate a public/private keypair for use with that website only and
send the public key to that website. Then, any time that the user
returns to that website, the browser would automatically use that
private key to
Is anyone aware of any third-party usability studies on CardSpace,
OpenID, ...?).
I'm not. It would be a good opportunity for security usability
researchers to contribute though.
[0] I'm not sure whether putting CardSpace and Liberty in such close
proximity in the above line was a
Hi,
Microsoft broke this in IE7... It is no longer possible to generate and
enroll a client cert from a CA not on the trusted root list. So private
label CAs can no longer enroll client certs. We have requested a fix,
so this may come in the future, but the damage is already done...
Also
| By the way, it seems like one thing that might help with client certs
| is if they were treated a bit like cookies. Today, a website can set
| a cookie in your browser, and that cookie will be returned every time
| you later visit that website. This all happens automatically. Imagine
| if a
re:
http://www.garlic.com/~lynn/aadsm28.htm#30 Fixing SSL
so lots of the AADS
http://www.garlic.com/~lynn/x959.html#aads
scenarios are that every place a password might appear, have
a public key instead.
for various of the cookie authentication operations ... also
think kerberos tickets
Tim Dierks writes:
(there are totally different reasons that client certs aren't being
widely adopted, but that's beside the point).
I'd be interested in hearing your take on why SSL client certs aren't
widely adopted. It seems like they could potentially help with the
phishing problem (at
#aads
and certificateless public key
http://www.garlic.com/~lynn/subpubkey.html#certless
we referred to the scenario as person-centric ... as a contrast
to institutional-centric oriented implementations.
past posts in this thread:
http://www.garlic.com/~lynn/aadsm28.htm#20 Fixing SSL (was Re: Dutch
On 2/9/08, David Wagner [EMAIL PROTECTED] wrote:
By the way, it seems like one thing that might help with client certs
is if they were treated a bit like cookies.
I don't see how this helps with phishing. Phishers will just go after
the password or other secrets used to authenticate a new
On Sat, Feb 09, 2008 at 05:04:28PM -0800, David Wagner wrote:
By the way, it seems like one thing that might help with client certs
is if they were treated a bit like cookies. Today, a website can set
a cookie in your browser, and that cookie will be returned every time
you later visit that
They can't be as anonymous as cash if the party being dealt with
can be identified. And the party can be identified if the
transaction is online, real-time. Even if other clues are erased,
there's still traffic analysis in this case.
If I show up at a store and pay cash for something every
a recent reference
Research unmasks anonymity networks
http://www.techworld.com/security/news/index.cfm?newsID=11295
Research unmasks anonymity networks
http://www.networkworld.com/news/2008/020108-research-unmasks-anonymity.html
Research unmasks anonymity networks
Anne Lynn Wheeler [EMAIL PROTECTED] write:
one of my favorite exchanges from the mid-90s was somebody claiming
that adding digital certificates to the electronic payment
transaction infrastructure would bring it into the modern age. my
response was that it actually would regress the
StealthMonger wrote:
They can't be as anonymous as cash if the party being dealt with can
be identified. And the party can be identified if the transaction is
online, real-time. Even if other clues are erased, there's still
traffic analysis in this case.
What the offline paradigm has going
(as if anyone uses client certificates anyway)?
Guess why so few people are using it ...
If it were secure, more people would be able to use it.
People don't use it because the workload of getting signed up is vastly
beyond their skillset, and the user experience using the things
Eric Rescorla wrote:
(as if anyone uses client certificates anyway)?
Guess why so few people are using it ...
If it were secure, more people would be able to use it.
No, if it were *convenient* people would use it. I know of absolutely
zero evidence (nor have you presented any) that people
Ian G wrote:
The PII equation is particularly daunting, echoing Lynn's early '90s
experiences. I am told (but haven't really verified) that the
certificate serial number is PII and therefore falls under the full
weight of privacy law regs ... this may sound ludicrous, but privacy
and
Philipp Gühring wrote:
I once implemented SSL over GSM data channel (without PPP and without
TCP), and discovered that SSL needs better integrity protection than
raw GSM delivers. (I am quite sure that´s why people normally run PPP
over GSM channels ...) SSH has the same problems. It also
Eric Rescorla wrote:
Huh? What are you claiming the problem with sending
client certificates in plaintext is (as if anyone uses
client certificates anyway)?
Well that is one problem - no one uses them, and no one
should use them, while PKI was designed under the
assumption that everyone would
Hi,
Huh? What are you claiming the problem with sending client certificates
in plaintext is
* It´s a privacy problem
* It´s a security problem for people with a security policy that requires the
their identities to be kept secret, and only to be used to authenticate to
the particular server
Philipp Gühring wrote:
Hi,
SSL key distribution and management is horribly broken,
with the result that everyone winds up using plaintext
when they should not.
Yes, sending client certificates in plaintext while claiming that SSL/TLS is
secure doesn´t work in a world of phishing and
At Thu, 31 Jan 2008 03:04:00 +0100,
Philipp Gühring wrote:
Hi,
Huh? What are you claiming the problem with sending client certificates
in plaintext is
* It´s a privacy problem
* It´s a security problem for people with a security policy that requires the
their identities to be kept
de 2008 3:04
Para: Eric Rescorla
CC: Cryptography; Rasika Dayarathna
Asunto: Re: Fixing SSL (was Re: Dutch Transport Card Broken)
Hi,
Huh? What are you claiming the problem with sending client certificates
in plaintext is
* It´s a privacy problem
* It´s a security problem for people
On Thu, 31 Jan 2008 03:04, [EMAIL PROTECTED] said:
If you want a public example of client certificate usage:
https://secure.cacert.org/
(You need a (free) client certificate from www.CAcert.org to be able to
access
Which has the problem that you may use any certifcate you ever created
wit
Hi,
SSL key distribution and management is horribly broken,
with the result that everyone winds up using plaintext
when they should not.
Yes, sending client certificates in plaintext while claiming that SSL/TLS is
secure doesn´t work in a world of phishing and identity theft anymore.
We
Philipp Gühring wrote:
Yes, sending client certificates in plaintext while claiming that SSL/TLS is
secure doesn´t work in a world of phishing and identity theft anymore.
We have the paradox situation that I have to tell people that they should use
HTTPS with server-certificates and
At Wed, 30 Jan 2008 17:59:51 -,
Dave Korn wrote:
On 30 January 2008 17:03, Eric Rescorla wrote:
We really do need to reinvent and replace SSL/TCP,
though doing it right is a hard problem that takes more
than morning coffee.
TCP could need some stronger integrity protection. 8
On 30 January 2008 17:03, Eric Rescorla wrote:
We really do need to reinvent and replace SSL/TCP,
though doing it right is a hard problem that takes more
than morning coffee.
TCP could need some stronger integrity protection. 8 Bits of checksum isn´t
enough in reality. (1 out of 256
31 matches
Mail list logo
