Since the beginning of the COVID-19 pandemic, the user base of eIDAS trust services has expanded beyond expectations. This is a very positive tendency towards achieving goals such as paperless administration or contracting, however, people who have just switched to handle their business electronically, may be very confused about it. No wonder; the world of public key infrastructures is not an easy one to understand. The main concern is that there are so many entities that it can get very difficult to follow and may be even more difficult to determine who to trust. This problem is not entirely a new one, in fact, it is present since the beginning, thus there were great efforts to resolve it in standards, recommendations and best practices. Sadly, there is no intergalactic PKI authority, which regulates all aspects of trust services in a single framework, so we have to rely on the work of around a dozen organizations. This post attempts to clarify these relations and the validation procedures of certificates.
First, if one is not familiar with how a PKI works, here is a quick rundown of public key certificates: these are based on public key cryptography, where a user has a keypair of a public and a private key. A digital certificate is used in order to prove that a given public key is owned by the person or entity specified in it. These certificates are issued by so-called certification authorities (CAs) following a long procedure of validation to determine if the requester can be the subject of the certificate. This is not confusing at all, but let's add that end entities are not the sole holders of certificates; for CAs, the assurance of their authenticity is even more important. If we are talking about intermediate CAs, their certificates are issued by other CAs, but if the CA in question has no entity above it in the hierarchy (root CA), its certificate is either self-issued or a cross-certificate issued by an other root.
It is a common misconception that root CAs are always trust anchors (which means that the trust in them is assumed and not derived; they are very important in the process of validation, because valid certificate paths begin with a trust anchor-issued certificate). It may be a bad practice (in the EU it certainly is) if a CA includes the recommendation of full chain validation in their policies, meaning that relying parties should validate the certificate chain up to a self-signed root certificate. This is not an exact requirement in any widely used legal framework; what is accepted as a trust anchor can differ very widely. RFC 5280, which describes certification path validation processes, states that "The selection of a trust anchor is a matter of policy: it could be the top CA in a hierarchical PKI, the CA that issued the verifier's own certificate(s), or any other CA in a network PKI." So, basically, it is up to the relying party, how it performs the validation, so it can vary among different applications.
Luckily, in Europe, it is easier for us to determine, because the European Union’s member states’ competent authorities are obliged to publish the list of regulated qualified trust service providers and their certificates, these datasets are called trusted lists. That is clear, but what if a malicious actor published a „trusted list” which contained all of its certificates made for their phishing websites? How does one authenticate a trusted list?
First, all trusted lists are digitally signed. But even if this does not convince us, the European Union even provides further guarantee, because it maintains a list of these trusted lists, which was originally called „compiled list” – although, by following the terms’ common usage, now referred to as LOTL (short for list of trusted lists – no wonder why); this list is in a machine-processable XML form and its authenticity is even more guaranteed than any trusted list’s. It is as well assured by a digital signature with a certificate which is also published in the Official Journal of the European Union (the current one in 2019/C 276/01). For more assurance, in case the LOTL changes, the LOTL itself contains the publications of those modifications of the signing certificates’ or the LOTL’s location; instances of this mechanism are called „pivot LOTLs”; the list of those publications are contained in the SchemeInformationURI tag of the current LOTL.
So, summed up, trusted lists are very secure, so it is no wonder why relevant standards and legal frameworks require the use of them to specify trust anchors. To verify a trusted list, one can use the so-called list of trusted lists, which is machine processable so it can even be included in software applications.
Sources / Further reading:
© 2020 Microsec Ltd. | Company registration number: 01-10-047218 | Tax number: 23584497-2-41