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.

Why You Should Get Familiar With TLS If You Accept Credit Cards
April 28, 2015 by Billy VanCannon Encryption PDF SSL/TLS Vulnerability

The group that manages the Payment Card Industry Data Security Standard quietly announced in February that an imminent update was coming to its payment card and application requirements related to the use of the SSL encryption protocol. Since then, there has been growing concern among merchants about what the changes mean to them.

The confusion among retailers generally can be boiled down to two questions:

1. What will the new updates require me to do?
2. What happens to my TSL/SSL certificates?

First let’s explain what’s going on: On Feb. 13, the PCI Security Standards Council informed its assessor community that SSL (Secure Sockets Layer) – a protocol designed to ensure that data provided between a web server and a web browser, such as credit card information, remains secure – is no longer an acceptable way to provide “strong cryptography.” This is due to a number of known fundamental vulnerabilities – some of which, such as Heartbleed, we have documented here, here and here – that essentially make SSL, as an encryption mechanism, obsolete.

Java Secures Supply Chains Through Code Signing
December 9, 2013 by Bruce Morton (Entrust), Erik Costlow (Oracle) Code Signing Identity PDF

We have recently discussed the benefits of code signing in two posts: Securing Software Distribution with Digital Signatures and Improving Code Signing. These posts covered the role of code signatures as a “digital shrinkwrap” designed to answer a simple question: Did the software I am about to run actually come from the author or has someone changed it along the way?

As software is downloaded, assembled, copied, distributed and redistributed, it can be modified at any point along the supply chain. Some modifications are designed to insert advertising into software, others add tracking capabilities, and others could be more nefarious, such as compromising the entire host or stealing data.