PKI Consortium blog

Posts by tag OV

    CASC Announces Launch of London Protocol to Improve Identity Assurance and Minimize Phishing on Identity Websites
    June 27, 2018 by CA Security Council Attack CA/Browser Forum CASC DV EV Identity OV Phishing SSL/TLS

    LONDON – (June 27, 2018) – The Certificate Authority Security Council (CASC), an advocacy group committed to the advancement of the security of websites and online transactions, announced at the CA/Browser Forum event in London the launch of the London Protocol – an initiative to improve identity assurance and minimize the possibility of phishing activity on websites encrypted with organization validated (OV) and extended validation (EV) certificates, which contain organization identity information (Identity Certificates).

    The London Protocol
    June 27, 2018 by CA Security Council DV EV Identity OV Phishing

    The objective of The London Protocol is to improve identity assurance and minimize the possibility of phishing activity on websites encrypted by OV (organization validated) and EV (extended validation) certificates (together referred to as “Identity Websites”). The London Protocol reinforces the distinction between Identity Websites making them even more secure for users than websites encrypted by DV (domain validated) certificates. That security feature can then be utilized by others for their own security purposes, including informing users as to the type of website they are visiting and use by antiphishing engines and browser filters in their security algorithms.

    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.

    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.

    Think Twice Before Using DV for E-Commerce
    March 12, 2014 by Dean Coclin DV Encryption EV OV Phishing SSL/TLS

    In a previous blog (What Are the Different Types of SSL Certificates?), we described the various types of SSL certificates available from publicly trusted Certificate Authorities (CAs).  CAs are often asked by their customers which certificate type should be used for websites conducting E-Commerce, rather than for just encryption of sensitive data. For the latter case, a Domain Validated (DV) certificate will work fine. A DV cert allows for encryption to take place between the browser and the server. However, because DV certificates do not contain any identification information, they SHOULD NOT BE USED for E-Commerce.  Why? Let’s look deeper at the differences between these certificates.

    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). In many cases, the CPS authentication description was vague and hard to understand, and some CAs were less diligent than others during authentication.

    Participate in our community discussions and/or join the consortium