Hello,
Many EU citizens have eIDs that could be used to automatically chceck their identity. That data could be compared to the data (the owner field) of a company retrived from a gov database using an API or provided by the user as a document signed electronically by the gov.
Would it be possible to provide such automatic checks in Let's Encrypt?
Hello @mimi89999, welcome to the Let's Encrypt community. 
From here: FAQ - Let's Encrypt
Let’s Encrypt offers Domain Validation (DV) certificates. We do not offer Organization Validation (OV) or Extended Validation (EV) primarily because we cannot automate issuance for those types of certificates.
And details on how it works to assist in your understanding of Let's Encrypt process and flow.
And from Baseline Requirements Documents (SSL/TLS Server Certificates) 3.2.2 Authentication of Organization and Domain Identity of CA-Browser-Forum BR 1.8.4 has requirements that a Certificate Authority is to meet for validation.
@mimi89999, are you thinking of issuance of certificates for domain names (that would also include some verified contact information for the domain owner or operator), or certificates for some other purpose or subject entity (like an e-mail address for S/MIME, or a code signing certificate)?
I think any such idea is probably useful, but there are lots of obstacles:
Let's Encrypt is already using its engineering capacity to maintain its issuance volume for its existing DV certificate service, as well as to work through its existing roadmap, which includes other widely-requested features like ECC certificates. So there really aren't a lot of resources to spare for a big new engineering project to offer a completely new kind of certificate.
I think it would also need to be clear that there is a high demand for these certificates and that they would be useful for a large portion of the Internet, for some application where Let's Encrypt's current certificates aren't enough. Since you're one of the first people to mention this idea, it's not obvious yet how many people are looking for this or what all of the use cases are.
I think it would also need to be clear that the industry rules under which Let's Encrypt operates actually allow Let's Encrypt to issue these certificates. That's part of what @Bruce5051 was talking about. Let's Encrypt can't just issue any certificate, but has to actually convince itself that the information in the certificate is accurate and is verified in a way that's considered acceptable by the industry rules.
I'm not sure if merely presenting a digital ID credential in the course of requesting a DV-style certificate is considered strong enough binding between the ID and the subject domain name, without also providing some kind of external-world proof that the domain name is really controlled by the person who is the subject of the ID. (It might be, though! But that's an issue to check.)
Further to that, I thought that existing OV certificates were required to be issued to legal persons and not natural persons (like incorporated associations rather than individual human beings). I might be wrong about this because I haven't double-checked; I thought there was another lesser-known category of "IV" for certificates verifying the identity of individuals.
There might be a challenging problem for a certificate authority in deciding which governments were trustworthy enough for their identity assertions to be accepted as prima facie evidence for issuing a certificate (although of course this issue already exists for other kinds of CAs).
Some Europeans are very mad about people putting personal data in append-only data structures, even on an opt-in basis, because they believe people should be able to retroactively withdraw consent for other people to propagate records about them. The certificate industry and Let's Encrypt are very committed to transparency in certificate issuance, in which issued certificates become public records that are tracked independently outside of the issuer's control. This makes deletion of information about a subject entity difficult or impossible. If European data subjects are going to continue to insist that there must always be a means to delete or correct such information, it might be safer for organizations like CAs to avoid creating those public records in the first place!
Finally, an important question is whether any of the issuers of these IDs either (1) object to this kind of use, or (2) could be induced to run this kind of service themselves, or (3) issue IDs that could be used in some relevant way without the involved of a third-party CA.
I'm sorry for not having clear intuitions about some of these questions. PKI turned out to be complicated!
The FAQ clearly states that:
There were also several feature requests, but since no mechanism for automatic issuance of such certificates was ever proposed before, requests probably weren't sent.
I understand that. However, new validation methods were allowed especially for ACME, so defining such rules and getting them accepted could be possible.
Hmmm... We should check that in the Baseline Requirements and EV SSL Certificate Guidelines.
I also propose issuing certificates to legal persons. It would be a 2 step process:
It is absolutely not enough. If you recall several years ago, a security researcher named Ian Carrol obtained an EV certificate (which is considered more trustworthy) for Stripe.com by incorporating a new "stripe.com" in a different country. Nope, this isn’t the HTTPS-validated Stripe website you think it is | Ars Technica
Beyond that, while I like the idea of OV certificates - I don't see it realistically happening in an ACME setting in the forseeable future. The engineering component that @schoen is concerned about is far smaller compared to the product work that would need to be done. This is also not too far off from many of the discussions people have brought up around S/MIME Certificates. I think existing tech like PGP accomplishes the same result for current practical uses.
How would that be done without human intervention?
I think also the industry is moving away from OV/EV in general, with popular web browsers not actually showing much difference between a certificate that just has a domain name and one that has even more information. Part of that is along the lines of the "Stripe" case mentioned, where just because a user sees the name of an organization, doesn't mean that it's the organization that the user actually knows and theoretically trusts. Trademark law is complicated, and crosses jurisdictions in interesting and unintuitive ways sometimes. (Did you know that there's a McDonald's Restaurant in Illinois that isn't the fast food giant, because they were there first?) And of course, the idea of "trust" is complicated as well. Browsers are tending to just want to have the URL be the end of it, really, with security guaranteed as far as your information only going to that domain name, with any more information sometimes causing more confusion than it prevents.
I think that's a separate issue. In that case, there would be no problem with binding the entity Stripe, Inc with the domain stripe.ian.sh, because they were correctly linked; the problem was that there were two different entities named Stripe, Inc. This was a problem because people generally expect different companies to have different names, which is not expected of individuals. (Browser UIs of also contributed, since at the time some hid the domain name for sites with EV certs, so the only thing you would see was "Stripe, Inc [US]" on either site.)
This is not only expected of individuals, but it is expected more. I shared this example, because it illustrates the same exploit applies to your request – one would merely need to find a person with the same name as a contact/owner of an organization to obtain a certificate.
Or get a judge to grant them a legal name change that is same name as the target victim has.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.