PKI Consortium blog

Posts by tag IETF

    2015 – Looking Back, Moving Forward
    January 6, 2015 by Bruce Morton (Entrust) Apple Attack CA/Browser Forum CAA Chrome Code Signing EV Firefox Forward Secrecy Google IETF Malware Microsoft MITM Mozilla OpenSSL PKI Policy RSA SHA1 SSL 3.0 SSL/TLS TLS 1.0 TLS 1.2 TLS 1.3 Vulnerability

    Looking Back at 2014

    End of 1024-Bit Security

    In 2014, the SSL industry moved to issuing a minimum security of 2048-bit RSA certificates. Keys smaller than 2048 are no longer allowed in server certificates. In addition, Microsoft and Mozilla started to remove 1024-bit roots from their certificate stores. Hopefully, the key size change will support users through to 2030.

    A Follow-up on POODLE and SSL 3.0
    November 21, 2014 by Bruce Morton (Entrust) Attack Encryption Google IETF Mozilla OpenSSL SSL 3.0 SSL/TLS TLS 1.0 TLS 1.1 TLS 1.3 Vulnerability

    In October 2014, Google announced POODLE, an SSL 3.0 protocol attack.

    To bring you up to speed, the SSL/TLS protocol is the most important and popular security protocol on the Internet. The Secure Sockets Layer (SSL) protocol was developed by Netscape. They quickly moved from SSL 1.0 to 2.0 and finalized with SSL 3.0 in 1996.

    This protocol was then picked up by the IETF, who released it under the name of Transport Layer Security (TLS). The IETF released TLS 1.0, 1.1 and 1.2. They are currently working on TLS 1.3.

    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.

    CA Security Council Members Presentation at RSA 2014 Conference: New Ideas on CAA, CT, and Public Key Pinning for a Safer Internet
    March 17, 2014 by Kirk Hall (Entrust) Attack CAA CASC Chrome EV Google IETF Microsoft Mis-issued OCSP Revocation RSA SSL/TLS Vulnerability

    CA Security Council (CASC) members Trend Micro, Go Daddy, and Symantec participated in a discussion panel at the 2014 RSA Conference in San Francisco on February 24 entitled “New Ideas on CAA, CT, and Public Key Pinning for a Safer Internet.” Panel members included Kirk Hall of Trend Micro (Moderator), Wayne Thayer of GoDaddy (Panelist), and Rick Andrews of Symantec (Panelist).

    Introduction to the Topic

    Hall began by introducing the topic – all three alternative technologies (Certificate Transparency or CT, Certificate Authority Authorization or CAA, and Certificate Pinning) are intended to make the internet safer by dealing with mis-issued digital certificates, including so-called “rogue” certs like those obtained by a hacker from the now-defunct Diginotar Certification Authority (CA). Mis-issued certs generally present the greatest potential danger when they are for the most popular fraud target domains, such as mail.google.com, login.yahoo.com, login.live.com, etc.

    2014 – Looking Back, Moving Forward
    January 6, 2014 by Bruce Morton (Entrust) Attack BEAST CA/Browser Forum CAA Code Signing ECC Encryption Forward Secrecy HSTS ICANN IETF Microsoft MITM Mozilla PKI Policy RC4 RSA SHA1 SSL/TLS TLS 1.2

    Looking Back at 2013

    Protocol Attacks

    The year started with a couple of SSL/TLS protocol attacks: Lucky Thirteen and RC4 attack. Lucky Thirteen allows the decryption of sensitive information, such as passwords and cookies, when using the CBC-mode cipher suite. Lucky Thirteen can be mitigated by implementing software patches or preferring the cipher suite RC4.

    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.

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

    What is Certification Authority Authorization?
    September 25, 2013 by Rick Andrews CAA IETF Policy SSL/TLS

    DNS Certification Authority Authorization (CAA), defined in IETF draft RFC 6844, is designed to allow a DNS domain name holder (a website owner) to specify the certificate signing certificate(s) authorized to issue certificates for that domain or website. Usually, the certificate signing certificate will belong to the Certification Authority (CA) that issues SSL certificates to you. It’s a way for you to indicate which CA or CAs you want to issue certificates for your domains. Using CAA could reduce the risk of unintended certificate mis-issuance, either by malicious actors or by honest mistake.

    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.

    Some Comments on Web Security
    June 5, 2013 by CA Security Council Attack CA/Browser Forum CASC Google IETF Microsoft Mis-issued Policy SSL/TLS

    Steve Johnson of the Mercury News posted an article on Web security and highlighted some of the issues.

    The posted issues help to explain why we created the Certificate Authority Security Council. We want to determine the issues, have them addressed and provide awareness and education on the solutions. The CAs also work with the browsers and other experts in the industry to develop standards for all CAs to be audited against through the CA/Browser Forum.

    Participate in our community discussions and/or join the consortium