There is much talk on the web about Encryption lately. There has been much talk about whether CAs (Certification Authorities) should care who they enable with encryption or not.
I will attempt at clarifying these issues, as I see the world of PKI and encryption.
So what is Encryption:
the process of converting information or data into a code.
Here is a quick encryption for you….my message is ABCD……let me encrypt…… encrypted message is FGHI…..(Guess what the key was!)
Why do we use Encryption:
Unfortunately this is where the confusion comes in …….mixing of different use cases…
There are two distinct use cases for the use of Encryption….and each side talks as if their use case is the only one that must exist! But before we talk about these, lets talk about the “core reason” why we encrypt, then we’ll talk about the two different use cases.
In encryption there is always Someone (Identity) involved. Sometimes you want to avoid this “Someone”, and sometimes you want only that “Someone” to have access to your messages….
Now lets talk about the confusion……..
Who is that Someone? Who is the naughty guy you want to avoid or nice guy to encrypt for?
Well it depends who you talk to ….
To Avoid…….
If you talk to The Guardian they say they need to encrypt their websites so that ISPs can’t interfere with their ad revenue and profit from the Guardian’s content without the Guardian being reimbursed. And New York times agrees with the need for Encryption to protect from ISPs
And they have a very valid use case for Encryption! Imagine if all the ISPs started blocking all the ads at ISP level . This would drastically change the online advertising eco-system causing an existential threat to any company who relies on online ad revenue. This is why IAB has been at the forefront of adopting encryption.
Therefore the problem we want encryption to solve in this use case is to make sure ISPs cannot read the content. We have “Identified” “someone” we want to “Avoid” – the ISPs. What we are saying is, you know what, I don’t care who else reads this as long as “those guys” (ISPs) don’t! Afterall its a public news website….. accessible to public but not to ISPs……with that we have our First Use Case for Encryption called “To Avoid”. You can encrypt content to “avoid” someone – the ISPs.
But I hear you saying, Yeah but that doesn’t make sure that only the “Intended” recipient can read my stuff…..that is correct…thats a different use case….Lets say you want only Paypal to be able to read your stuff when you are on the PayPal site, how will you know you are encrypting it for PayPal, unless you have confidence those encryption keys belong to PayPal? And this is our Second Use Case…“Encrypt For” the intended recipient so that only he/she can read your content.
So lets analyze who wants which type of encryption…..“To Avoid” or “Encrypt For”.…
Rightly so, for any business relying on Ad revenue, encryption method of “To Avoid” becomes a must! But on the other hand billions of users and millions of businesses want to be able to trust eachother and exchange information securely knowing who the recipient is. And thats where the clash and confusion comes from! We mix and match use cases and browser indicators and morph into something weird!
So how can we institute the “To Avoid” encryption model?
Setup a CA and without caring about who the end entity is, issue certificates so that all the communication is encrypted. In this model, you don’t care about anything but just issuing certificates, to anybody and you don’t need to check who they are, because in this model you simply don’t care. This achieves the goal of encrypting the traffic to avoid ISPs. Because the web PKI model was built with “Encrypt For” methodology, where end users “trust the indicators”, once you introduce the additional model of encryption “The Avoid” methodology with the same indicators, of course you will cause confusion. Same as kids going to the zoo and seeing the above Gorilla/Dog 🙂 Confusion!!! End users, rightly so, associate the trust indicators with the “intended recipient”. But in the “To Avoid” model there is no “intended recipient validation”……Confusion!!!
Encrypt For…..
On the other hand we have millions of businesses, who have a need to be able to identify themselves to their customers, users. Which legitimate businesses don’t want to identify and differentiate themselves from the fake ones!!! Which bank would say, yeah sure i don’t care if my customers can’t identify my website and its ok for them to go to a fake site pretending to be me!!! Which user would say, naaa its ok don’t tell me if the site I am on is the legitimate site or not. Which e-commerce site doesn’t want to establish trust with its visitors!!
With the advent of “To Avoid” use case being promoted using the same indicators for the “Encrypt For” model, confusion is only to be expected. However, I am confident in the intellect and goodwill of the PKI community to enable us all with both use cases without causing harm to user eco-system.
I am ready to take some questions now:
Question: What is the Role of Revocation in all this?
Answer: Two sides of the coin for PKI is to “issue” and to “revoke”. Giving birth to babies and abandoning them is like issuing certificates without having the ability to revoke them. There are many legitimate reasons why revocation is required…remember heartbleed? Technology refresh for example where we moved from SHA1 to SHA2…. or compromised private keys……..or mis-use….and many more….
Value of revocation is not in question, we all believe in it, but implementation of it is. To date there are standards for “Issuance” but not for “Revocation”. To date there are acceptable technologies for “Issuance” but not necessarily for “Revocation”.
CAs (Certification Authorities) have useful knowledge that the OS (operating system), Browser or an IoT device needs. This information is the validity of a certificate. Whether a certificate is valid or not is an important piece of information. This information can be provided at the “issuance”, the fact that you are issuing means that its valid……and after issuance this information can be provided by Revocation checks….to see if its still valid or not………I believe there should be an industry wide Standards for Revocation and innovation to provide scalable, resilient, accessible Revocation infrastructure. Only then can you have the full coin.
Question: Should CAs have the power to knock off sites?
Answer: LOL, I see this written here and there and always puts a smile on my face …:) A CA can only provide few bytes of information……..How will that few bytes of information knock off a site again??
What renders a site that you see is the browser. Browser has the ability to show or not to show you a site. Browser makes a determination and renders the site. CAs are mere information sources to the Browser in this scenario. Its the Browser who have the power to knock off sites, not CAs as both decision making and rendering is done by the Browser.
Question: Why do we have short lived certificates?
Answer: Because there is no standards for Revocation or accepted Revocation infrastructure. Remember, CAs have this valuable information about the validity of a certificate. And remember that you can get this valuable information either at the “Issuance” stage or from “Revocation checks”, if you are doing them. But what if you are not doing revocation checks? Well, then you can ask the CA to issue it frequently ….and you have short lived certs. Because every time the CA issues it, you have the valuable information. The question is, how short lived should a certificate be? 90 days, 1 week, 1 hour? The reality is Operating Systems, Browser and IoT devices need this valuable information about validity of certificates “On demand” and ” in real time”. There is no avoiding that. End result is, we will either build a revocation infrastructure we are all happy with, or we will issue short lived certificates with a life span of 1 day……So the burden will either be on the CAs to build a Revocation infrastructure or the burden will be put on the whole Computing eco-system and enterprises to change/modify their systems to have daily issuance and installations of certificates in their environments…..
I personally believe the burden should be on the CAs to provide an acceptable Revocation infrastructure as this is the responsible thing to do versus forcing the whole enterprise computing eco-system to modify and create a potential vulnerability by adding yet another moving part to an already complex ecosystem…..Oh by the way….doing short lived certificates in IoT has yet to make it to the “Challenging” stage….