Plans for Extended Validation?

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.


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.


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 :slight_smile:

hi @CoreTex

It is a great idea and there are lots of initiatives (australia has which would support this

There are also companies which offer the service you describe:


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


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.

1 Like

As I did not get any feedback on my “above” post (about 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, 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.


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 “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, 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
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 assurance interface and LE, so this should not be an (showstopping) issue.

hi @Schultz-IT-Solutions

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.


actually, the “assurance process” used by is a very well defined process, based on a number of agreed policies (starting with ). 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 (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 ) 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. :slight_smile:

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.