[Servercert-wg] Displaying secure sites to Internet users

Sun Nov 17 17:11:22 MST 2019

Looks like a good process. Some parts could be improved for better automation, but looks great.

Am 18.11.2019 um 00:33 schrieb Burton <burton at typewritten.net>:

The correct way to vet a UK company would be to:
1. The CA checks Companies House to check if the company is incorporated.
2. The CA sends a letter with verification code to the company address listed on Companies House.
3. The CA requests the company to send them a bank statement / tax bill to prove operation.

Possible to get any access here? Unsure on VAT ID e.g. in Europe to be able to used therefore.

4. Once the company has sent the information provided in (3) and is it confirmed by CA then (5) otherwise (3).
5. Once the company receives the letter with verification code then (6) otherwise vetting on hold until company receives letter with verification code.
6. The CA initiates video call with the director who is listed at Companies House and then the CA does the following:
a) The CA asks the director to hold up his/her passport to the side of their face to confirm that the face matches the passport photo and then the CA confirms the details such as full name and DOB matches the information printed on the passport.
(optionally: For high profile companies the CA could also ask for the passport to be countersigned and put the video call on hold while they confirm the countersignature with the individual.)
(optionally: For high profile companies the CA could also ask for the incorporation certificate to be countersigned and put the video call on hold while they confirm the countersignature with the individual.)

Maybe allow electronical identification function in passports therefor as alternative, e.g. eID in Germany. How about people, who are stated to be allowed to sign as well (unsure on UK, in Germany Prokura, maybe Secretary in UK?), I won’t believe, the director of BBC will perform a video call for verification.

b) The CA asks the director to hold up the verification letter in front of the camera to confirm company address.

Could be asked to enter a random generated code on the letter to a system like Google validates businesses.

c) The CA calls the company number listed on 3rd party register (automated phone call like the Google verification phone call) and the director tells that verification code to the CA to confirm the phone number belongs to the company.
d) Signs the agreement.

Electronical as well? Or may be latest with a qualified digital signature?

7. That's it.

This method confirms that:
a) The company is in active operation at the address listed on Companies House.
b) The company phone number is in active operation at the company.
c) The director of the company has been vetted and confirmed certificate request by signing the agreement.

Thank you

Burton

On Sun, Nov 17, 2019 at 11:14 PM Christian Heutger <ch at psw.net<mailto:ch at psw.net>> wrote:
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<mailto: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/20191118/f869a2ac/attachment-0001.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/20191118/f869a2ac/attachment-0001.bin>