3 ms·

Slightly off-topic: why didn't client-side certificates ever become a thing?

by sowbug 9y ago

Santosh83 9y ago
Passwords were already almost universal even before ANY encryption, during the early days of the WWW and before that too.
- diggernet 9y ago
  Encryption has been around longer than computers.
  - acdha 9y ago
    That's technically true but irrelevant: on the web, SSL came well after the initial wave of adoption and U.S. companies were restricted by law[1] from exporting strong encryption to people outside of the United States. It took awhile to get programs updated and for years it was common to see separate versions (or even third-party patch trees) on download pages. All of that meant that someone launching a service couldn't assume that their users’ software supported encryption at all or securely for years. Coupled with the previously mentioned horrible user experience and cost of certificates, that really killed the idea since the password experience was both easier and far more familiar. 1. https://en.wikipedia.org/wiki/Export_of_cryptography_from_the_United_States#PC_era https://en.wikipedia.org/wiki/Export_of_cryptography_from_th...
npongratz 9y ago
Some old discussion here: https://news.ycombinator.com/item?id=6732110 https://news.ycombinator.com/item?id=6732110
dfox 9y ago
There are two main reasons: 1) In the beginning the whole X.509/PKCS PKI mechanism was seen as something that came out of X.500 and other telco stuff, is centralized, complex and expensive (all of these things are in fact true for the originally envisioned usage) and thus irrelevant for decentralized internet. (for example, the L for "Lightweight" in "LDAP" essentially means that it uses passwords instead of client side certificates) 2) The UX in early SSL capable browsers for client-side certificates was horrible (In Netscape the whole SSL configuration was in completely separate dialog from browser settings, which was incredibly complex. IE uses SSL implementation from windows which is also used for lots of other things and has centralized configuration and also even today creates confusing dialogs when site requests client certificate). It's somewhat ironic that various ActiveX/Java based replacements of this horrible UX are in fact often even more unusable.
- zeveb 9y ago
  What's really sad to me is that SPKI (RFCs 2692 & 2693) addressed centralisation, complexity and cost, and was more-or-less completely ignored. If the browser and server vendors had just supported it, I really think that it could have had a chance. It was even backwards-compatible with X.509!
raesene6 9y ago
painful maintenance - most users don't want to manage certificates and crypto keys especially in a multi-device world. that's likely the main one If you don't use a hardware module certificates are easily stolen by malware and as revokation is often problematic, stolen certs can be quite bad news.

Slightly off-topic: why didn't client-side certificates ever become a thing?

by sowbug 9y ago

Slightly off-topic: why didn't client-side certificates ever become a thing?

Passwords were already almost universal even before ANY encryption, during the early days of the WWW and before that too.

diggernet 9y ago
Encryption has been around longer than computers.
- acdha 9y ago
  That's technically true but irrelevant: on the web, SSL came well after the initial wave of adoption and U.S. companies were restricted by law[1] from exporting strong encryption to people outside of the United States. It took awhile to get programs updated and for years it was common to see separate versions (or even third-party patch trees) on download pages. All of that meant that someone launching a service couldn't assume that their users’ software supported encryption at all or securely for years. Coupled with the previously mentioned horrible user experience and cost of certificates, that really killed the idea since the password experience was both easier and far more familiar. 1. https://en.wikipedia.org/wiki/Export_of_cryptography_from_the_United_States#PC_era https://en.wikipedia.org/wiki/Export_of_cryptography_from_th...

npongratz 9y ago

Some old discussion here: https://news.ycombinator.com/item?id=6732110 https://news.ycombinator.com/item?id=6732110

dfox 9y ago

There are two main reasons: 1) In the beginning the whole X.509/PKCS PKI mechanism was seen as something that came out of X.500 and other telco stuff, is centralized, complex and expensive (all of these things are in fact true for the originally envisioned usage) and thus irrelevant for decentralized internet. (for example, the L for "Lightweight" in "LDAP" essentially means that it uses passwords instead of client side certificates) 2) The UX in early SSL capable browsers for client-side certificates was horrible (In Netscape the whole SSL configuration was in completely separate dialog from browser settings, which was incredibly complex. IE uses SSL implementation from windows which is also used for lots of other things and has centralized configuration and also even today creates confusing dialogs when site requests client certificate). It's somewhat ironic that various ActiveX/Java based replacements of this horrible UX are in fact often even more unusable.

zeveb 9y ago
What's really sad to me is that SPKI (RFCs 2692 & 2693) addressed centralisation, complexity and cost, and was more-or-less completely ignored. If the browser and server vendors had just supported it, I really think that it could have had a chance. It was even backwards-compatible with X.509!

raesene6 9y ago

painful maintenance - most users don't want to manage certificates and crypto keys especially in a multi-device world. that's likely the main one If you don't use a hardware module certificates are easily stolen by malware and as revokation is often problematic, stolen certs can be quite bad news.