PKI Consortium blog

Digital Trust Is Elusive – Are Qualified Trust Services A Solution?
May 1, 2020 by Sebastian Schulz Attack eIDAS ENISA ETSI Phishing Policy QTSP Qualified SSL/TLS Trust List TSP

A popular saying goes: “Trust takes years to build, seconds to break, and forever to repair.”

While I wouldn’t completely agree, the idea isn’t wrong. In real life trust between two parties is established over some period of time, depending on a variety of factors. Have you ever wondered why you initially trust some people more and others less, even if you’ve never met them before? There are a complicated multitude of factors that influence our thoughts: the person’s appearance, tone of voice, title or rank, etc. Trust is established over time but can be lost within a few moments.

The CA Security Council Looks Ahead to 2020 and Beyond
January 9, 2020 by Patrick Nohe (GlobalSign), Doug Beattie (GlobalSign) Apple CA/Browser Forum Chrome Edge Encryption EV Firefox Forward Secrecy GDPR Google Identity Microsoft Mozilla PKI Policy Qualified SSL 3.0 SSL/TLS TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3 Web PKI

A whirlwind of activity will cause dramatic shifts across the PKI world in the year ahead

Suffice it to say that 2019 was filled with challenges and contentiousness as Certificate Authorities and Browsers began to watch their shared visions diverge. The debate around Extended Validation continued as CAs pushed for a range of reforms and browsers pushed to strip its visual indicators. And a ballot to shorten maximum certificate validity periods exposed fault-lines at the CAB Forum.

9 Common Myths About CAs
August 1, 2019 by Tim Callan (Sectigo) CA/Browser Forum CASC Code Signing Encryption ETSI Identity Malware PKI Qualified Revocation SSL/TLS Vulnerability WebTrust

Over the years misconceptions about CAs and the SSL infrastructure have arisen. Below is a list of common myths related to SSL and CAs.

Myth #1: CAs are not regulated

Fact: CAs are subject to various checks and balances, including third-party qualified audits through WebTrust or ETSI and strict criteria set forth by leading browsers, before they are accepted in browser root stores. Similarly, the CA/Browser Forum’s Baseline Requirements and Network Security Guidelines establish global standards for certificate issuance and CA controls that will soon be included in third-party auditing standards. Browsers are free to use these requirements to exclude non-compliant CAs from the root store.

2019 – Looking Back, Moving Forward
January 3, 2019 by Bruce Morton (Entrust) Attack CA/Browser Forum Certificate Expiry Chrome Code Signing DV ECC EV Forward Secrecy Identity Mis-issued Phishing PKI Policy Qualified Revocation RSA SSL/TLS TLS 1.0 TLS 1.3 Vulnerability

Looking Back at 2018

2018 was an active year for SSL/TLS. We saw the SSL/TLS certificate validity period drop to 825-days and the mass deployment of Certificate Transparency (CT). TLS 1.3 protocol was finally completed and published; and Chrome status bar security indicators changing to remove “secure” and to concentrate on “not secure.” The CA/Browser Forum has been reformed, the London Protocol was announced and the nearly full distrust of Symantec SSL completed. Here are some details on some of the 2018 happenings in the SSL/TLS ecosystem.

The Latest on Certification Authority Authorization
March 21, 2017 by Jeremy Rowley Attack CA/Browser Forum CAA Encryption Identity OV PKI Policy Qualified

Things are certainly heating up at the CA/Browser with exciting proposals surrounding inclusion of the Wi-Fi Alliance (WFA) as a subjectAltName otherName, new validation methods, and debates over how the CAB Forum will continue operating. One of these newly passed ballots requires all CAs to check and process a domain name’s DNS Certification Authority Authorization (CAA) resource record prior to issuing a digital certificate.

Background

RFC 6844 created CAA records as a method for domain owners to specify a policy on which certificate authorities are authorized to issue certificates for the associated domain. The basic concept is that immediately prior to issuance, the certificate authority (CA) will check the CAA record and determine whether policy permits creation of the certificate. Issuance is permitted if either a CAA record does not exist for the domain or the CAA record lists a string specified by the CA as authorizing the CA to issue the certificate. Using CAA records, the domain owner is able to control policy at a more granular level, including specifying which CA can issue wildcard certificates and how to report issues. Note, that CAA record checking is an additional requirement that occurs after the CA completes the normal domain verification process required by the CA/Browser Forum’s baseline requirements under Section 3.2.2.

Always-On SSL
September 30, 2016 by Rick Andrews, Ben Wilson Encryption Firefox Google Identity Microsoft Mixed Content OpenSSL Policy Qualified SSL/TLS

There is no doubt that content owners and publishers have a duty to encourage trust and the confidence during internet usage by adopting security best practices. If a customer believes that their data and identity are safe and protected, they are more inclined to continue their online transactions. Industry best practices for website protection should be vendor-neutral, easy to implement, and globally accessible. Websites should take all the reasonable steps possible to adopt best practices in secure design and implementation, and this includes using Always-On SSL across the entire website.

CA/B Forum Istanbul 2015
November 10, 2015 by Dean Coclin Chrome eIDAS Qualified Root Program WebTrust

While some face to face meetings can be rather mundane and boring, that can’t be said about October’s CA/B Forum meeting in Istanbul, Turkey.  Guest speaker Andrea Servida from the European Commission gave an overview of the new eIDAS regulation on electronic identification and trust services. While not everyone in the room agreed with his points, all were made aware that this has now become the law in the EU and certificate authorities which plan to issue the new EU Qualified website certificates must comply with it. Unfortunately, the law appears to make it a requirement that the Certificate Authority (or Trust Service Provider-TSP as spelled out in the regulation) must be based in the EU or in a country that has an agreement with the EU. This could limit CA choices for EU website owners to only smaller CAs located in the EU, and potentially drive up certificate prices. A link to Mr. Servida’s presentation is here: https://cabforum.org/wp-content/uploads/eIDAS-Istanbul-Servida.pdf

What To Do When You Rely on Internal Names in TLS/SSL Certificates
July 18, 2014 by Wayne Thayer Attack CA/Browser Forum Firefox IANA ICANN Microsoft MITM Qualified SSL/TLS

A deadline set by the CA/Browser Forum for the use of Internal Names is quickly approaching, and many system administrators need to understand how best to adapt to this change. At the same time, hundreds of new top-level domains are being launched, which redefines what constitutes an Internal Name. In this post we’ll explain what the changes are, why they’re being made, and how you can update your systems in response to the problem.

Always-On SSL, Part II
February 5, 2014 by Ben Wilson Encryption Firefox Mixed Content Policy Qualified SSL/TLS

The SSL/TLS protocol has more to offer than just providing you with transmission encryption. Its main benefit is that it provides a way for third parties to authenticate connections to your website over the Internet. A user who can connect to your site and retrieve information via SSL/TLS will have greater assurance and trust that information came from you. The point of Always-On SSL is that once a user is able to create an authenticated connection to your point of presence via https, then he or she should not be bounced back outside of that zone of protection. When content is communicated via HTTPS, it is because you expect to provide a level of security — and your users come to expect them as well. Once you welcome a visitor, it makes no sense to have them go back outside in order to knock. This is just one of several illustrations I’d like to present where heightened protection of a visitor should be maintained, and hopefully these examples will illustrate why Always-On SSL is the preferred method for providing web visit security.

CA Day in Berlin
January 24, 2014 by Dean Coclin eIDAS ETSI EV Microsoft PKI Qualified Root Program RSA SSL/TLS TSP

“CA Day” (also known as CA Conformity Assessment) was hosted by the German company TuVIT in Berlin on January 16, 2014. In attendance were approximately 100 people from mostly European CAs. Under the European regulatory framework, CAs are included in a group referred to as “Trust Service Providers” or “TSPs.” CASC members in attendance at CA Day were Symantec, Digicert and Comodo. The dominant theme for this CA Day was the draft Regulation on Electronic identification and trust services for electronic transactions in the internal market (eIDAS) and upcoming changes in EU regulations for Qualified Certificates, which was briefed by Gerard Galler from the European Commission and discussed in greater detail by several European TSPs. eIDAS includes a proposal for EU Qualified Website certificates (i.e. SSL) using the Extended Validation certificate as a regulatory baseline. Under proposed Article 37, qualified website certificates could only be issued by EU Qualified CAs which have been audited according to ETSI (European Telecommunications Standards Institute) standards by an approved auditor. If promulgated by the European Parliament, the Commission would be empowered to give EU Qualified EV SSL certificates the “backing” of EU law.