PKI Consortium blog

One Year Certs
July 9, 2020 by Patrick Nohe (GlobalSign) Apple CA/Browser Forum DV Google Identity Microsoft PKI Policy Root Program SHA1 SHA2 SSL/TLS
Starting on September 1st, SSL/TLS certificates cannot be issued for longer than 13 months (397 days). This change was first announced by Apple at the CA/Browser Forum Spring Face-to-Face event in Bratislava back in March.

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.

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.

Chrome Kills Mixed Content for HTTPS
December 6, 2019 by Bruce Morton (Entrust) Attack Chrome Firefox Mixed Content Policy SSL/TLS
In a phased approach, Chrome plans to block mixed content on secure websites to improve user security. Most browsers already block some mixed content such as scripts and iframes by default. Chrome is amping it up by gradually taking steps to also block images, audio recordings and videos, according to a recent Google Security blog. Preventing mixed content to load will eventually result in HTTPS websites losing their security indicator downgrading the site to HTTP, which alerts visitors that the site is not secure.

The Insecure Elephant in the Room
October 10, 2019 by Paul Walsh 2FA Android Attack Chrome DV Encryption EV Firefox Google Identity Malware Microsoft Mozilla Phishing Policy Revocation SSL/TLS Vulnerability W3C
The purpose of this article The purpose of this article is to demonstrate why I believe browser-based UI for website identity can make the web safer for everyone. I explain in great detail, the reasons why the UI and UX didn’t work in the past. And what’s left is only making the problem worse instead of better. Some people seem to find it difficult to consume my thoughts about the enforcement of “HTTPS EVERYWHERE”, free DV certs and the browser padlock.

What Are Subordinate CAs and Why Would You Want Your Own?
June 26, 2019 by Doug Beattie (GlobalSign) CA/Browser Forum Chrome Code Signing CRL ECC eIDAS Encryption EV HSM Identity Microsoft OCSP PKI Policy Revocation RSA S/MIME SSL/TLS
Digital certificate and PKI adoption has changed quite a bit in recent years. Gone are the days where certificates were only synonymous with SSL/TLS; compliance drivers like stronger authentication requirements and digital signature regulations (e.g. eIDAS) have greatly expanded the role of PKI within the enterprise. As PKI usage has expanded, conversation has moved beyond just the number and type of certificates needed and onto deeper dialogue about custom PKI deployments.

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.

CA/Browser Forum Governance Reform
May 18, 2018 by Dean Coclin Apple CA/Browser Forum Code Signing Policy S/MIME SSL/TLS
In March 2016, the CA/Browser Forum formed a working group to review potential ways to restructure the forum. The primary goal was to examine ideas so the Forum could work on other types of standards besides TLS. Ben Wilson and I chaired this group with excellent participation from a cross functional team of browser and certificate authority representatives as well as interested parties. After 2 years of efforts, the working group produced Ballot 206 which passed in April 2017.

Certificate Transparency Deadline Moved to April 2018
May 3, 2017 by Bruce Morton (Entrust) Chrome Google IETF Policy SSL/TLS
Google just announced they will not be enforcing certificate transparency (CT) logging for all new TLS certificates until April 2018. In a previous blog post, we advised that Google provided a new policy, which required new TLS certificates to be published to the CT logs in order for the domain to be trusted by Chrome. The reason for the delay was not clear, but Google needs to consider the following:

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.