PKI Consortium blog

CA Security Council (CASC) 2019 Predictions: The Good, the Bad, and the Ugly
December 6, 2018 by Bruce Morton (Entrust), Chris Bailey (Entrust), Jay Schiavo (Entrust) Apple Attack CASC Chrome DV Encryption EV Firefox Google Identity IETF Malware Microsoft Phishing SSL/TLS TLS 1.0 TLS 1.2 TLS 1.3
As the legendary coach of the NY Yankees Yogi Berra allegedly said, “It’s difficult to make predictions, especially about the future.” But we’re going to try. Here are the CA Security Council (CASC) 2019 Predictions: The Good, the Bad, and the Ugly. The Good Prediction: By the end of 2019, over 90% of the world’s http traffic will be secured over SSL/TLS Encryption boosts user security and privacy, and the combined efforts of browsers and Certification Authorities (CAs) over the past few years have moved us rapidly to a world approaching 100% encryption.

CASC Announces Launch of London Protocol to Improve Identity Assurance and Minimize Phishing on Identity Websites
June 27, 2018 by CA Security Council Attack CA/Browser Forum CASC DV EV Identity OV Phishing SSL/TLS
LONDON – (June 27, 2018) – The Certificate Authority Security Council (CASC), an advocacy group committed to the advancement of the security of websites and online transactions, announced at the CA/Browser Forum event in London the launch of the London Protocol – an initiative to improve identity assurance and minimize the possibility of phishing activity on websites encrypted with organization validated (OV) and extended validation (EV) certificates, which contain organization identity information (Identity Certificates).

The London Protocol
June 27, 2018 by CA Security Council DV EV Identity OV Phishing
The objective of The London Protocol is to improve identity assurance and minimize the possibility of phishing activity on websites encrypted by OV (organization validated) and EV (extended validation) certificates (together referred to as “Identity Websites”). The London Protocol reinforces the distinction between Identity Websites making them even more secure for users than websites encrypted by DV (domain validated) certificates. That security feature can then be utilized by others for their own security purposes, including informing users as to the type of website they are visiting and use by antiphishing engines and browser filters in their security algorithms.

Fortify Allows Users to Generate X.509 Certificates in Their Browser
June 19, 2018 by Tim Hollebeek Chrome Code Signing Encryption Firefox Google HSM Microsoft Mozilla S/MIME W3C
Fortify, an open source application sponsored by Certificate Authorities through the CA Security Council, is now available for Windows and Mac. The Fortify app, which is free for all users, connects a user’s web browsers to smart cards, security tokens, and certificates on a user’s local machine. This can allow users to generate X.509 certificates in their browser, replacing the need for the deprecated <keygen> functionality. Certificate Generation In The Browser The Web Cryptography API, also known as Web Crypto, provides a set of cryptographic capabilities for web browsers through a set of JavaScript APIs.

Fortify Provides a More Secure Web Experience for Certificates and Smart Cards
June 19, 2018 by CA Security Council CASC Code Signing S/MIME SSL/TLS
San Francisco – June 19, 2018 – The Certificate Authority Security Council (CASC), an advocacy group committed to the advancement of web security, today announced that Fortify, an open source application sponsored by the Council, is now available for Windows and Mac. Fortify, a free app, connects a user’s web browsers to smart cards, security tokens, and certificates on a user’s local machine. This allows users to generate X.509 certificates in their browser, replacing the loss of key generation functionality.

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.

TLS 1.3 Includes Improvements to Security and Performance
April 10, 2018 by Tim Shirley Forward Secrecy IETF SSL/TLS TLS 1.2 TLS 1.3 Vulnerability
Last month saw the final adoption, after 4 years of work, of TLS version 1.3 by the Internet Engineering Task Force (IETF). This latest iteration of the protocol for secure communications on the internet boasts several noteworthy improvements to both security and performance: Security All cipher suites that do not provide forward secrecy have been eliminated from TLS 1.3. This is a very important security property, because without forward secrecy, if a server’s private key is compromised today, any previously-recorded conversations with that server dating back as long as the key was in use could be decrypted.

Chrome Will Show Not Secure for all HTTP Sites Starting July 2018
February 15, 2018 by Bruce Morton (Entrust) Android Chrome Google HSTS Phishing SSL/TLS Vulnerability
Through 2017 and into 2018, we have seen the use of HTTPS grow substantially. Last Fall Google announced the following status: Over 68% of Chrome traffic on both Android and Windows is now protected Over 78% of Chrome traffic on both Chrome OS and Mac is now protected 81 of the top 100 sites on the web use HTTPS by default Google helped to drive this growth by implementing the “Secure” and “Not secure” status in Chrome’s status bar.

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.

How Does the ROCA Attack Work?
November 9, 2017 by Tim Hollebeek Attack PKI ROCA RSA Web PKI
On October 17th, a group of Czech researchers announced they had found a way to factor the moduli of many RSA public keys generated by hardware produced by Infineon Technologies AG. The technical details were presented in a paper at the 2017 Computer and Communications Security conference, hosted by the Association for Computing Machinery on November 2nd. The technique only works against the key pairs produced by Infineon’s library, because it exploits the unique method they use to generate RSA primes.