 Welcome to this third part on our lecture on public key infrastructures. This time we're going to talk about X549. Why even? I mentioned X549 as an old standard, but it is used in fairly modern technology as well. In particular, in transport layer security or the called TLS. TLS is a backbone protocol for securing many other protocols. Some VPNs build on it. Some email protocols can be secured with it, but most importantly, HTTP is commonly secured with TLS, resulting in HTTPS. And that is used as the protocol for the worldwide web. TLS was actually born as secure sockets layer. In the early 1990s, it was in version three that it was finally found secure or at least reasonably secure. And that served as a blueprint for the definition of TLS in 1999 by the IETF, the Internet Engineering Task Force. TLS works as a layer between the transport layer TCP, which commonly on the Internet itself runs in IP and the application layer. For us, most of interesting, most of most interestingly HTTP. TLS has a few goals, authentication, confidentiality and integrity. To achieve authentication, it employs X549 certificates. The origins of X549 are interesting in themselves. It is actually a really old standard part of the ITU International Telecommunication Union of X500 standards. The idea there was we have a global directory and CAs and their sub-CAs are going to be responsible for controlling access to sub-trees in our global directory. All information would be stored in a giant tree and these entities would be able to control access. There was a strict naming discipline. However, the entire standard X500 never saw much deployment. But one standard was reused by the IETF and that was X549. In particular, to issue certificates for domain names and bind them to public keys so you can authenticate a domain that you are connecting to. The concept of a tree was completely given up by the IETF. It's not mentioned anywhere for the WebPKI and they did not have a global CA, but they pursued the concept of a forest of CAs that are equal. Any CA can issue for any domain. Governance followed quite late. People used the WebPKI years before serious attempts were made to regulate how exactly and under which circumstances certificates should be issued for domain names and which kind of verification should be applied. In the last 10 years in particular, however, we have seen quite a little bit of progress there. This here is the elementary structure of an X549 certificate. Still simplified because you can do quite a lot with it and here it already appears in version 3, which is the most common one today. In gray, you find the fields that are the most important for a certificate. You have the issuer, you have a subject, you have a public key, and you have a signature by the issuer on the entire thing. I have added a little bit more and I have also marked in gray the expiry date called not after an X549 because a certificate should not be used after a certain expiry date. The idea being it is safer to replace your certificates at regular but relatively long time intervals. There's a version number, of course, there's a serial number, the definition of the algorithms used in particular signature algorithm, but also the algorithm used for the public key. There's also a date before which the certificate may not be used called not before, indicating a total validity period. And then you have a few things that are used in terms of extending the certificate. You can have a flag, for example, indicating that the certificate is meant to represent a CA. Then there's a thing called extended validation EV, which we're going to talk about later, and CILs, which we're also going to talk about even later. The public key is stored in a data structure that's called subject public key info. If you want to extract it from the certificate, that's the data structure you are looking for. Now, recall what I said. In practice, we have many global CAs on the web, PKI, and we have root starts and it is these that I would like to have a little bit closer look at now. I have marked them here in red in terms of the root certificates that can be stored in a root store, right? Root certificates are, in essence, the anchor points, the roots of the forest of trees that we spoke about earlier. Root stores hold root certificates and these are the certificates of trusted CAs. Trusted means they are trusted to issue certificates to the correct entities. In other words, they apply a certain verification process, which is assumed to be practical and secure and reach its goal of identifying the correct entity. Every application that uses X549 in practice must have a root store. Root stores are actually included in every operating system that you are likely to encounter in particular windows, operating systems by Apple, and various Linux versions. But browsers can also have root stores. For example, Mozilla Firefox to this day has its own root store, whereas other browsers make use of the operating systems root store. That has certain implications. For example, every vendor has their own process to determine if CA should be added to the root store or not. By extension, by the way, this means you are trusting that your vendor is making the right choices, which CAs to include and which not. What is this based on? Well, a CA has to write a so-called certification policy statement and send it to the vendor, and then it's going to be assessed. That document is not exactly technical. It is more of a legal nature. It describes which audits need to take place, at which intervals, how data is stored in particular keys, how it is kept secure, etc. And against the background of this CPS, an assessment is made, and a CA is allowed to enter the root store and be shipped or not. In the case of Mozilla, by the way, this is a relatively open discussion forum where people have a look at these CPSs. And these people are quite good. They are normally experts in that field, but there are very few. However, if you choose to do it, you can easily find the discussion forum or ask us, and you can have a look at the discussions that happen there yourself. In the case of most commercial vendors, in particular Microsoft and Apple, no such open forum exists. There's little to no openness. And if you want, as a little practice, you can have a look at the Mozilla root store versus that of Microsoft or Apple. What about the intermediate certificates I mentioned earlier? I have marked them here in red. But see how they flow down the chains. Everything marked with an I is an intermediate certificate. And they can be chained again, or as in the case of E1 and E2 here on the left, they can issue and toast certificates. Now, intermediate certificates are part of a certificate chain, but they are neither root nor entity certificates in the tree. There are two primary reasons why you would even want to use intermediate certificates. Sometimes you would like to delegate your signing authority in essence, create a sub-CA. Allow me to go one slide back. Could, for example, implement I5 as a sub-CA that is not in the root store, but acts as a subordinate CA of, by extension, the CA that has R1. Also note, by the way, here the blue marks that this CA operates both a root certificate and an intermediate certificate. We'll have a look at that. Now, if you have sub-CA's, subordinate CA's, modern governance rules require you to disclose this and add certain limitations before your CA can be added to the root store. But this was not the case until roughly 2012. A further reason to use an intermediate certificate is to protect your main root certificate. That's the case I was referring to when the intermediate certificate is operated by the same organization as the CA. You can get an advantage out of this. You can take the private key for your root certificate offline and keep it in a secure location. Let's go one step back again. The private key of this root certificate, R1, can be kept in a secure location and the public key, of course, can still be distributed to anyone, everyone. In particular, shipped in browser root stores or operating system root stores. For your day-to-day operations, the online operations when you're issuing certificates, well, you simply do that now using the private key of your intermediate certificate. In other words, you are issuing from your intermediate certificate. That has an advantage. It's relatively easy to replace intermediate certificate in case of a compromise of that certificate's private key, the private key that belongs to it, or cryptographic breakthroughs that made an attack successful. There are a few other reasons why you would do this, but these are the two ones that you should definitely keep in mind. However, intermediate certificates are not a free lunch. They do have the same signing authority as the root certificates unless restricted. As I said, originally, no technical restrictions actually existed concerning what they can sign. Or I should be more precise maybe and say they existed in the standard but were ignored. Today, they are used increasingly and more often. One of the people actually showed that it is necessary. One thing that takes place commonly is now, if you have an intermediate certificate, in particular, if it represents a sub-CA, you only allow it to sign certain domains. For example, by saying you may only certify domains in the .nl top level domain of the domain name system. You can also say chains must not be longer than a certain value and integer value. Don't forget one thing, however, that restriction must be supported and correctly interpreted by the client. It is no use if the client who relies on the intermediate certificate and the certificate that has been issued from it to state the correct information, but does not itself verify it. Further use that you should be aware of, and this is a little bit where people argue, is sometimes organizations have so-called SSL proxies. That is the term at least under which you can find them. The goal is to monitor the traffic, the network traffic of your employees. And you can of course protest at the idea of monitoring people. However, there are a few legitimate cases. For example, think of industrial espionage. Sometimes you do run a company that has secrets. And in such cases, you don't really want the secrets to escape and you would like to sound an alarm as soon as you become suspicious. And in that case, you would like to inspect encrypted traffic. What you do in such a case is you get yourself a sub-CA that by extension by the intermediate certificate is linked to the root store. And on the fly, it can issue and entity certificates that in essence stage a classic man in the middle or person in the middle attack a transparent rewriting of certificate chains happening right in your proxy. And that proxy is normally situated on your network border. Okay. Now, this has been done. It means, however, that the holder of the sub-CA is suddenly as powerful as all CAs in the root store. Since the first CA actually made it public that they support such things, most vendors today has actually taken to forbidding the practice. Still, that is something that can be done. Further use of intermediate certificates that's also thrown upon quite a little bit is called cross-signing. Have a look at this figure here. We have root certificates R1 and R2 and they belong to different CAs, CA2 and CA1. And let's say they are included in the same root store that I have marked in green. So far, no big problem. We have one interesting pass here from I1, the intermediate certificate. There is another delegation here to I4, which is actually a certificate that is operated by CA2, meaning that CA2 has the private key for it. Further and host entity certificates have been issued. Now, for a moment, imagine this was not the same root store. Imagine that the root store was split here and one root store were here and the other root store were here. What would be the effect? The effect of cross-signing would be exactly what I have just described as a single root store here in green. Cross-signing can inadvertently link two root stores, even though you did not actually want that. And the problem is you might not be aware of the existence of such cross-signed certificates. They can be issued without you, the vendor of the root store, even knowing. What you really have here is a special case of an intermediate certificate. It turns your forest into a directed acyclic graph. Now, again, sometimes you want that, but these cases are rare. You could, for example, have a business-to-business model where your root store is not meant for general browsing of the web and connecting to domains securely, but just to do business between two companies. In that case, you could actually have the companies cooperate by cross-signing each other and then design business processes to make use of that. However, for the worldwide web, it completely breaks our root store model. Again, because the cross-signing essentially links two different root stores without anyone at all being aware of it, except, of course, for the two participating CAs. This supports the control of the root store vendor, and it means that governance, external governance, becomes very, very important. However, unfortunately in the past, such cross-signing has happened without disclosure. What happens if a CA is actually not in your root store, but you encounter it in a TLS connection? That is the root cause for a famous error message. I'm showing you here a little picture of an older one where it says your connection is not secure. In essence, if your browser, for example, does not recognize the root certificate because it's not in the root store, it is going to tell you that it cannot verify the authenticity of the connection, and hence it calls the connection not secure. Now, what about this governance that I am talking about? In practice, the last 10 to 15 years, forums have emerged that take the steering role in the governance of certificate issuance. And the most important one is probably the CA browser forum where CAs and browsers work together to agree on the steps to execute to verify the identity of a certain entity that wishes to be certified. At present, there are three issuance models that are accepted. The first two are also already deployed and the other one is still a little bit evolving. Now, historically, the middle one extended validation was the one defined first, but we go through them in a slightly different order because domain validation is actually the most common. This is a simple form of algorithmic governance in essence prescribing that you must validate the ownership of a domain before you issue a certificate to the person or the entity who claims to own the domain. And this is done by technical means. This is an example by email because you assume that only the owner of a domain can receive email for it. It can be done by placing a token on the web server to demonstrate that you can control the web server on that domain. And it can also, by the way, be done by the DNS, which is relatively new standard. The second concept that uses this is let's encrypt, which is also a free and mostly automated CA that I highly recommend you should check out. The second concept is the most expensive one is called extended validation. Interestingly, it is also the one that has turned out to be not particularly popular. And it is now in decline. You have a strong requirement for legal documentation of the identity that you're talking about. In other words, you really must present legal documents that certify that you are who you claim to be. The entire model is actually a little bit disputed. I mentioned it is in decline. The reason being, it is disputed how useful it really is for the users of the web. Maybe in a few years, I will report that extended validation is no longer in use. It is certainly currently under pressure. Finally, there is a mid middle kind of thing that is called organizational validation. It's between domain validation extended validation and the steps to verify my identity are still evolving. That concludes our lecture on X549.