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. 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.

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.

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. A large part of the conversation is around subordinate CAs, sometimes referred to as Issuing or Intermediate CAs, and why an organization might want their own. Let’s discuss.

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.

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. This created new bylaws which will go into effect on July 3, 2018.

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:

• Overall CT policy discussions with the major stakeholders are underway, but we are still far away from a conclusion.
• Other browsers appear to be supporting CT, but have yet to determine their policies or advance their browser code.
• The CT deployment document, RFC 6962-bis, tracked by IETF standards has not been released.
• The proposed document for CT Domain Label Redaction that addresses privacy has started, but has not been adopted or completed by the IETF.
• Sufficient, scalable, and reliable CT logs have not been deployed by the ecosystem to address the increase in requirements.

Certification authorities (CAs) as well as TLS certificate subscribers will welcome the extra time to help ensure that deployment of CT logging is efficient and seamless.

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.