PKI Consortium blog

ICANN’s Accelerated gTLD Delegation Process and How This Impacts Your Organization
December 18, 2013 by Jeremy Rowley Announcement CA/Browser Forum CASC ICANN MITM Mozilla PKI Policy Qualified Revocation SSL/TLS Vulnerability
After the CASC’s previous letter addressing ICANN’s proposal to delegate nearly 2000 new gTLDs for use on the public Internet, ICANN identified and initiated an extensive study on two significant security issues. Now, based on the conclusions of the studies, ICANN is moving forward quickly with the delegation process, delegating more than 30 in the last two months alone. With ICANN ramping up the delegation process, nearly all 2000 will be delegated under the new rules, with only .

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.

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.

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).

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.

Certificate Chains, Key Management and the Number of CAs Counted by Web Crawlers – Oh My
November 4, 2013 by Ryan Hurst CRL Microsoft OCSP PKI Policy Revocation SSL/TLS
Have you ever wondered why your web server certificate has a “chain” of other certificates associated with it? The main reason is so that browsers can tell if your certificate was issued by an organization that has been verified to meet the security, policy and operational practices that all Publicly Trusted Certificate Authorities are mandated to meet. That certificate at the top of the chain is commonly called the “root.” It’s signature on a certificate below it indicates that the organization operating the root believes that practices of the CA below it meets that same high bar.

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.

Certificate Authority Audits and Browser Root Program Requirements
October 15, 2013 by Kirk Hall (Entrust) AICPA CA/Browser Forum CASC ETSI EV ISO ITU Microsoft Policy Qualified Root Program SSL/TLS WebTrust
Recent news stories have highlighted the need for strong security in online communications, and use of SSL certificates issued by a publicly trusted Certification Authority (CA) is perhaps the best way to achieve that. But why should the public trust SSL certificates issued from commercial CA roots, which are embedded as trust anchors in web browsers? One answer is because of the multiple layers of standards and tough requirements that all commercial CAs must meet – and for which they are audited every year.

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.