Re: [cryptography] Is it just me or is this fundamentally broken?

[Peter Gutmann]

Peter Saint-Andre  writes:

>No one uses XEP-0027 these days, they all use OTR. The PGP integration with
>XMPP clients was an early experiment in the Jabber community before we even
>called it XMPP. Think 13+ years ago. But clients never signed empty strings,
>although we never fixed the spec because no one was using the technology.
>I'll push to make the spec Obsolete.

It might be a good idea to do this, since the reason I found out about this
part of the spec was because someone complained that they were having problems
signing an empty string.

Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Is it just me or is this fundamentally broken?

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 3/4/13 4:42 PM, Peter Gutmann wrote:
> Quoting http://xmpp.org/extensions/xep-0027.html#signing:
> 
> Signing enables a sender to verify that they sent a certain block
> of text. [...] The text that is signed MAY be the empty string.
> 
> (There's no metadata or anything there, just a raw signature).

No one uses XEP-0027 these days, they all use OTR. The PGP integration
with XMPP clients was an early experiment in the Jabber community
before we even called it XMPP. Think 13+ years ago. But clients never
signed empty strings, although we never fixed the spec because no one
was using the technology. I'll push to make the spec Obsolete.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRNUldAAoJEOoGpJErxa2pTEIQAIGMstyjlTE1v4pX8IyXxF0j
9TkcIqPKvJmUwM+SRC5cFic/FarOATXezkJPypxwjvscmcGmVKxMVDBT1PAjssnM
kjJFLSU6f93ujySIS/BEfGbV5KbjTSOwqAvhiORYpQ5Mt2Cl9h/kIvfElBf7zDbf
Bgt8gRT4fGQwYaEMNJH+0eBbvFuvRMYbyh8J/lD9sbCEmcXAFYfS6WxfSAEb2Zrm
lefAKYlHP+t6gzXJHrCFGG4JPNP8k37nwDsIp/SW4d/VOu3HYjZAd8Xe1y+hpKZM
lETcDM7HBCr0hGs3OSh9K/qmlkV8vvShROf0+khZvdeXiuuUuWuhjmnhG9urqt2S
uHUOUv1q0BnnScDOT4VQJ31pdOdb3iJ5JedlgYJijV26JO94Ams3TadTIQfPoRa4
uzByU7E8lCtcwd6+tBoGLr+9S8spESsmRj3OAOsQuPUl1nOrjEO1rWbQE/e3HXgp
dUfFZKIQGwrJRFK9MsR2JQVPKGwsi3Y7BdqsqkKx9ozAoWu3LRuqBdeEgT0eTlb6
st1tMCNGsZtk8ZUFeXYhmbGRJJPfcRotPom3r564tvBTCM/m0bu7VIuJaS24Mu4U
GnRCIHxZiLY5yBL7EVCqabdUihLmLiYaF/Nu/VgikaxDv+IXyKoe+qYiWj6ppyN1
W0xarAcz2tF8RSYoGWZy
=mfUh
-END PGP SIGNATURE-
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[Joe St Sauver]

Hi,

strife asked:

#Can anyone enlighten me why client TLS certificates are used so rarely? It
#used to be a hassle in the past, but now at least the major browsers offer
#quite decent client cert support, 

Not quite seeing eye-to-eye with you on the "quite decent client cert 
support" point, I'm afraid. Client cert user interaction still deserves
poor marks for complexity and user opacity, I think.

I did a preconference seminar for Educause Security Professionals 2012 on
client certificates, and it's actually sort of surprising how deeply buried
many bits of the current browser client cert implementation are. See
http://pages.uoregon.edu/joe/secprof2012/sec-prof-2012-client-certs.pdf

Or consider the level of native OS support for USB format PKI hard tokens
or smart cards on some operating systems, just to mention another example
of how client certificate support is still not really ready for prime time
at this point.

[In fact, if anyone's looking for a nice paper topic, I think a terrific
topic might be "Why Johnny Can't Ecrypt Using Client Certs, Either"
modeled on http://static.usenix.org/events/sec99/whitten.html ]

#and seeing how most people struggle with passwords, I don't see why 
#client certs could not be beneficial even to "ordinary users".

Client certs *could* be hugely beneficial to even ordinary users -- 
imagine their use for EAP-TLS authentication, for example. 

The devil, as always, is in the details.

Assume the average person has multiple devices these days -- maybe a 
desktop at work, a laptop for travel, a tablet at home, a smartphone, etc.

If I want to use client certs for encryption/decryption, I need the *same*
cert on all of those devices, or on a portable device (such as a USB-format 
PKI hard token, or a smart card) so I can take my credentials with me. 
Sync'ing certs from one device to another isn't totally impossible, but 
backing up, manually transfering and reinstalling certs on multiple devices
really isn't simple enough for most mere mortals. [Attempts to deploy a 
unique client cert to each device have issues of their own that we'll 
skip for the purposes of this note]

Smart cards or USB-format PKI hard tokens are a nice alternative, but 
somewhat expensive, and you can't just run down to your favorite local
office supply store or neighborhood compute supply store and buy one.

Then there's the fact that not all devices easily accomodate USB-format
PKI hard tokens or smart cards, but if you *are* able to use a USB format 
PKI hard token or smart card, at least the credentials stored on those 
devices can be stored in a non-exportable format, which is good given 
the uptick in malware's that has reportedly been scraping client certs 
of late.

Smart cards or hard tokens are also required if you're shooting for the
highest NIST LOAs, but there's so much more that's required to get there
that in many ways the use of smart cards or hard tokens is a minor 
matter relative to identity proofing requirements and all the rest of
what's require -- and it's hard to find anyone who actually needs LOA-4,
at least in higher ed.

Speaking of identity proofing, many times client certs only map to email
addresses, not to "real names," and not to guaranteed-unique and 
never-to-be-reused arbitrary identifiers (like the EPPN). Some may find 
that choice less than full satisfactory.

Or let's talk about key servers/directory models. Let me wave my magic
wand and magically create an Internet-wide directory for client certs,
perhaps modeled on PGP public key servers. Unfortunately, I don't see 
much interest in fielding an animal of that sort, and w/o it, you're
either reduced to enterprise-level directories, or the painful process
of requesting a signed message to bootstrap key exchange for encryption
purposes (yuck)

And the list goes on...

Bottom line, I think that there's still a lot of work ahead if you want
to do client certs at scale...

Regards,

Joe

Disclaimer: all opinions strictly my own.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

[cryptography] Is it just me or is this fundamentally broken?

[Peter Gutmann]

Quoting http://xmpp.org/extensions/xep-0027.html#signing:

  Signing enables a sender to verify that they sent a certain block of text.
  [...] The text that is signed MAY be the empty string.

(There's no metadata or anything there, just a raw signature).

Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[Tony Arcieri]

On Sun, Mar 3, 2013 at 11:22 PM,  wrote:

> Hi,
>
> Can anyone enlighten me why client TLS certificates are used so rarely? It
> used to be a hassle in the past, but now at least the major browsers offer
> quite decent client cert support, and seeing how most people struggle with
> passwords, I don't see why client certs could not be beneficial even to
> "ordinary users".


Not sure what your idea of "quite decent client cert support" is, however I
don't think this is the case:

1) It's not easy for users to use client certs instead of passwords. Try to
build a demo of a site that makes use of client certs for logging in. I
think you'll find it an exercise in frustration
2) It's not easy to move client certs around from browser-to-browser, e.g.
if you want to log into the same site from multiple browsers (the sync
features of Chrome and Firefox could potentially make this easier)
3) There's no uniform API for managing client certs from JavaScript

-- 
Tony Arcieri
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[Guido Witmond]

On 03/04/2013 11:15 PM, Open eSignForms wrote:

Step 10 will make it impossible for you mom. ;-)



10. You write your message, sign it with your private key, encrypt
it with your public key and deliver the ciphertext to

https://guidos-secure-mail.com/deliver?to=StealthMongersMom&ciphertext=MIIABC...XZY===


(openssl s/mime encoded message, without headers)




You're right. Wrong key for encryption. Should use mom's public key for 
encryption.


Thanks, Guido.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Interesting Webcrypto question

[Taral]

On Mon, Mar 4, 2013 at 12:31 PM, Jeffrey Walton  wrote:
> Actually, its not too far fetched. In the mobile arena, I see a number
> of in-house browser based apps that can be side-loaded or distributed
> through a private or enterprise application store. When using these
> distribution channels, script injection and tampering is not a high
> risk because its part of the application bundle.

Can you mitigate the risk with the Chrome webstore too? Perhaps via
some kind of chain-of-trust or attestation scheme.

--
Taral 
"Please let me know if there's any further trouble I can give you."
-- Unknown
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Interesting Webcrypto question

[Jeffrey Walton]

On Mon, Mar 4, 2013 at 3:10 PM, Peter Thoenen  wrote:
> I'm catching up on this but it's a pretty easy answer.
>
>> Say you've implemented a bunch of crypto on your web page via Javascript.
>
> And this is where you went wrong.  Don't implement crypto (or anything of 
> import) client side period (if we are talking web based javascript stuff 
> here).
>
Actually, its not too far fetched. In the mobile arena, I see a number
of in-house browser based apps that can be side-loaded or distributed
through a private or enterprise application store. When using these
distribution channels, script injection and tampering is not a high
risk because its part of the application bundle.

Organizations like the browsers based and hybrid apps because they are
quick to develop, and HTML5 give them all sorts of annoying
capabilities, such as reverse proxies via WebSockets.

Its yet to be seen if we will get any useful security features for the
'side-loaded web app' model. I wrote to Ian and Alexey (authors of RFC
6455 - WebSockets) and asked for a method to query the underlying
connection so I could do unthinkable things such as aborting the
connecting or not transmitting the password if the certificate or
public key was not expected. I did not hear anything back.

Jeff
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Interesting Webcrypto question

[Peter Thoenen]

I'm catching up on this but it's a pretty easy answer.

> Say you've implemented a bunch of crypto on your web page via Javascript.


And this is where you went wrong.  Don't implement crypto (or anything of 
import) client side period (if we are talking web based javascript stuff here).

-Peter
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[Guido Witmond]

On 03/04/2013 06:10 PM, StealthMonger wrote:

 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1

 Peter Gutmann  writes:


 ... sit behind her with your arms crossed so you can't point to
 anything or type stuff out for her, and walk her through the process
 of acquiring and using one without leaving your chair or performing
 any part of the operation for her.

> Now imagine getting her to do the same using only a sheet of
> instructions you've written.

 Mother sits down at her computer to do email. Computer notices that
 she does not have an encryption key (client-side certificate),
 starts a background process to generate one, and tells her:

 From now on, you will have a new email address. Starting next week,
 the old one will no longer work.

 This will be the only computer on which you can receive email. If
 you ever want to use another computer, press "Add/Change Computer"
 below.

 [Computer finishes generating key with key ID xlzoazsabewlcc.]

 Your new email address is "xlzoazsabewlcc". It is now being
 broadcast worldwide. Tell your bank and all your friends.


How do you get that address communicated over the phone?

Let me try and help your mother:

Mother sits at computer, and asks: "What now?"

Me:
1. open firefox, install the secure email addon from: 
mozilla/addons/guidos-secure-email-plugin.xpi


She installs it.

2. browse to https://guidos-secure-mail.com/

She: how do you spell that?

Me: h-t-t-. dot com (with hands at my back)

3. Web browser connects to server, and the plug in validates server 
certificate against DNSSEC/DANE specified Root certificate. (It won't 
connect if there is an error here)


4. I ask her to press the 'Signup' button at the plugin (on the browser 
chrome, not in the window)


Browser plugin asks for username: Mom types: StealthMongersMom and she 
presses the ok-button.


5. Browser plugin requests client certificate at guidos-secure-mail.com 
with her chosen username. Browser receives certificate from the site, 
signed with a subCa of the same RootCa certificate as the server. 
Username must be unique, otherwise she needs to choose something different.


Mom has all she needs to send and receive secure mail.

6. Mom phones offspring and says I've got an email address: it's  
stmomo@@guisecmail.com (unintelligible due to line noise)


7. You: How do you spell that?

8. She: S-t-e-a. . . m-a-i-l  dot com

9. You type it in and your browser plugin looks up
https://guidos-secure-mail.com/cert-of?id=StealthMongersMom
It validates the server certificate and checks if the client cert 
is chained to the same RootCA.


10. You write your message, sign it with your private key, encrypt it 
with your public key and deliver the ciphertext to 
https://guidos-secure-mail.com/deliver?to=StealthMongersMom&ciphertext=MIIABC...XZY=== 
(openssl s/mime encoded message, without headers)


11. She logs in with her certificate, the site delivers the ciphertext 
and the plugin decrypts it with her private key


12. The plug in retrieves the certificate for the sender-address 
(StealthMonger@@nym), validates it against the DNSSEC/DANE RootCA 
for nym... and has a validated return address.


13. Your mom presses the reply-button, composes a message, her plug 
signs it with her private key, encrypts it with your public key. She 
delivers the message at 
nym...//deliver?to=StealthMonger&ciphertext=MIIDEF...ABC=== (important 
not to send to guidos-secure-email.com)


14. You receive the message and when the message signature matches that 
of the client certificate you got from step 9 you know that there is no 
man in the middle at guidos-secure-mail.com impersonating your mom. My 
site does not have your mom's private key to do so.


Notice that mom didn't validate any keys, nor did she ask you for your 
address. She just assumes that the first mail she gets is from you. It's 
the contents of the message that does the validation for her. Just like 
ordinary email.





 Anyone else who can log into this computer has access to all your
 bank accounts and email.


Please use Qubes-OS, Genode, Minix or any other POLA based OS and user 
interface to prevent the Dancing Pwnies. With Swiss-cheese-OS we can 
never reach security nirvana...




 Make sure your login password is strong.



Please don't use passwords, use a GPG key on a crypto-stick.com. 
Upcoming version 2 of the stick can store plenty of certificates and 
private keys on its secured sd-card.


Cheers, Guido.


___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[StealthMonger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Peter Gutmann  writes:

>  writes:

>>Can anyone enlighten me why client TLS certificates are used so
>>rarely?  It used to be a hassle in the past

> They're still a huge pain to work with, and probably always will be.
> If you don't believe me, go to your mother, sit her in front of a
> computer, sit behind her with your arms crossed so you can't point
> to anything or type stuff out for her, and walk her through the
> process of acquiring and using one without leaving your chair or
> performing any part of the operation for her.

> Now imagine getting her to do the same using only a sheet of
> instructions you've written.

Mother sits down at her computer to do email.  Computer notices that
she does not have an encryption key (client-side certificate), starts
a background process to generate one, and tells her:

   From now on, you will have a new email address.  Starting next
   week, the old one will no longer work.

   This will be the only computer on which you can receive email.  If
   you ever want to use another computer, press "Add/Change Computer"
   below.

   [Computer finishes generating key with key ID xlzoazsabewlcc.]

   Your new email address is "xlzoazsabewlcc".  It is now being
   broadcast worldwide.  Tell your bank and all your friends.

   This computer is the only computer in the world that can receive
   messages to this new address.  You should probably make a backup.
   Press "Make Backup" below.

   Anyone else who can log into this computer has access to all your
   bank accounts and email.  Make sure your login password is strong.

Simple as that.  (Well, almost.)  Admittedly, this is oriented to
email, not browsing.  But the browser can be told to look for the same
key ring for certificate material.

- -- 


 -- StealthMonger 
Long, random latency is part of the price of Internet anonymity.

   anonget: Is this anonymous browsing, or what?
   
http://groups.google.ws/group/alt.privacy.anon-server/msg/073f34abb668df33?dmode=source&output=gplain

   stealthmail: Hide whether you're doing email, or when, or with whom.
   mailto:stealthsu...@nym.mixmin.net?subject=send%20index.html


Key: mailto:stealthsu...@nym.mixmin.net?subject=send%20stealthmonger-key

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.9 

iEYEARECAAYFAlE0lwoACgkQDkU5rhlDCl4R9gCfVOs1ynBZUqmE8TGDH9HjSvt6
nhQAn3vZpOK91H+exiJf3gyoRR4OF28r
=NeCP
-END PGP SIGNATURE-

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[dan]

With respect to:

>...
> - repudiation: there is no way deny writing a message; leading to self 
> censoring.
> 
> In other words, everything I sign with my Thawte client certificate is 
> tied to my identity *for life*. That's why I don't use that thing. In 
> fact, I've long since lost the private key for it. With password based 
> accounts, I can decide to write under any pseudonym and keep control of 
> my privacy, at the price of having the hassle with passwords.
>
> I've tried to write a blog[1] on it.
>...
> witmond.nl/blog/2012/11/21/why-we-still-use-passwords.html

I agree with you entirely.  Though tangential enough to
perhaps be off-topic, I wrote on the same theme last month.

Identity as Privacy
geer.tinho.net/ieee/ieee.sp.geer.1301b.pdf

--dan

___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[Guido Witmond]

On 03/04/2013 08:22 AM, str...@riseup.net wrote:

Hi,

Can anyone enlighten me why client TLS certificates are used so rarely? It
used to be a hassle in the past, but now at least the major browsers offer
quite decent client cert support, and seeing how most people struggle with
passwords, I don't see why client certs could not be beneficial even to
"ordinary users".


Hi Strife,

I'ld like to add a few cents too:

The whole x509 client and server certificates were designed to be used 
with a global directory, called x500. The idea is that you can lookup 
the key of person you want to communicate to. Although this 'secures' 
the communication against tampering and keeps the contents confidential, 
it lacks three properties:
- there is no way to securely communicate with total strangers; you need 
to know their name

- privacy: every person has one-true-certificate-to-bind-them;
- repudiation: there is no way deny writing a message; leading to self 
censoring.


In other words, everything I sign with my Thawte client certificate is 
tied to my identity *for life*. That's why I don't use that thing. In 
fact, I've long since lost the private key for it. With password based 
accounts, I can decide to write under any pseudonym and keep control of 
my privacy, at the price of having the hassle with passwords.


I've tried to write a blog[1] on it.


Another reason why the Crypto-heaven did not materialise is that the 
current crop of operating systems is completely unfit to protect the 
user's interests. As soon as one piece of malware is inside, it's not 
your computer anymore. And with that the malware can abuse your 
expensive client certificate at will.


I believe only micro-kernel operating systems with POLA security layers 
on top of that can bring solace.
See Qubes-OS, Genode, Minix. Without such security any progress to use 
cryptography is doomed. See 'Dancing Pwnies' on wikipedia.


IanG and Peter Gutmann are completely correct that usability is key. 
Browsers have a long way to go. For example, log in at CAcert with your 
client certificate. That's easy. Now try to log out. That's impossible. 
The only thing you can do is to close your browser. Losing all other 
open tabs with it.




I've come up with a way to get out of this mess. I call it Eccentric 
Authentication.[2]


It's a protocol that will provide pseudonymous client certificates, 
eliminates passwords, allows total strangers to communicate securely at 
a dating site. With the addition of a *Cryptographic Same Origin Policy* 
we can end CRSF, block the most obnoxious advertisment-spies while still 
allowing CDN-networks, javascript-applications. I've designed a fully 
anonymous dating site where you _can_ limit abuse.


I've written about that too. In fact, my whole website handles about it. 
Feel free to explore and ask if things are not clear.


Cheers, Guido Witmond.

1: http://witmond.nl/blog/2012/11/21/why-we-still-use-passwords.html
2: http://witmond.nl/ecca/ecca.html


___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[Peter Gutmann]

 writes:

>Can anyone enlighten me why client TLS certificates are used so rarely? It
>used to be a hassle in the past

They're still a huge pain to work with, and probably always will be.  If you
don't believe me, go to your mother, sit her in front of a computer, sit
behind her with your arms crossed so you can't point to anything or type stuff
out for her, and walk her through the process of acquiring and using one
without leaving your chair or performing any part of the operation for her.

Now imagine getting her to do the same using only a sheet of instructions
you've written.

Whenever anyone asks "why aren't certificates/smart cards/whatever used more?"
they should be required to go through this exercise, and then they will be
enlightened.

NB: Remember to switch to a fresh mother every time you re-try this
experiment with some new technology.

Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Workshop on Real-World Cryptography

[Peter Gutmann]

Jon Callas  writes:

>(Personally, I don't like GCM. I think it's too tetchy. But I'm pretty blase
>about PKCS#1, because I'm used to pouring over it to make sure it's done
>right.)

Same here.  GCM combines the scariest features of CTR mode (it's RC4 all over 
again, apart from SSL people have managed to get that wrong almost everywhere 
it's been used) and GHASH (all the side-channels you can eat).  With CBC+HMAC 
we at least know what we're getting and can defend against it, with GCM 
there's years of attacks still waiting to be published.

Peter.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography

Re: [cryptography] Client TLS Certificates - why not?

[ianG]

On 4/03/13 10:22 AM, str...@riseup.net wrote:

Hi,

Can anyone enlighten me why client TLS certificates are used so rarely?



My thoughts only, not authoritative.

The big answer today is momentum, I would say.

In the past, I would say that forces were deployed against TLS 
certificates.  The CAs did not push them because the market for selling 
client-side certificates at a commercially sensible price wasn't there, 
it's a loss making proposition.  Still isn't/is.  But what they did do 
successfully is convince people that certificates not signed by 
browser-CAs were evil.  They got their cake and their still eating it.


The combination of these forces pushed all the developers over to 
passwords, and they've been on that since forever.  Same cake, now about 
18 years old, and causing predictable tummy aches.



It
used to be a hassle in the past, but now at least the major browsers offer
quite decent client cert support, and seeing how most people struggle with
passwords, I don't see why client certs could not be beneficial even to
"ordinary users".



Browsers need a couple of things:  create a new cert on the fly, and to 
fix the certs on a per-site level.  But more than anything, they need to 
get their heads out of committee holes and start doing real security 
work for themselves.  Thankfully that seems to be happening over at google.



With CAcert, there is even an excellent infrastructure in place that could
allow people to generate signed pseudonymous client certificates. A
service provider could limit the amount of certificates allowed per user
(as validated by CAcert), maybe even the amount of points required etc.



As you mentioned it:  CAcert tried to move all its infra over to 
certificates.  The results were mixed.  Some things worked very well, 
somethings less well.  However, the places where things worked less well 
were pretty much all to do with the software just not evolving in that 
direction.


My personal experience is that writing the cert-based user 
authentication is easier and more robust than writing the password 
authentication system.  (I've done both in PHP.)  But it does require a 
bit more than copycat design :)  For example, one has to find a way to 
handle multiple certs for the same person, which requires one to stress 
the claims of the CA more than they are capable of being stressed.  In 
particular, if cert A says "John Smith" and cert B says the same "John 
Smith", are we happy?  I was... but I had to windmill it a little.



That way, one could provide services without the requirement of
registration, and still effectively limit abuse?


Certs solve the spam problem, and the password security problem.  And 
the phishing problem.  Oh, and the lost password problem, as a bonus :)


More or less, or, at least, certs lift the bar a long way.

What's more, if they were used more often, and client & server software 
were to evolve to respect them, we'd be halfway to a decent security 
model.  For example, properly used (afair, impossible in current 
browsers because we can't easily get general signing access to the certs 
from say javascript) we'd be able to use the certs for proper 
transaction signing, which would get us decent accounting software 
instead of the "don't click Pay twice" nonsense standard aka online banking.




iang
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography