By Jeremy Rowley and Tim Hollebeek

The Certificate Authority/Browser (CA/Browser) community discussions on the value of Extended Validation (EV) certificates, the future of EV, and proposed improvements to EV revealed that DigiCert has a slightly different view on EV than other participants.

Sharing our view on EV issuance may help others understand the stances DigiCert takes with respect to EV certificate issuance and the future of EV. Some of these stances are not currently supported in the EV requirements and are features specific to DigiCert.

Some History

Some history is required to understand DigiCert’s view on EV certificates. First, the CA/Browser created EV certificates at the request of a certain browser and the financial community to distinguish legitimate financial and enterprise sites from phishing attacks. The creators of EV hoped that providing identity information about the site operator would help users detect phishing and protect financial companies from reputational harm if their customers were defrauded. EV certificates became widely available in 2007. Since then, Certificate Authorities (CAs) have verified entities and issued EV certificates with few updates to the standards defining what EV means.

Goals of EV

The goals of EV are captured in section 2.1.1 and 2.1.2 of the EV Guidelines, which states that the objectives of EV certificates are to:

“[1] Identify the legal entity that controls a Web site: Provide a reasonable assurance to the user of an Internet browser that the Web site the user is accessing is controlled by a specific legal entity identified in the EV Certificate by name, address of Place of Business, Jurisdiction of Incorporation or Registration and Registration Number or other disambiguating information; and

[2] Enable encrypted communications with a Web site: Facilitate the exchange of encryption keys in order to enable the encrypted communication of information over the Internet between the user of an Internet browser and a Web site.

[3] Establish the legitimacy of a business claiming to operate a Web site or distribute executable code, and to provide a vehicle that can be used to assist in addressing problems related to phishing, malware, and other forms of online identity fraud.

[4] Make it more difficult to mount phishing and other online identity fraud attacks using Certificates;

[5] Assist companies that may be the target of phishing attacks or online identity fraud by providing them with a tool to better identify themselves to users; and

[6] Assist law enforcement organizations in their investigations of phishing and other online identity fraud, including where appropriate, contacting, investigating, or taking legal action against the Subject.”

At DigiCert, we ignored the individual goals, choosing to incorporate this section as a single value we follow in developing product and issuing EV certificates. That value is brand protection. Although brand protection includes identification, the scope covered is broader.

Branding and Brand Protection

Proper branding and brand protection serves a critical purpose in communicating attributes to consumers and preserving a business’ reputation. People only recognize amazon.com as Amazon because of the branding associated with Amazon. Prior to establishing the brand, Amazon was a geographical region in South America. Because brand represents a company’s culture, reputation, and values, companies spend millions of dollars on its protections. EV Certs are PKI’s foray into the field of trademark recognition and trademark protection.

When a customer orders an EV certificate at DigiCert, the certificate request is automatically checked against a table of previously issued EV certificates. If an EV certificate for an organization already exists in another account, the certificate request is flagged and does not issue until the applicant undergoes a name resolution process. Normally, this process involves contacting the other EV certificate holder to confirm authorization. If the existing account holder does not confirm authorization, the certificate request escalates to a dispute resolution process.

Need a Better-Defined Process

This process is not well-defined—as the first significant conflict occurred weeks ago when security researchers attempted to issue certificates for Stripe, Inc. (https://stripe.ian.sh/) and Cloudflare. Note that the security researchers legitimately could obtain an EV certificate for these two well-known names under the current EV guidelines. Both researchers properly registered the name, were in good standing with the government agency, and had a verifiable telephone and address. In both cases, the researchers created real, existing businesses, and, if either researcher sold widgets rather than blogs about digital certificates, no Certificate Authority (CA) would have questioned their corporate status. Even with high-risk checks and the well-known names of Stripe and Cloudflare, a non-US CA could have issued the cert, easily unaware of what the names represent.

Despite the fact the EV guidelines permitted issuance, DigiCert rejected the certificate request. Why? Because both Stripe and Cloudflare are existing DigiCert customers and hold valid EV credentials. Although both researchers passed the validation requirements, neither received permission from existing Stripe or Cloudflare account holders to issue the certificates. We didn’t escalate the EV request through the dispute resolution process. Since, the researchers were not affiliated with the appropriate trademark, their EV certificate requests were denied. This brand protection benefit exists for all EV customers, regardless of name of the company, address, and other aspects of the certificate holder’s identity.

Process Improvements

This explanation is not intended to preach DigiCert’s practices and policies. Indeed, the approach we take needs revision and improvement. Some of the issues are obvious. For example, the first entity to order an EV certificate can effectively lock down a name, creating domain squatting issues. Also, brand protection is limited to DigiCert, as companies and phishing groups or unauthorized parties can order a similar EV certificate from a competitor. There are other issues, of course, but we are actively working to address both of these concerns through internal policy and ideas promoted at the CA/Browser Forum and Internet Engineering Task Force (IETF).

EV Squatting—Resolve Disputes as They Arise

The first issue is EV squatting. One solution is to mirror the Internet Corporation for Assigned Names and Numbers (ICANN) process and resolve disputes as they arise. Our dispute system is premised on the belief that most phishing sites tend to disappear quickly after discovery and that the rightful name holder is usually obvious upon review of an order. As mentioned, the chances to test and refine the resolution process are non-existent to date. Additionally, duplicate names for EV certificates are rare.

Brand Protection—Improve CAA

We are trying to work with others to solve the second issue (brand protection) through improvements to the Certificate Authority Authorization (CAA) resource record checking process. CAA was introduced as RFC 6844 and is a DNS record that reports certificate issuance policy to a CA. Our hope is CAA becomes a standard way to specify all types of CA policy, including which accounts are authorized to issue certificates, the type of certificate permitted, and the validation methods permitted. This would extend CAA from the limited scope of specifying which CA can issue certificates to more granular controls. RFC 6844 already permits user-defined tags in CAA records, meaning DigiCert could implement these policies unilaterally. However, we felt standardizing the tag values would benefit all CAs and broaden both the use and control of CAA attributes.

The downside of CAA (and one of the reasons we opposed CAA historically) is the lack of compliance evidence. Bad-acting CAs can issue whatever certificates desired ignoring CAA records, claiming their CAA record check process timed out without a response. Because CAA is a point-in-time check without clear requirements around document retention, there is no way for the public to confirm CAA specified policies were followed. Because of this, we believe that, at the very least, all CAs must keep and disclose CAA record check information as is sufficient to demonstrate the results of their CAA checks.

Certificate Transparency

This lack of transparency in CAA and the belief that EV equates to brand protection is also one reason DigiCert is a staunch supporter of Certificate Transparency (CT). With CT, all companies can monitor the certificates issued using their company name or domain names. Companies can search CT logs to reveal phishing sites and discover when their issuance policies were ignored. CT is a powerful tool that provides a complete picture about CA issuance, giving companies and browsers the information required to mitigate brand attacks.

Make Real EV Guideline Improvements

Although DigiCert utilizes EV to provide brand protection to customers, critics correctly point out that users do not understand the difference between Stripe, a Delaware company, and Stripe, the Kentucky organization. The lack of distinction does harm brand protection, and CAs and the security community should work together to improve the EV guidelines and processes.

As mentioned earlier in the blog, EV was released in 2007. 11 years is a long time for a standard to remain static. DigiCert supports making real improvements to the industry, including revisions to the EV Guidelines in collaboration with the rest of the security community. Specifically, we would like to discuss and adopt ideas where CAs can add additional value using the skills and information collected in issuing certificates. With ideas like Legal Entity Identifier (LEI) and onFido, we are confident we can constructively find solutions that provide technical enhancements to the brand protection EV should provide.

Encryption, Trademark Protection, & Brand Recognition

By design, EV certificates are focused on identity and brand rather than just encrypting traffic. Because EV is not focused solely on encryption, some improvement efforts have tried to unnecessarily make EV more difficult to obtain. To make EV more meaningful, improvements need to focus on both enhancements to security and how organizations, regardless of when incorporated, can utilize EV for better trademark protection and recognition. Newer companies deserve the same right to EV certificates as established business entities. Excluding smaller or non-profit entities creates an uneven playing field and limits a new entrant’s ability to preserve their brand and reputation.

DigiCert Wants to Help Improve the Process

DigiCert plans on proposing some of the following ideas as improvements to EV. Many of these ideas could apply to the whole ecosystem if required for OV and DV certificates as well. However, improving the EV certificate guidelines  provides a great opportunity to implement new values and improve online security without interrupting encrypted communication. If there is interest from the community, we would like to spec out a few of the following ideas and create a ballot for them.

1. Require EV certificates to specify the method of domain validation used as information in the certificate.
2. Require CAs to verify a registered trademark before issuing an EV certificate.
3. Include trademark and brand information in a certificate.
4. Provide a face-to-face verification with the certificate requester.
5. Only issue EV certificates if certain security parameters (e.g., proper Transport Layer Security (TLS) version) are met.
6. Require a valid CAA record prior to issuance.
7. Require that the CA check the certificate type in the CAA record or respect a CAA policy regarding validation processes prior to issuing.
8. Require CAs to log the identity with an identity blockchain.
9. Include LEIs in certificates.

This list includes only some initial thoughts, and we gladly welcome additional ideas and feedback. Once we create a defined list of potential EV guideline improvements, we will happily run a Proof of Concept (PoC) to evaluate how the ideas impact security.

Feedback Welcomed

We’re happy to engage on the CAB Forum, Mozilla forum, Twitter, and other forums with parties interested in improving EV. Feel free to reach out to us at any time.