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 rocket
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 crimi
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: http://www.freepatentsonline.com/665116
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
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 authentica
Philipp =?iso-8859-1?q?G=FChring?= <[EMAIL PROTECTED]> writes:
>I had the feeling that Microsoft wants to abandon the usage of client
>certificates completely, and move the people to CardSpace instead.
While there's an obvious interpretation of that ("Microsoft want to lock
everyone into CardSpac
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
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...
>
> Al
| 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 we
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. recent
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 th
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 sy
David Wagner <[EMAIL PROTECTED]> writes:
>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.
Because they're essentially u
David Wagner wrote:
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 least, the problem of theft of web authenticators
-- it obviously won't help with theft of SSNs). If users don't know
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
http://www.arnnet.com.au/index.
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 paradi
>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 eve
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 goin
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 i
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 securi
>> (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
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 ch
Dave Howe <[EMAIL PROTECTED]> writes:
>SSL - Cludge thrown together by a browser manufacturer,
To paraphrase Winston Churchill, "SSL is the worst secure-pipe protocol,
except for all the others". Like most people here, I can find assorted nits
to pick with it (mostly message-formatting stuff and
On Jan 30, 2008 9:04 PM, Philipp Gühring <[EMAIL PROTECTED]> 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 identit
enero 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 pe
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 iden
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 t
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 serve
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 wou
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 assumes
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 in
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 ou
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 username+pas
At Wed, 30 Jan 2008 11:25:04 +0100,
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
34 matches
Mail list logo
