PKI Consortium blog

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. A digital signature is like a shrink wrap, protecting the code from modification without detection. Second, the code is signed with a digital certificate issued by a public certificate authority which has performed a verification check on the identity of the author. Malware authors don’t like to be identified, hence the likelihood of a legitimate code signing certificate being issued to a malware author is decreased.

CA Security Council Report: Consumers Don’t Know Much About Security, But They Trust the Padlock and Green Bar When Shopping Online
April 13, 2015 by CA Security Council CASC EV Google Identity SSL/TLS

San Francisco – April 13, 2015 – The CA Security Council (CASC), an advocacy group committed to the advancement of the security of websites and online transactions, today released its 2015 Consumer Trust Survey which found that validation matters.  While consumers are confused about some aspects of security, they recognize and trust the security that SSL brings to e-commerce sites.  Fifty-three percent of respondents identify the padlock as adding confidence in an e-commerce site, with 42 percent associating the green bar and organization name in the URL with greater safety.

Microsoft Deploys Certificate Reputation
April 9, 2015 by Bruce Morton (Entrust) EV Google Identity Microsoft Mis-issued SSL/TLS

As we have stated previously, website owners have a concern that an attacker can have a certificate issued for their domain name. We now have two systems which will help monitor certificates for domains: Certificate Transparency (CT) and Certificate Reputation.

At the start of 2015, most certification authorities (CAs) support CT as requested by Google. CT works for extended validation (EV) SSL certificates and will allow all EV certificates to be monitored.

In March 2015, Microsoft deployed Certificate Reputation. Through the use of Windows, Internet Explorer and other applications, certificate data for all types of SSL certificates is collected and provided to Microsoft. In addition, Microsoft has stated that they don’t collect any information that could be used to identify the user.

Who Sets the Rules Governing Certification Authorities?
August 19, 2014 by Kirk Hall (Entrust) CA/Browser Forum Code Signing DV Encryption ETSI EV Google Hash Function Identity IETF Microsoft Mozilla OCSP Policy Revocation Root Program SSL/TLS WebTrust

Every time something positive is published about SSL and encryption,such as Google’s recent decision making use of https encryption a favorable rating factor for a website, or negative, such as the Heartbleed issue – bloggers and others always post questions about public Certification Authorities (CAs), including general questions on who sets the rules that govern CAs. Some bloggers seem to assume there are no rules or standards, and that CAs can operate without any requirements or limitations at all — that’s incorrect.

Revocation – A Cure For the Common Heartbleed
April 28, 2014 by Jeremy Rowley Attack CASC Chrome CRL Google Identity OCSP Revocation SSL/TLS

The Heartbleed bug spurred server administrators worldwide to work closely with Certification Authorities (CAs) in rekeying and reissuing potentially vulnerable SSL certificates. Part of this effort included revoking existing certificates used on vulnerable servers to ensure obtained private keys are not later used in a man-in-the-middle attack against the website. Unfortunately, in recent days, certain news reports and blogs addressing certificate revocation and checking for revoked certificates online have failed to discuss the benefits of revocation, instead focusing on the minority of circumstances where widely deployed revocation is not perfect. In the interest of providing balanced information to the public, we, as members of the CA community and as individuals generally interested in a high level of Internet security, would like to help clarify some of the issues confused by these reports and blogs.

Always-On SSL, Part I
January 16, 2014 by Rick Andrews Encryption Google Identity Microsoft Mixed Content OpenSSL SSL/TLS

There is no doubt that content owners and publishers have a duty to encourage trust and the confidence during internet usage by adopting security best practices. If a customer believes that their data and identity are safe and protected, they are more inclined to continue their online transactions. Industry best practices for website protection should be vendor-neutral, easy to implement, and globally accessible. Websites should take all the reasonable steps possible to adopt best practices in secure design and implementation, and this includes using Always-On SSL across the entire website.

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.

How Organizations Are Authenticated for SSL Certificates
November 22, 2013 by Kirk Hall (Entrust) CA/Browser Forum CSR DV EV Identity OV Phishing Policy SSL/TLS

Certification Authorities (CAs) are trusted third parties that authenticate customers before issuing SSL certificates to secure their servers.

Exactly how do CAs authenticate these organizations? And where are the rules that determine what CAs must do during authentication?

The Rules on Customer Authentication

In the past, there were no common rules applicable to CAs as to minimum steps required to authenticate a customer before issuing an SSL certificate. Instead, each CA was permitted to create its own authentication processes, and was only required to describe the process in general terms in its public Certification Practice Statement (CPS). In many cases, the CPS authentication description was vague and hard to understand, and some CAs were less diligent than others during authentication.

Improving Code Signing
November 14, 2013 by Jeremy Rowley CA/Browser Forum Code Signing Identity Malware SSL/TLS

Previously, we discussed how code signing certificates play a key role in the trust framework by proving the authenticity of software. As mentioned, code signing certificates act as a certification that the software was unmodified after publication. Although current code signing practices greatly reduce the threats of malware and adware embedded in signed objects, the sophistication of threats has risen and there is a need for improvement. When code signing was new, skilled criminal hackers were the exception and script kiddies were the norm. Now, the skill level and sophistication of criminal networks, and even nation states, have advanced to the point where customized malware is being used to penetrate company networks, steal valuable information, and even tamper with sensitive infrastructure.

The (Soon to Be) Not-So Common Name
October 8, 2013 by Ryan Hurst CA/Browser Forum CRL Encryption Identity IETF Revocation SSL/TLS Vulnerability

If you are reading this post you are probably already familiar with the use of digital certificates and SSL even if you may not be familiar with the history. Before exploring the history of SSL, let’s review at its core what a digital certificate actually is. Fundamentally, a digital certificate is the binding of entitlements and constraints to a key, in other words a digital certificate would dictate the following, “The holder of the private key associated with this certificate can rightfully use the name John Smith when signing emails.”