Hi @ahaw021,
the point is that every bank is forced by law to do a human validation of these and even more information to validate the Identity. So from that point you can rely on the information you are able to fetch via API without having self the human process in place.
Eric
hi @CoreTex
But you still have the issue of having to do with banks world wide to get the right validation
For example an australian business may deal with one of 10 banks. An american business would deal with one of 30.
Banks also like to charge for every service so once again this negates the point of a free ca.
As well as that lets not forget the fun beast that is bank privacy laws.
Andrei
Hi @ahaw021,
there are so many banking apps in place supporting 90% of the banks worldwide. I just have to enter IBAN, BIC, username and password, and oho I can see every detail of my bank account, including company name, Firstname, Lastname and so on. Why I canât enter easily my banking username/password credentials in the certbot ?
Just an idea 
hi @CoreTex
It is a great idea and there are lots of initiatives (australia has http://www.bpay.com.au/) which would support this
There are also companies which offer the service you describe:
http://www.globalbusinessregister.com/
However
A) You still need to be part of the BPAY network
B) BPAY is really designed to move money not for a validation service
C) PCI-DSS compliant infrastructure would have to be built
D) You would have to find a way to automatically submit your bank details. Usually this is done via a SSO token in a web browser which removes some of the automation flexibility
E) I havenât read the base guidelines for whats required
F) How do you deal with the fact that a company is not found
I think you are on to a winner but unfortunately the data and automation needed isnât quite as cheap as it needs to be
Andrei
Iâm happy to raise this suggestion in future Letâs Encrypt meetings to see what people think about its feasibility, but Iâm not that optimistic that it can be rolled out easily by Letâs Encrypt with a large benefit to a wide audience.
As I did not get any feedback on my âaboveâ post (about CAcert.org infrastructure for EV), Iâd like to âthrow my hat into the ringâ once moreâŚ
They have a fully implemented process for EV, and trusted parties around the globe to do this.
If LE could find a way to cooperate with CAcert.org, this might be beneficial for all interested parties.
Any thoughts on this?
good idea in concept however lots of red flags for me
if you compare the issuance stats of CACert to Letâs Encrypt and number of Assurers vs number of certificates the number of volunteers needed would be huge (just managing the assurers would be a full time job (going back to the whole point of ACME being an automated protocol)
Their root cert also doesnât appear to be in the Mozilla Cert Bundle so would involve installing it on the servers. And from what I read their root must be used (rather than the Letâs Encrypt roots)
I like the idea of of consensus and blockchains could provide a mechanism to do this in a more automated way (e.g. trusted approvers) can review and vote
However as this is not part of the ACME protocol in general the first hurdle would be to come up with a standard to do this that works. The second challenge would be to convince the CA Forum that this sort of review is equivalent to dedicated trained reviewers. The third challenge would be to code it and implement it.
Andrei
I agree this would not be an âout of the boxâ solution to the requirement, but I belief combining the two approaches would be a possible course of action. Let me elaborate:
The CAcert.org âweb of trustâ is based on âhuman beings validating each others identityâ. As your screenshot shows, there is some 350.000 legally verified users (that means: another user, who has previously been verified by yet multiple other verified users, has (in a âperson-to-person physical meetingâ) reviewed the persons legal documents - like passport, ID card, driving licence - and considered them âbeing consistent with the person presenting themâ.
You are right, currently there are âonlyâ about 18.000 people (worldwide) who can actually do this validation. But putting the two projects together, we might indeed have a exponential jump in numbers of âvalidated usersâ. The assurers in CAcert web-of-trust do work voluntarly, so there is no cost involved for âsaleriesâ here.
As you might have figured, I am indeed such an âassurerâ for CAcert.org, and there is a substantial number of others for example here in Vienna, Austria. And I even went through the process to receive an extended validation for my own domains with CAcert.org
So I would be quite happy to act as an âliaison officerâ between the two projects, if this is considered a possibility by LE.
And with âverified assurersâ around the globe, it should eventually be a doable task to establish a network of trusted people to validate the EV requirements.
From an technical point of view, an API could be implemented between the CAcert.org assurance interface and LE, so this should not be an (showstopping) issue.
I am not a member or IETF so can't really comment on the feasibility etc. From a standards and documentation point of view.
As ACME currently stands
This document describes an extensible framework for automating the
issuance and domain validation procedure, thereby allowing servers
and infrastructural software to obtain certificates without user
> interaction.
CA Browser Forum on EV:
Have a read of the requirements around confirmations etc.
I don't think a network of people who "trust each other" is enough to pass the required test from CA Browser
For example how does CACert comply with this requirement:
Confirmation Response: The CA MUST receive a response to the Confirmation Request from a Confirming Person
that confirms the particular fact at issue. Such response MAY be provided to the CA by telephone, by e-mail, or by
paper mail, so long as the CA can reliably verify that it was provided by a Confirming Person in response to the
Confirmation Request.
So it's not technical hurdles it's write a protocol that meets requirements of CAB Forums so people know it's accurate and trustworthy. I believe ACME does comply with all requirements for proof for a Domain Validated Certificate which is why it works as a protocol.
Andrei
actually, the âassurance processâ used by CAcert.org is a very well defined process, based on a number of agreed policies (starting with https://www.cacert.org/policy/AssurancePolicy.html ). The assurer is indeed legally liable for the quality of the individual assurance process. And of course there is a written form (piece of paper), signed by both participants in the assurance process. This physical document is kept by the assurer, but itâs data is entered into the CAcert.org (online) database.
But before diving really deep into this matter, maybe some member of IETF could actually comment on the feasibility?
Who could that person be?
N.B. the main reason why still today the root certificate is not yet included in the Mozilla cert-bundle (see http://wiki.cacert.org/InclusionStatus ) is the requirement to have an âexternal auditâ been taken. This, as far as I understand, is a financial burden the organisation could not handle so far.
The IETF doesn't have formal membership, and would in any case be completely the wrong body to talk to about this. You want to change Trust Store policy, that realistically means you need to change the minds of Trust Store owners. I suggest you begin with someone like Jody Cloutier at Microsoft. If you can't get the Trust Store owners to allow this, it doesn't matter how "technically possible" you're sure it is, it's useless.
You could also ask Gervase Markham from Mozilla and Ryan Sleevi from Google about their views from the point of view of their respective trust stores. They donât make all of these decisions themselves, but they represent their employers for some purposes and have strong opinions about what is best for relying partiesâ security.
I havenât reviewed this area carefully, but I agree that potentially an amendment to the CA/B Forum EV guidelines would be needed to make them match up with the practices of an entity like CACert or a more automated equivalent. Letâs Encrypt has no plans to pursue this, but other people are obviously welcome to look into it.
sorry, just to be clear here: CAcert is not depending on âpeople who trust each otherâ, but rather on âlegally bound community members having vetted each others identity through authoritve governmental documents providedâ.
I contacted both Gervase and Ryan as you suggested. When I get responses, will get back here âŚ
After a more detailed analysis of the CABForum âguidelinesâ regarding extended validation, I now belief (after consulting with Gervase Markham from Mozilla), that one would need to develop a âfull proposalâ to the CAForum, in order to ammend the guidelines (they are restricted, among other entities to âemployees of the CAâ to carry out the validation process. This is not a viable solution for a community-driven entity like LE) .
I do have ideas for such an proposal and am willing to contribute to the discussion and development of it, but I think it should be initiated by LetsEncrypt officials. Otherwise it might be wasted resources (if LE not really wants to walk that road).
any suggestions?
kind regards
Ruediger Schultz
How about offering EV to entities that already have one from a different authority and thus they do not require to have to go through the entire process all over again?
Iâm pretty sure the EV rules require each certificate authority to perform its own independent investigation. I have never heard of a CA considering another CAâs actions as prima facie proof of the correctness of a certificateâs contents.
I agree with schoen, LE cannot rely on other CAâs processes.
And as âwildcard certificatesâ (which was a feature request from the very start of LE) will be available from january onwards, I all the more think that a valid discussion of âextended validationâ would be well timed nowâŚ
As I said before I belief the next step to implement EV within LetsEncrypt would be to develop a process (proposal) towards the Browser Forum (in order to adapt the Browser Forumâs âextended validation rulesâ. I know this sounds (and actually IS) a complex task, with a lot of discussion.
But all of this would depend on a more formal commitment of LE to actually âwant EV as a feature to LetsEncryptâ.
Only then one could start to setup any kind of RFC infrastructureâŚ
I would still suggest to
if you care a lot about this. (You can also ask the other browser representatives, but Gervase and Ryan tend to be especially active and outspoken about their opinions, in a way that other browser representatives usually aren't.)
I can tell you that nobody from Let's Encrypt is interested in actively pursuing this right now at the CA/B Forum, but that's doesn't necessarily mean that Let's Encrypt would never implement this if the Forum were willing to accept it and prescribe a path. To me, something that might be more valuable is if DNS registries and registrars (which are often considered the source of ground truth for the web PKI) took a more active role in validation processes in general. I don't know whether the results would be called "stronger DV" or some other category of validation (maybe "RRV")?
I did indeed contact both of them in july and Gerv responded.
However he feels that the CA/B Forum will not change the EV rules upfront, so the first step (from his point of view) would actually be the CA developing the respective processes. If (as you say) ânobody from Letâs Encrypt is interested in actively pursuing thisâ upfront, but may wait for the CA/B Forum to act first, then the whole issue is stuck in a kind of âinfinite loopâ !
I do understand that there is work included in this issue, and all of us do have a lot of other things to take care of. However this situation is a bit disappointing to meâŚ
That is definitely frustrating, but we donât feel that the benefits are large enough to prioritize this activity, so you may need to work with some other organization to make progress on it.
