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.