This is a tad dated, but I need to catch this blog up to the blog posts I've authored for my employer's blog. Here's the blurb for a whitepaper I authored on revocation in web browsers.
The past couple years have had a number of Certificate Authority compromises that have resulted in high-profile sites having fraudulent certificates issued for them. It has shown a spotlight on Certificate Authority practices and also the current trust calculation present in web browsers. Two years ago, iSEC Partners collaborated with the EFF to create the SSL Observatory: a window into the issuing practices of CAs and this year released a scanning tool:sslyze that can be used to scan for SSL misconfigurations. SSL is a critical piece of Internet infrastructure and has been a long time research focus for iSEC Partners.
Recently, I've been interacting with the Certificate Authority/Browser forum on the topic of Certificate Revocation. Many projects like DANE, Convergence, TACK, and numerous others all cover the topic of initial trust - do I trust this certificate or not - the issue of revocation has been left largely alone with the exception of Chrome developing crl-sets. But recovering from failure is at least as important as protecting ourselves from it in the first place, so we have an interest in making sure Revocation provides the properties that we desire. At the September meeting of the CA/B Forum, I presented what I feel is the correct path forward for revocation checking in web browsers.
The paper I presented identifies five key properties a revocation system should provide: to be Privacy Preserving, to be Performant, to have No Single Point of Failure, to Uniquely Identify a Certificate, and finally, to be Effective. After evaluating the possible ways forward, I suggest the path of least resistance and the methodology that can be followed to move us towards a web where you are confident in the status of a certificate. Unfortunately, this requires a concerted effort to develop, test, and deploy updated versions of web servers and convince stakeholders of the benefits of doing so. This paper is meant to spur conversation and be a proposal that others can be compared to. The discussion at the CAB forum overall was positive, and I appreciated the opportunity to meet and discuss these issues with people who also care passionately about this niche of the web infrastructure.
Read our whitepaper Here
This post originally appeared on iSEC Partners' blog.
required, hidden, gravatared
required, markdown enabled (help)
* item 2
* item 3
are treated like code:
if 1 * 2 < 3:
print "hello, world!"
are treated like code: