Re: Personal crypto device (or smart card) success stories?

2007-09-08 Thread Anders Rundgren
Well Kyle, we sure have different views on this subject!

Living in Europe where two-factor authentication is a standard feature for
things like on-line banking, I think the problem with PKI has some other
down-to-earth explanations as well.

In Europe OTP (One Time Password) systems are the by far most common.
Why?  1) OTP tokens do not need to be "connected" to the PC.  2) OTP
tokens do not need currently rather non-standard card drivers etc.

Some people believes that Microsoft's CardSpace will be the solution for
consumers.  It is already available for Firefox.   Personally I don't think any
authentication system requiring local software and connectors will be
of much importance until the mobility issue is solved.  Try using a smart
card in a public computer like the ones you find at airports :-(

For the zillion of corporate intranet applications that do not use PKI, I
believe the primary reason for not using PKI is that many of these systems
have their user database for reasons that it is hard managing small
groups in a delegated fashion using Active Directory.  For integrated
applications it seems that Kerberos is a better way than making all
applications talk PKI.

Anders Rundgren

- Original Message - 
From: "Kyle Hamilton" <[EMAIL PROTECTED]>
To: 
Sent: Sunday, September 09, 2007 05:04
Subject: Re: Personal crypto device (or smart card) success stories?


On Sep 6, 2007, at 11:24 PM, Nelson Bolyard wrote:
> No other success stories?
> Are there really no other readers of this list using their own  
> personal
> crypto devices for reading/writing signed and/or encrypted email?
>
> Maybe NSS is way overkill for the needs of mozilla users?
>
> ___
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto

Nobody uses it because nobody understands it.  Nobody understands it  
because nobody understands legalese.  Everything associated with  
cryptography (the way it's practiced today) has to do with legalese  
-- knowing the legal identity of an entity so that you could perhaps  
later sue them for some unknown reason.

Everyone prefers to use unsigned/unencrypted systems because they are  
less complex to set up.  They are more invisible -- they don't  
needlessly throw up messages about 'warning!'s that exist outside of  
the sender's or receiver's control (have you ever tried to use signed  
messages via Outlook Express over Hotmail?  They append a Hotmail  
footer to every message body, which invalidates the signature).  They  
are less frightening -- "what do you mean, my full legal name and  
address and everything is going to go out for anybody to read?!" [the  
envelope information isn't kept secret in PEM, and certificates are  
sent unencrypted via TLS unless an anonymous cipher's used first and  
then a full protocol renegotiation with certificate presentment occur  
after the anonymous cipher is established].  They have fewer moving  
parts that all have to be set up in just the right way.

Frankly, cryptography as implemented everywhere is a failure.  Nobody  
understands PGP, nobody uses it.  Nobody understands NSS (or the  
underlying concepts of X.509), nobody uses it.  We only buy the  
certificates for our servers because of the "Netscape Tax" -- the  
requirement that Netscape built into its browsers that every server  
must have a valid X.509 certificate signed by a pre-approved entity  
that Netscape contracted with.  The user didn't even get the chance  
to choose what entities to trust until later -- and that process is  
still so arduous that no user would really want to try to learn how to.

Enforcing this concept that X.509 (and the X.500 naming hierarchy,  
and everything associated) is the One True Way is certainly the only  
way to keep the US military, or governments in Europe, in tune with  
it -- but really, the requirements that the usage model impose create  
a hardship for everyone else who's trying to use it for non-Legal  
purposes.  Nobody should have to be so rigidly regimented when they  
try to use it unless they're trying to adhere to Legal requirements.

The amount of information in a certificate is staggering.
It takes training to be able to read an actual certificate ["what's  
this "S=Kyle Hamilton,[EMAIL PROTECTED],CI=Las  
Vegas,ST=Nevada,C=US" mean?  Do I speak for the City of Las Vegas  
simply because I'm located here in the X.500 Directory structure?].
It takes tools that most people have never heard of or used to be  
able to get anything useful out of a certificate (openssl asn1parse  
being one of them).
The certified information is so hidden by the chrome of every  
application that uses it that it's only the most truly paranoid  
people who look at it anyway.
...and even then, the information they need to see isn't put in front  
of their face when they double-click the lock icon, they instead get  
a completely worthless explanatio

Re: Personal crypto device (or smart card) success stories?

2007-09-08 Thread Kyle Hamilton
On Sep 6, 2007, at 11:24 PM, Nelson Bolyard wrote:
> No other success stories?
> Are there really no other readers of this list using their own  
> personal
> crypto devices for reading/writing signed and/or encrypted email?
>
> Maybe NSS is way overkill for the needs of mozilla users?
>
> ___
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto

Nobody uses it because nobody understands it.  Nobody understands it  
because nobody understands legalese.  Everything associated with  
cryptography (the way it's practiced today) has to do with legalese  
-- knowing the legal identity of an entity so that you could perhaps  
later sue them for some unknown reason.

Everyone prefers to use unsigned/unencrypted systems because they are  
less complex to set up.  They are more invisible -- they don't  
needlessly throw up messages about 'warning!'s that exist outside of  
the sender's or receiver's control (have you ever tried to use signed  
messages via Outlook Express over Hotmail?  They append a Hotmail  
footer to every message body, which invalidates the signature).  They  
are less frightening -- "what do you mean, my full legal name and  
address and everything is going to go out for anybody to read?!" [the  
envelope information isn't kept secret in PEM, and certificates are  
sent unencrypted via TLS unless an anonymous cipher's used first and  
then a full protocol renegotiation with certificate presentment occur  
after the anonymous cipher is established].  They have fewer moving  
parts that all have to be set up in just the right way.

Frankly, cryptography as implemented everywhere is a failure.  Nobody  
understands PGP, nobody uses it.  Nobody understands NSS (or the  
underlying concepts of X.509), nobody uses it.  We only buy the  
certificates for our servers because of the "Netscape Tax" -- the  
requirement that Netscape built into its browsers that every server  
must have a valid X.509 certificate signed by a pre-approved entity  
that Netscape contracted with.  The user didn't even get the chance  
to choose what entities to trust until later -- and that process is  
still so arduous that no user would really want to try to learn how to.

Enforcing this concept that X.509 (and the X.500 naming hierarchy,  
and everything associated) is the One True Way is certainly the only  
way to keep the US military, or governments in Europe, in tune with  
it -- but really, the requirements that the usage model impose create  
a hardship for everyone else who's trying to use it for non-Legal  
purposes.  Nobody should have to be so rigidly regimented when they  
try to use it unless they're trying to adhere to Legal requirements.

The amount of information in a certificate is staggering.
It takes training to be able to read an actual certificate ["what's  
this "S=Kyle Hamilton,[EMAIL PROTECTED],CI=Las  
Vegas,ST=Nevada,C=US" mean?  Do I speak for the City of Las Vegas  
simply because I'm located here in the X.500 Directory structure?].
It takes tools that most people have never heard of or used to be  
able to get anything useful out of a certificate (openssl asn1parse  
being one of them).
The certified information is so hidden by the chrome of every  
application that uses it that it's only the most truly paranoid  
people who look at it anyway.
...and even then, the information they need to see isn't put in front  
of their face when they double-click the lock icon, they instead get  
a completely worthless explanation of just what 'security' (in the  
context of an un-wiretappable TCP connection) means.  It takes at  
least one more click to see the information that the X.509  
certificate is supposed to certify.

And now, we have laws that protect childrens' information.  This  
means that if a kid goes to a site that accepts certificate-based  
authentication, then they've suddenly made the operator of that site  
liable -- they don't even get the chance to say "we don't want kids'  
information" unless they design their webservice really well.  So  
now, client-side certificate-based authentication systems are now too  
risky to put in place.  (On the flip side, we now have Sarbanes-Oxley  
and other requirements, so we have business needs that non-business  
users need to not have to deal with.)

It's very, very disheartening to see everyone beat their heads  
against the same structural walls that they've built around  
themselves when the reality is, the use of cryptography just cannot  
become a sustainable, thriving, useful, ubiquitous, invisible  
technology until these design flaws are worked out.

I believe that NSS -- overkill as it may be for most users at this  
time -- does provide very useful functionality for anyone who might  
be interested in looking at alternative information which might be  
held in a certificate.  Cryptography, as a whole and holistic concept  
(e

hardware security module storing x509 client cert: mozilla code for loging into subversion

2007-09-08 Thread rupert thurner
hi,

we noticed that the support for hardware security modules (smartcards)
storing ssl client certificates in mozilla/firefox is quite good.

is it possible to somehow reuse this for serf to provide x509 client
certificate login for subversion, via the serf library? see
http://code.google.com/p/serf/issues/detail?id=27.

regards,

rupert.

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: PSM:CertPrompt

2007-09-08 Thread Eddy Nigg (StartCom Ltd.)
A few additional comments to make that clearer:

Eddy Nigg (StartCom Ltd.) wrote:
> I noticed, that in the first section under "IE Current Usage", it says 
> that IE will _always_ use that certificate (or lack of certificate) for 
> that site. Only in the second part this is corrected with "IE will 
> always use that certificate to authenticate, until the user _closes_ IE or 
> hits the 'Clear SSL Cache' button. But again in the last section it says 
> "Find all the certificates, present them to the user, remember the 
> user's selection _forever_" which isn't correct.
>   
See the underlined content. Once it says "always", then until the user 
"closes" IE and then again "forever". In short IE will prompt for the 
certificate again after one closes IE.
> However this page leads me to something else actually. When a browser 
> doesn't have the complete chain installed in the browser, client auth 
> fails - and this even if the server presents the complete chain as 
> expected to the browser. Additionally, if the chain is missing or no 
> client certificate is installed in the browser, some error like -12777 
> pops up (Don't remember the correct number right now). This of course is 
> less then helpful for the ones in the unknown
>   
The section above is about Mozilla/Firefox, not about IE. This wasn't 
very clear in my post.

-- 
Regards 
 
Signer: Eddy Nigg, StartCom Ltd. 
Jabber: [EMAIL PROTECTED] 
Blog:   Join the Revolution! 
Phone:  +1.213.341.0390
 

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto