PKI Consortium blog

Posts by author Bruce Morton

    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.

    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.

    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.

    CAs Support Standards and Regulations
    May 10, 2013 by Bruce Morton (Entrust) CA/Browser Forum CASC CICA ETSI EV SSL/TLS WebTrust
    There is an industry myth that certification authorities (CAs) are not regulated. In fact publicly-trusted SSL CAs support the development of industry regulations and have been audited annually to ensure compliance to the many requirements. To provide some history, SSL CAs have always self-policed themselves by having external audits performed. In the ‘90s, the CAs wrote certificate policies and certification practice statements requiring annual compliance audits. Since there were no CA audit criteria, the CAs contracted for SAS 70 audits.

    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.

    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.

    Participate in our community discussions and/or join the consortium