PKI Consortium blog

Recap of NIST’s Workshop on Improving Trust in the Online Marketplace
April 17, 2013 by Rick Andrews CA/Browser Forum CASC NIST Revocation SSL/TLS

On April 10 and 11, NIST held a workshop in Maryland to bring together many parties (industry, research and academia communities, and government sectors) to examine “technical and administrative efforts to increase trust online by improving the Public Key Infrastructure certificate marketplace supporting SSL and TLS.”

From the opening keynote to the final remarks, we heard from experts around the world. There were presentations on the current state of trust infrastructure and audits, the impact of recent breaches, detailed looks on some emerging solutions like Certificate Transparency and DANE, and new ideas to manage and minimize risk in key usage.

CASC Happenings at NIST
April 10, 2013 by CA Security Council CASC NIST PKI Policy SSL/TLS TSP

This week members of the CASC will be attending and speaking at the NIST Workshop on Improving Trust in the Online Marketplace. You can also follow the CASC on Twitter for more information and news at @CertCouncil, as well as see some of the presentations after the events on our SlideShare page. Even if you can’t make it to Maryland, you can still watch the event via the live webcast. Please join us for the following CASC member events:

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.

What the ICANN SSAC Report Doesn’t Tell You
March 22, 2013 by CA Security Council CA/Browser Forum CASC ICANN SSL/TLS

The CA Security Council, which comprises seven of the largest CAs, read with interest the article titled, “Internal-use SSL certificates pose security risk for upcoming domain extensions.” As a group in one of the best positions to understand the impact of the new gTLDs on organizational security infrastructure and the Internet as a whole, we felt it appropriate to comment on this and related stories which summarize the ICANN Security and Stability Advisory Committee (SSAC) report sac 045 Invalid Top Level Domain Queries at the Root Level of the Domain Name System.

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.

All You Need to Know About the RC4 Encryption Scheme
March 14, 2013 by Rick Andrews Attack CASC Encryption RC4 RSA SSL/TLS Vulnerability

The latest published attacks target specific algorithms used within SSL/TLS. Those algorithms are used when a client connects to a server via SSL/TLS; they’re not used when a Certificate Authority signs a certificate. The attacks demonstrate potential weaknesses in the use of the algorithms.

While interesting, the attacks don’t represent an immediate practical threat to users of SSL/TLS (including online banking, e-commerce, social networking, etc.). Such attacks require an attacker to run malicious software on a user’s computer which would connect to a particular web site and send the same message over and over again many times. In fact, if the attacker’s software could send the same message over and over 10 times per second, it would still take more than 3 years for the attack to succeed.

The Importance of Revocation Checking Part 2: A Real World Example
March 11, 2013 by Wayne Thayer Attack Code Signing CRL Encryption Identity Malware OCSP Revocation SSL/TLS

Just last week, a new security incident related to certificate revocation checking made headlines. It was discovered that a legitimate website was hosting a malicious Java application that installed malware on the computers of people who visited the site. This comes after recent updates that introduced Security Level settings in Java, and then raised the default from Medium to High. At the high level, users are shown a warning before any unsigned Java code is executed. Unfortunately, this recent incident exposed a method that allows an attacker to bypass the warning.

The Importance of Checking for Certificate Revocation
March 9, 2013 by Rick Andrews Attack CRL Identity Malware MITM OCSP Revocation SSL/TLS

Certificates are typically valid for one to three years, and during that time it’s possible that the web site owner or the CA realizes that end users should not trust the certificate. There are several cases in which this might happen, including these:

• The web site owner ceases doing business, no longer owns the domain name used in the certificate, has changed their organization name, or wishes to shut down the web server.
• The subscriber learns that an unauthorized party has gained access to the private key associated with the public key in the certificate.
• The CA learns that errors were made in authentication, the subscriber misrepresented some material info used in the authentication process, or the subscriber has violated the terms of its agreement with the CA.

When the subscriber or CA makes the decision to revoke a certificate, that decision must be conveyed to end users who encounter the certificate in use. There are two different methods for this:

RSA Recap – Securing Your Site
March 8, 2013 by Ben Wilson BEAST CASC Encryption Firefox Hash Function HSTS OpenSSL Policy RSA SSL/TLS TLS 1.1 TLS 1.2 Vulnerability

At RSA last week a few of us participated in panel discussions that focused on SSL/TLS. During the panel that I moderated on Friday, one theme we addressed was secure server configuration. One of CASC’s goals is to help harden existing SSL/TLS implementations against vulnerabilities—because most SSL/TLS exploits arise from suboptimal website configurations. These vulnerabilities and attacks can be mitigated or even eliminated with proper server configuration and good website design.

CASC Happenings at RSA
February 25, 2013 by CA Security Council Attack CASC Identity PKI RSA SSL/TLS

We are excited to have members of the CASC attending and speaking at this year’s RSA Conference. The events and panels will cover various topics that revolve around the security of the Internet and CAs as a whole. You can follow the CASC on Twitter for more information and news at @CertCouncil, as well as see some of the presentations after the events on our SlideShare page. Please join us for the following CASC member events: