Previous article on ‘Comprehending Public Key Infrastructure behind SSL’, took you through the concept of Public Key Infrastructure (PKI) and how to build trust in the PKI Model. This article continues with the challenges faced by the Public PKI Model and their solutions.
Challenges Faced by the Public PKI Model
The existing PKI model of trust may have satisfied the hidden goal ofg allowing end users in using SSL secured website securely, but the model is suffering from disputes that threaten to ruin the safety of the entire model.
1. Efforts to get fraudulent certificates are on the rise: The commercial CA in public PKI model, are given the tough task of confirming the identity and right of a specific entity, in order to operate a given website. Due to the global nature of internet these days, authorization or identity verification process is relatively consistent across various countries, customs and legal regulations. Moreover, the sheer number of requests that CA are supposed to handle for SSL certificates on a daily basis, requires outsourcing of some aspects of the CA operation.
2. Dearth of effective revocation mechanisms: The present revocation mechanisms that are used today in PKI are – use of consistently published blacklists of established, untrusted certificates. These blacklists, also called certificate revocation lists (CRLs) are routinely created by CA and hosted on publicly visible URL. The revocation list URL is ingrained in SSL certificates. This mechanism depends on the browser, which is constantly downloading the CRLs that have been published by CAs and reviewing SSL certificates against the CRL list. However, there is a significant flaw in the CRL mechanism and that is CRLs are published repeatedly and that means that if a fraudulent certificate is issued soon after a CRL is published, the fraudulent certificate is not going to be listed in the CRL till it is next updated.
3. Anticipated lack of clarity in the PKI model: The final critical challenge facing the public PKI model is a complete lack of visibility into the different trust relationships, established so that the model could work. It is not necessary that the commercial CA are known to the end users, which is a normal side effect of attempting to simplify the security model for end users. So, when somebody visits a website and clicks on the certificate details for a website, they are provided with a brand name, which does not have any meaning to them. While commercial CA have a standard documentation that describes the practices in delivering certificates to websites, these documents are very technical and have legalese that is not easy for a end user to understand.
Looking at the challenges listed above, there is a huge amount of activity among the browser manufacturers. IETF and CA standard organizations to offer various solutions that are designed to help address some of the issues. Normally the solutions balance each other, but like other groups of organizations whose interests don’t match, there are some major differences.
Provide an instrument for website operators to protect websites without depending on public CA issued certificates.
One solution discussed by former IETF KeyAssure and DANE working groups is to influence the public DNSSEC service that has been launched recently, in order to provide information, used by a web browser, to conform whether or not an SSL certificate, presented to a browser is similar to the one website operator provisions on their website.
This solution is based on the assumption that an SSL certificate is not made to imply any kind of ‘trustworthiness’ towards a particular website but is designed to provide a cryptographic means for relations to a website to be classified and safeguarded from man-in-the-middle attacks.
Provides an instrument to website operators to clarify which public CA has delivered their certificate. The DANE working group discussion provides another interesting solution that allows website operators to stipulate which particular CA issued their certificate. The solution allows website operators to manage a ‘whitelist’ of CA, sanctioned to issue SSL certificates for their websites. This whitelist is called Certificate Authority Authorization (CAA) extension. According to the solution explained earlier, by using DNSSEC to protect the DNS records, the DNS record information can be honored by the end user. This kind of whitelist assists website operators and browsers to assure that SSL certificate has not been secretly restored by another certificate that has been signed by a different CA. This hybrid solution allows the website operator to get extended affirmation certificates from a public CA. Thus, end users can surely trust whether it is an authentic website, based on EV criteria.
Develop a dynamic SSL certificate mapping to websites. This is a planned solution that works towards building a ‘history’ of particular certificates that are used to secure repeatedly visited websites, within the browser or in public, in a database that is externally maintained. The idea of this approach is that considering the certificates are seldom changed during the usual operation (most of the public SSL certificates have a span of 3 to 5 years), a website certificate change (which is triggered by a change in the CA which issues the certificate or by a change in the certificate content), is generally expected and can be used to trigger a warning to the user.
A number of other proposals are presently being actively discussed in different work groups, in order to improve the overall security model for public SSL and PKI certificates. For example, to handle the difficulty in adequately revoking certificates, extensions are being suggested to TLS that would allow websites to directly contact OCSP server and attach OCSP response to TLS certificate messages, sent to web browsers. A browser that understands OCSP attached TLS messages can then use OCSP response to confirm whether a certificate has not been revoked. This method, also called OCSP stapling, takes care of privacy and availability issues that come up when browsers directly contact OCSP servers.