[Servercert-wg] Displaying secure sites to Internet users

Sun Nov 17 16:13:49 MST 2019

Then provide alternative solutions. What’s then reliable? Are you also promoting to revoke all passports and ID cards, as there are also mistakes been done on verifying their data? I know many occurrences of inconsistencies there as well, however, passports, company registers etc. still exist and bank accounts, identity services beside PKI all rely on them. Just CA shouldn’t? My name isn’t Christian Heutger, my given name on birth is Joerg Christian Heutger, as recent passports didn’t show, my driver license is just on Christian Heutger, do I need to cut it now or is it better than nothing. We could still just rely on, that I’m a human, as that’s the lowest value, which isn’t deny-able.

Am 17.11.2019 um 22:18 schrieb Burton <burton at typewritten.net>:

The problem is the vetting methods used by CAs to vet an individual or company for a certificate. CAs don't really understand vetting properly enough to be trusted to do it properly. I have found lots of vetting inconsistencies between CAs (from personal experience). I've had conversations with people from Companies House and they have told me of the inconsistencies of director's names, DOB, address, etc and that is because Companies House does minimum checks on the data. If Companies House were to conduct a verification check of the data on the company register it would take an office the size of half of wales to do that.

First, work on the vetting problems and then move on otherwise there isn't any point in trying again.

Thank you

Burton

On Sun, Nov 17, 2019 at 8:38 PM Christian Heutger <ch at psw.net<mailto:ch at psw.net>> wrote:

  *   While I'm quite familiar with ISO 27001, I don't think this dichotomy exists like you suggest. SSL/TLS already provide robust authentication of a domain name, which is how SSL/TLS is used on the Internet, and what the CA/Browser Forum concerns itself with. This robust authentication, when done following the Baseline Requirements and browser root programs, helps ensure users can reliably connect to secure sites on the Internet.

And that’s the main problem. The users expect (as it‘s common to expect if looking at similar techniques like TIA (in Germany TUEV) seals on cars, passport control on immigration etc.), that they are connected to the “correct” site and want to be able to verify, they are. Domain validation is somehow the absolute minimum method possible for having the encrypted connection established without errors using certificates, but it’s not worth the word of validation, as everyone can register a domain without any (strong) restrictions or control. For sure, where are limitations of NIC TOC, but that’s about technical or audience targeting reasons (amount of characters, .eu only for EU citizens, etc.) than authenticity reasons. My problem statement is about real identity validation, real authentication expected from trusted third parties. And for sure, TIA seals sometimes fail, immigration checks sometimes fail, some border control work better, some more weak, but that did not result in shutting down all immigration controls, because of issues arising.

  *   All of these things seem well-within our chartered scope. Discussions of UI, of course, are completely outside the scope of our charter, and well outside the expertise of members of this Forum. After all, we've seen folks acknowledge that it requires product and UI expertise, and that's inherently per-product. Just as we wouldn't expect Windows and macOS to look identical, given how much their product experiences differ, it's completely unrealistic to discuss trying to normalize UI.

Why not, we have all the players on the boat. The CA with the contact to the certificate providers (I name this one the audience of server administrators, who run the certs on their servers) with experience in their environment, how to setup certs, how to maintain certs, but also how they are used, how their customers expect them to be etc., it’s a good way to gain end user feedback, as they are their users, I’m quite unsure, how else the ones, you built your browsers, operating systems, etc. for could be asked better (than by studies, which may always run in trouble of how independent they really are), all major browser, operating system etc. responsible with their UI teams in the back, some interested parties, which are, as their name says, interested parties in this ecosystem etc. How can I drive a car in another country or cross the roads without been injured? Because there are common rules and signs. However, they differ a bit based on countries need, so also the products differ a bit on the environment, however, all browsers have URL bars, all browsers have navigation buttons, all browsers have common design elements, because users know and expect them that way and they are well established. Anyone tried to do something completely new. And all of the CA/B Forum members have a positive effect of the outcome, happy users, feeling more safe performing transactions on the internet, place data online and trust the browser and products they use, which they work all together on from different perspectives, by providing authentification services, by providing certs, by providing applications to get use of.

  *   Once we have reliable data in certificates, which we're clearly years away from having in the existing ecosystem, then it might be useful to figure out how to take advantage of that data in a way that helps users and reduces phishing. This is likely best accomplished by moving this data out of the SSL/TLS handshake, so that it better aligns with the Web security model, doesn't harm the security (encryption or authentication) of HTTPS, and helps explore how best to solve the problem(s) you seem to be concerned about. But that's a few years away, and requires us first solve the validation issues.

Why reinvent the wheel instead of planning a better basement to settle up on (if the current one is not working as expected), get the wheel running (again, as we maid the system worse from where it started of) and improve the system on incidents and non-compliance arising?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191117/8fb151b7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3860 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191117/8fb151b7/attachment.bin>