PKI Consortium blog

SHA-1 Deprecation, On to SHA-2
December 16, 2013 by Bruce Morton (Entrust) Code Signing Microsoft PKI Policy SHA1 SSL/TLS

We have previously reviewed implementation of SHA-2, but with Bruce Schneier stating the need to migrate away from SHA-1 and the SHA-1 deprecation policy from Microsoft, the industry must make more progress in 2014.

Web server administrators will have to make plans to move from SSL and code signing certificates signed with the SHA-1 hashing algorithm to certificates signed with SHA-2. This is the result of the new Microsoft Root Certificate Policy where Microsoft deprecates SHA-1 and imposes the following requirements:

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.

IETF 88 – Pervasive Surveillance
November 26, 2013 by Bruce Morton (Entrust) Attack CRL Encryption Forward Secrecy HSTS IETF PKI Revocation SSL/TLS Vulnerability Web PKI

Internet Surveillance

The big news at IETF 88 in Vancouver was the technical plenary on Hardening the Internet which discussed the issue of pervasive surveillance. Pervasive surveillance is a mass surveillance of an entire or a substantial fraction of a population. The surveillance is usually carried out by government, is not targeted and its occurrence may not be overt. It was noted that pervasive surveillance, of the kind revealed in the Snowden-sourced documents, constitutes a misguided and damaging attack on civic society in general and the Internet in particular.

Securing Software Distribution with Digital Code Signing
October 16, 2013 by Bruce Morton (Entrust), Jeremy Rowley CASC Code Signing Malware SSL/TLS

Code signing certificates from publicly trusted Certification Authorities (CAs) fulfill a vital need for authentication of software distributed over the Internet in our interconnected world. As the commonly referred to “Internet of things” continues to grow, consumers have access to millions of applications for their desktops, laptops, and mobile devices. Creative software engineers provide us with applications to cover any of our potential needs or interests. Cybercriminals and others with malicious intent recognize this as an opportunity and seek to trick us into installing malicious software (malware) — programs that hijack our computers, steal our money, or try to inflict harm.

Public Key Pinning
August 28, 2013 by Bruce Morton (Entrust) Android Chrome Google IETF Mis-issued SHA1 SSL/TLS

The current browser-certification authority (CA) trust model allows a website owner to obtain its SSL certificate from any one of a number of CAs. That flexibility also means that a certificate mis-issued by a CA other than the authorized CA chosen by the website owner, would also be accepted as trustworthy by browsers.

This problem was displayed most dramatically by the DigiNotar attack in 2011 and in a mistaken CA certificate issued by TURKTRUST in 2012. In these cases, certificates were issued to domains that were not approved by the domain owner. Fortunately, the problem was detected in both cases by public key pinning, which Google implemented in Chrome.

CAs Support Standards and Regulations
May 10, 2013 by Bruce Morton (Entrust) CA/Browser Forum CASC CICA ETSI EV SSL/TLS WebTrust

There is an industry myth that certification authorities (CAs) are not regulated. In fact publicly-trusted SSL CAs support the development of industry regulations and have been audited annually to ensure compliance to the many requirements.

To provide some history, SSL CAs have always self-policed themselves by having external audits performed. In the ‘90s, the CAs wrote certificate policies and certification practice statements requiring annual compliance audits. Since there were no CA audit criteria, the CAs contracted for SAS 70 audits.

Self-Signed Certificates Don’t Deliver Trust
April 2, 2013 by Bruce Morton (Entrust) CRL DV EV NIST OCSP Policy SSL/TLS

We’ve heard the argument that website operators could just use self-signed certificates. They are easy to issue and they are “free.” Before issuing self-signed certificates, it’s a good idea to examine the trust and security model. You should also compare self-signed certificates to the publicly trusted certification authority (CA) model; and then make your own decision.

Self-Signed Certificate Model

• Owner says who they are
• Owner issues on their own policy
• Owner is responsible for quality
• Owner may not follow industry guidelines
• Owner may not provide certificate status
• Compromised certificates may not be able to be revoked
• Owner is not audited
• Issuer of certificate may not be authorized by the domain owner
• Certificates may not be renewed if there are no reminders
• Self-signed certificate model does not provide trust and the browser provides a trust dialogue box to indicate such

Publicly-Trusted CA-Signed Certificate Model

• CA verifies the owner of the domain and the certificate applicant
• CA operates to a policy in conformance with the requirements of the browser and operating system vendors. The requirements include the CA/Browser Forum Baseline Requirements, Extended validation (EV) Guidelines and recommendations from NIST.
• CA provides quality to the certificate. Checks include compromised keys, minimum key size, ensuring hashing algorithms, maximum validity period and proper certificate extensions.
• CA updates policy based on industry best practices
• CA provides certificate status through CRL and OCSP
• Compromised certificates can be revoked
• CA is audited to certificate issuing criteria such as WebTrust for CA, WebTrust for EV and SSL Baseline Requirements
• Certificate requesters for a Domain validated certificate are authorized by the owner of the domain. Requesters for Organization and Extended Validation certificates are authorized by a member of the organization specified in the certificate.
• CAs provide multiple reminders to ensure the certificates are renewed before they expire. CAs may also provide certificate discovery tools to find certificates on your systems which may not have reminders.
• Publicly trusted CA model is based on the CA being a trusted third party to the browser/OS vendor, the website certificate subscriber and the end-users of the website. The CA is obligated to meet the requirements of all three parties.

So, when should you use a self-signed certificate?

When trust, security, service, quality and reliability are not your criteria.

IETF 86 – Web PKI Working Group
March 21, 2013 by Bruce Morton (Entrust) CRL Google IETF OCSP PKI Policy Revocation SSL/TLS Web PKI

At the IETF 86 meeting in Orlando last week, there was a working group meeting discussing the operations of the Web PKI. At the previous IETF 85 meeting a birds-of-a-feather was held to discuss the purpose of having such a group. The result of the meeting was an established group with the charter that states purposes such as:

• Working group will work to improve the consistency of Web security behavior
• Address problems as seen by the end-users, certificate holders and CAs
• Describe how the Web PKI actually works
• Prepare documented deliverables as discussed below

The meeting discussed the charter and the four following deliverables. More information is in the presentation slides; look under the Operations and Management Area, then under WPKOPS.