PKI Consortium blog

2018 – Looking Back, Moving Forward
January 6, 2018 by Bruce Morton (Entrust) Attack CA/Browser Forum CAA Certificate Expiry Chrome ECC Encryption Google Microsoft Mis-issued OV PDF PKI ROCA RSA SSL/TLS TLS 1.3 Vulnerability
Looking Back at 2017 2017 saw the end of SHA-1 in public trust SSL/TLS certificates and the start of Certification Authority Authorization (CAA) allowing domain owners to authorize their CA. A “Not secure” browser indication was propagated to push more websites to support HTTPS. There was also a change in the certification authority (CA) ownership with DigiCert acquiring Symantec’s SSL and related PKI business and Francisco Partners buying Comodo’s CA.

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.

2017 – Looking Back, Moving Forward
January 13, 2017 by Bruce Morton (Entrust) 3DES Apple Attack CA/Browser Forum CAA Chrome Code Signing Encryption Firefox Google Identity Malware MITM Policy Revocation RSA SSL 3.0 SSL/TLS TLS 1.3 TSA Vulnerability
Looking Back at 2016 Fortunately, 2016 was not a year full of SSL/TLS vulnerabilities. Although some researchers did prove old cryptography algorithms should be put out to pasture. The year showed the end of public-trusted SHA-1 SSL/TLS certificates. It also showed more transparency should be considered due to issues discovered with a few certification authorities (CAs). The great news is HTTPS is no longer the minority — after 20 years, connections using HTTPS has surpassed HTTP.

Google Certificate Transparency (CT) to Expand to All Certificates Types
November 8, 2016 by Jeremy Rowley Announcement CA/Browser Forum Chrome DV EV Google IETF OV Policy SSL/TLS
The policy change goes into effect October 2017 A recent Google announcement stated that all publicly trusted SSL/TLS certificates issued in October 2017 or later will be expected to comply with Chrome’s Certificate Transparency (CT) policy or be untrusted by the browser. Since January 2015, Chrome has required Extended Validation (EV) certificates to comply with CT. With this policy change, the Chrome CT policy will also apply to Domain Validated (DV) and Organization Validated (OV) certificates.

Why Is Certificate Expiration Necessary?
October 19, 2016 by Bruce Morton (Entrust) Attack CA/Browser Forum EV Hash Function Identity OCSP Policy RSA SSL/TLS Vulnerability
The Long Life Certificate – Why It Doesn’t Exist Why is certificate expiration even necessary? Wouldn’t it be better if I could just buy a certificate with a long life before expiration? It would really simplify certificate management if it could be installed and forgotten. Simple, no management required, just file-and-forget. Imagine, I’ve been in business, starting say 10 to 15 years ago. I roll out my web pages and secure them with a 20-year-validity SSL certificate.

Minimum Requirements for Code Signing Certificates
July 20, 2016 by Bruce Morton (Entrust) CA/Browser Forum CASC Code Signing FIPS HSM Malware Microsoft Revocation TSA
It is time for an update on the Baseline Requirements for Code Signing. First the bad news, the new standard was not approved by the CA/Browser Forum due to philosophical differences among some forum members who felt code signing was not in scope with the Forum’s charter. The good news is the document was created in a multi-stakeholder environment and substantially improves the current management processes. As such, it was decided to bring the document outside of the forum and finalize it as part of the CA Security Council.

TLS Certificates on the Web – The Good, The Bad and The Ugly
May 17, 2016 by Rick Andrews CA/Browser Forum Code Signing ECC Encryption EV Hash Function PKI Policy RSA SSL/TLS
It might be hard to believe, but the SSL/TLS Ecosystem is nearly 20 years old. It’s time to take stock and see how we’re doing with regards to TLS certificates. In this article, we’ll primarily discuss certificates themselves and not web server configuration, although that is often a source of problems. In the last few years, we’ve endured three major certificate-based migrations: Away from the MD2 and MD5 hash algorithms to SHA-1 Away from small RSA keys to 2048-bit keys or larger Away from the SHA-1 hash algorithm to SHA-256 What’s driving these migrations?

2016 – Looking Back, Moving Forward
December 14, 2015 by Bruce Morton (Entrust) Attack CA/Browser Forum CAA Chrome Code Signing DH Encryption Firefox Google Hash Function IETF Microsoft MITM OpenSSL Policy RC4 Revocation RSA SSL/TLS TLS 1.2 TLS 1.3 Vulnerability
Looking Back at 2015 A number of new tactics proved 2015 was no exception to an active year defending against ever increasing security issues. Vendors found new and creative ways to provide vulnerabilities including the now popular man-in-the-middle (MitM) attacks. MitM as well as a host of other new vulnerabilities caused browsers to rethink their security requirements. This article gives a flashback of the exploits and industry changes from 2015 and looks ahead at the latest security requirements and how it impacts IT security teams.

Code Signing Baseline Requirements
November 30, 2015 by CA Security Council CA/Browser Forum CASC Code Signing Identity Malware
You may have heard that the CA/Browser Forum is getting ready to approve Baseline Requirements for Code Signing certificates. But why is this important? Let’s back up and get some background on code signing. Software code that is digitally signed indicates to the user that the code has not been tampered with since it was signed. It also provides authenticity as to who signed it and when. With the advent of malware, it’s important to insure that the code which was written by the developer is the same code which you downloaded and installed into your computer or mobile phone.

SSL Certificate Validity Periods Limited to 39 Months Starting in April
February 19, 2015 by Jeremy Rowley CA/Browser Forum ETSI Policy SSL/TLS Vulnerability WebTrust
In accordance with the CA/Browser Forum Baseline Requirements, effective April 1, 2015, Certificate Authorities (CAs) will no longer be able to issue SSL Certificates with a validity period longer than 39 months. Shortening the validity period to 39 months is the result of much consideration within the CA/Browser Forum to arrive at a duration that allows optimal usability while maintaining the tightest network security. A shortened validity period will significantly improve Internet security by requiring administrators to renew and verify their certificates more often.