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.

The Latest on Certification Authority Authorization
March 21, 2017 by Jeremy Rowley Attack CA/Browser Forum CAA Encryption Identity OV PKI Policy Qualified

Things are certainly heating up at the CA/Browser with exciting proposals surrounding inclusion of the Wi-Fi Alliance (WFA) as a subjectAltName otherName, new validation methods, and debates over how the CAB Forum will continue operating. One of these newly passed ballots requires all CAs to check and process a domain name’s DNS Certification Authority Authorization (CAA) resource record prior to issuing a digital certificate.

Background

RFC 6844 created CAA records as a method for domain owners to specify a policy on which certificate authorities are authorized to issue certificates for the associated domain. The basic concept is that immediately prior to issuance, the certificate authority (CA) will check the CAA record and determine whether policy permits creation of the certificate. Issuance is permitted if either a CAA record does not exist for the domain or the CAA record lists a string specified by the CA as authorizing the CA to issue the certificate. Using CAA records, the domain owner is able to control policy at a more granular level, including specifying which CA can issue wildcard certificates and how to report issues. Note, that CAA record checking is an additional requirement that occurs after the CA completes the normal domain verification process required by the CA/Browser Forum’s baseline requirements under Section 3.2.2.

2017 – Looking Back, Moving Forward
January 13, 2017 by Bruce Morton (Entrust) 3DES Apple Attack CA/Browser Forum CAA Chrome Code Signing Encryption Firefox Google Identity Malware MITM Policy Revocation RSA SSL 3.0 SSL/TLS TLS 1.3 TSA Vulnerability

Looking Back at 2016

Fortunately, 2016 was not a year full of SSL/TLS vulnerabilities. Although some researchers did prove old cryptography algorithms should be put out to pasture. The year showed the end of public-trusted SHA-1 SSL/TLS certificates. It also showed more transparency should be considered due to issues discovered with a few certification authorities (CAs). The great news is HTTPS is no longer the minority — after 20 years, connections using HTTPS has surpassed HTTP.

Google Certificate Transparency (CT) to Expand to All Certificates Types
November 8, 2016 by Jeremy Rowley Announcement CA/Browser Forum Chrome DV EV Google IETF OV Policy SSL/TLS

The policy change goes into effect October 2017

A recent Google announcement stated that all publicly trusted SSL/TLS certificates issued in October 2017 or later will be expected to comply with Chrome’s Certificate Transparency (CT) policy or be untrusted by the browser.

Why Is Certificate Expiration Necessary?
October 19, 2016 by Bruce Morton (Entrust) Attack CA/Browser Forum EV Hash Function Identity OCSP Policy RSA SSL/TLS Vulnerability

The Long Life Certificate – Why It Doesn’t Exist

Why is certificate expiration even necessary? Wouldn’t it be better if I could just buy a certificate with a long life before expiration? It would really simplify certificate management if it could be installed and forgotten. Simple, no management required, just file-and-forget.

Minimum Requirements for Code Signing Certificates
July 20, 2016 by Bruce Morton (Entrust) CA/Browser Forum CASC Code Signing FIPS HSM Malware Microsoft Revocation TSA

It is time for an update on the Baseline Requirements for Code Signing.

First the bad news, the new standard was not approved by the CA/Browser Forum due to philosophical differences among some forum members who felt code signing was not in scope with the Forum’s charter.

The good news is the document was created in a multi-stakeholder environment and substantially improves the current management processes. As such, it was decided to bring the document outside of the forum and finalize it as part of the CA Security Council. The CASC members and others will continue to enhance and manage the document. Microsoft also supports the document and has added the requirement to use the new standard for code signing certificates by February 1, 2017.

TLS Certificates on the Web – The Good, The Bad and The Ugly
May 17, 2016 by Rick Andrews CA/Browser Forum Code Signing ECC Encryption EV Hash Function PKI Policy RSA SSL/TLS

It might be hard to believe, but the SSL/TLS Ecosystem is nearly 20 years old. It’s time to take stock and see how we’re doing with regards to TLS certificates. In this article, we’ll primarily discuss certificates themselves and not web server configuration, although that is often a source of problems.

In the last few years, we’ve endured three major certificate-based migrations:

• Away from the MD2 and MD5 hash algorithms to SHA-1
• Away from small RSA keys to 2048-bit keys or larger
• Away from the SHA-1 hash algorithm to SHA-256

What’s driving these migrations? Primarily, it’s the relentless march of attacks. As Bruce Schneier says, “Attacks always get better; they never get worse.” To stay ahead of these attacks, Certification Authorities and browser vendors joined together several years ago to form the CA/Browser Forum, and published several requirements documents: the Baseline Requirements, the EV SSL Guidelines and the EV Code Signing Requirements.

2016 – Looking Back, Moving Forward
December 14, 2015 by Bruce Morton (Entrust) Attack CA/Browser Forum CAA Chrome Code Signing DH Encryption Firefox Google Hash Function IETF Microsoft MITM OpenSSL Policy RC4 Revocation RSA SSL/TLS TLS 1.2 TLS 1.3 Vulnerability

Looking Back at 2015

A number of new tactics proved 2015 was no exception to an active year defending against ever increasing security issues. Vendors found new and creative ways to provide vulnerabilities including the now popular man-in-the-middle (MitM) attacks.  MitM as well as a host of other new vulnerabilities caused browsers to rethink their security requirements.  This article gives a flashback of the exploits and industry changes from 2015 and looks ahead at the latest security requirements and how it impacts IT security teams.

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.

SSL Certificate Validity Periods Limited to 39 Months Starting in April
February 19, 2015 by Jeremy Rowley CA/Browser Forum ETSI Policy SSL/TLS Vulnerability WebTrust

In accordance with the CA/Browser Forum Baseline Requirements, effective April 1, 2015, Certificate Authorities (CAs) will no longer be able to issue SSL Certificates with a validity period longer than 39 months.

Shortening the validity period to 39 months is the result of much consideration within the CA/Browser Forum to arrive at a duration that allows optimal usability while maintaining the tightest network security. A shortened validity period will significantly improve Internet security by requiring administrators to renew and verify their certificates more often. It will also make it easier for users to keep up-to-date on new advances in security and remain aware of their control over private keys.