- Email: [email protected]
Delegated Certificate Validation:
ISTR 0803.qxd
13/11/2003
15:41
Page 45
Delegated Certificate Validation: A new approach to simplifying PKI and achieving trust interoperability Abstract The trust provided by a PKI system rests on the fact that the digital certificates being used within the infrastructure are authentic and can be relied upon. As such, the process of validating certificates is central to the management of risks within a PKI and for resolving any disputes which may arise later. A major problem is that certificate validation is such a complex process, involving numerous convoluted steps, that implementing it properly has been difficult for application providers. This has hampered support for PKI within end-user application so much so that the full potential of PKI technology is not being realised. This paper shows that by transferring the task of certificate validation from end-user applications to dedicated trust servers, we can simplify the implementation and management of a PKI system. Moreover by adopting a delegate certificate validation approach, the ultimate vision of interoperability between disparate PKI “islands” can also be achieved easily. This has the potential of finally shifting PKI technology beyond closed user-groups to an open, inter-PKI communication environment. Keywords: trust; interoperability; validation
1 Introduction It has long been recognised that PKI can play an important role in the delivery of the essential security mechanisms that are required for an online world, including data integrity, user authentication, secure and scalable key distribution for confidentiality services, digital signatures and associated non-repudiation.
For over a decade, PKI has been making its way steadily across the ‘new technology curve’, a path trod by all new technologies. The late-1990s were days of extreme optimism and hype, leading to everyone clambering to get on the bandwagon. Later, with the fall of technology in general, PKI also slid down the disappointment curve as the hyped expectations were not being met. Although the picture was, and to a lesser degree still is, being painted as bleak for PKI technology, it is nevertheless progressively being embedded into commercial software (e.g. browser, e-mail, workflow, etc) and hardware (e.g. phones, smart-cards, etc). Furthermore, open standards for technical interoperability, as well as legislation to recognise the equivalence of digital signatures to handwritten signatures in legal proceedings, are both in advanced stages of maturity. Putting aside the two extremes views, currently the PKI market is in what is commonly referred to as the ‘reality check’ phase. Whilst most informed analysts believe in the potential of PKI and realise that it is here to stay (until it is either broken or something better comes along), there are still two major and justified criticisms facing the industry: 1. PKI is complex to build, and timeconsuming and expensive to deploy and manage; 2. PKI is only suited to close-user groups (i.e. inter-PKI interoperability is not possible easily). This paper looks at both of these problems in turn and shows how the single new approach of delegated certificate validation has the potential of solving both issues.
2 Complexity problem Digital certificates (in the format of X.509) have become an accepted method for
1363-4127/03/© 2003, Elsevier Ltd
45
Liaquat Khan Liaquat Khan is the technical director for Ascertia, a leading provider of digital signature and real-time certificate validation solutions. Ascertia’s certificate validation solutions include a range of client/server products, which allow a party relying on e-transaction to validate the identity of a signer in real-time. In TrustFinder OCSP, Ascertia provides the latest and most sophisticated OCSP (Online Certificate Status Protocol) server on the market. Ascertia next-generation validation servers include TrustFinder SCVP and TrustFinder XKMS. Ascertia’s signature solutions allow you to apply legalgrade digital signature to any type of document from within popular applications from Microsoft and Adobe. For further information visit www.ascertia.com Previously Liaquat has held senior crypto-related positions with the Global Trust Authority, NatWest Bank, Barclaycard, Baltimore and AdmiralCMG.
ISTR 0803.qxd
13/11/2003
15:41
Page 46
PKI re-visited – current issues and future trends
securely binding the identity of an individual or device to a public key, for the purpose of supporting public key cryptographic operations such as digital signature verification and public key-based encryption. However, prior to using the public key contained in a digital certificate, an application must first determine the authenticity of that digital certificate. Failure to do this properly undermines the security provided by any PKI-based system. It is through validating the certificate that the assertion of the binding made between the identity and the public key in each of the digital certificates can be traced back to a single point of trust (referred to as the trust anchor). So what is involved in determining the trustworthiness of a digital certificate? At a high level it can involve the application checking the following points: • ensuring the certificate was issued by a recognised and pre-configured trust anchor (not necessarily directly, but through a chain of intermediate certificates); • ensuring that each certificate in the path has not been altered since first being issued; • ensuring that each certificate in the path internally contains valid fields and extensions that comply with requirements of PKI standards; • ensuring that each certificate in the path is within its accepted lifetime (i.e. has not expired); • ensuring that each certificate in the path has not been revoked since being issued; • ensuring that each certificate in the path was issued for the intended purpose or application for which it is currently being used. Generally, these (and other checks not mentioned above) are grouped together in three logical steps which encapsulate certificate validation:
46
1. Certificate path building — i.e. building a path of certificates from the signer’s certificate to a certificate authority (CA) certificate which the verifier trusts. 2. Certificate path verification — i.e. checking the signature and other internal fields of each certificate in the path to ensure that they are correct, have not been modified, and comply with standards. 3. Certificate status checking — i.e. ensuring that each certificate in the path is still valid and has not been revoked by the issuing CA. The above operations can be performed entirely by the end-user application, or elements of the above operations can be delegated to trusted servers that are dedicated to these tasks. The next sections explain how certificate validation was handled in a traditional PKI, what the current approach is, and how things are likely to change in the future.
2.1. Certificate validation in a traditional PKI system In a traditional PKI system, the verifier’s PKI client application would need to perform each of the above three certificate validation tasks internally. The certificate status checking step would be performed by the client retrieving a CRL from a repository, as illustrated in figure 1. CRL stands for certificate revocation list, which is basically a signed list identifying all revoked certificates that have not yet expired within a particular domain. CRLs are issued periodically by CAs and posted onto online repositories. PKI client applications can then download these periodically, verify the signature on the CRL to ensure that it is authentic, and then determine whether or not the certificate being relied upon is identified as revoked within the CRL.
Information Security Technical Report. Vol. 8, No. 3
ISTR 0803.qxd
13/11/2003
15:41
Page 47
Liaquat Khan Delegated Certificate Validation
As a result, in a traditional PKI system the client application was required to perform a lot of complex PKI operations to support full certificate validation, making the application bulkier and more expensive to build (often termed ‘fat’ clients). This has led to a situation where either PKI is being completely ignored in applications where it would be useful or PKI and the associated certificate validation checks are being implemented but only partially and, as a result, leaving serious security holes. Another problem with a traditional PKI system is that the client is relying on CRLs, which have the following limitations: • they can become large, and therefore take time to download and process (in a large PKI they can grow to over 1MB in size); • they are periodic, so they do not provide the freshest information on the status of certificates (you could issue them very frequently, but then you will also be forcing users to download potentially large CRLs very frequently); • they do not provide a positive statement that a certificate is ‘valid’; • they do not provide signed evidence that a particular certificate was checked at a particular time and what response was given by the authority responsible for the certificate.
2.2. OCSP: current state-of-the-art The Internet Engineering Task Force (IETF), in its effort to simplify the checking of the revocation status of certificates by PKI client applications, developed the OCSP protocol (online certificate status protocol). With this protocol, a PKI client application no longer needs to download and process CRLs but can rely on a validation authority (VA) to perform revocation status checking on its behalf (see figure 2).
Figure 1: A traditional PKI client. The advantages of a PKI based on OCSP are: • The PKI client application is ‘thinner’, as certificate revocation checking is delegated to the validation authority or VA (i.e. the OCSP server). • OCSP is real-time, so it provides the freshest information on certificate status. • OCSP can provide signed evidence that a particular user checked a particular certificate at a particular time and a particular response was given by the VA. This is vital for dispute-resolution situations. • OCSP can provide a positive response that a particular certificate can be considered to be ‘good’. • OCSP responses only cover the certificates whose status was requested, so they are smaller in size. Currently, this is the most preferred method for certificate status checking, especially for valuable transactions (e.g. the Identrus banking PKI scheme is extensively based on OCSP technology — see www.identrus.com). There are a number of OCSP server implementations in the market, including Ascertia’s TrustFinder OCSP server.
Information Security Technical Report. Vol. 8, No. 3
47
ISTR 0803.qxd
13/11/2003
15:41
Page 48
PKI re-visited – current issues and future trends
considered trustworthy for the particular application at hand. The client application may even just ask for the trust server to return the public key extracted from the validated certificate, if it does not want even to process certificates and just wants to handle raw public keys.
Figure 2: OCSP-based PKI client.
2.3. Delegated certificate validation — the future If one extends this concept further, then a client application should really not need to know anything about what is involved in validating a certificate or even what a certificate is, if we are to really make PKI implementation easier. In such a scenario, the client application should simply ask its trusted server to validate the certificate on its behalf and provide a simple response on whether or not the certificate can be
With this in mind, currently the IETF and W3C (World Wide Web Consortium) are defining standards which transfer all aspects of certificate validation onto a dedicated trust server. These standards are referred to as SCVP (simple certificate validation server) and XKMS (XML key management specifications), respectively. Employing delegated certificate validation would lead to a truly ‘thin’ PKI client (i.e. from a PKI perspective, the actual operations being performed by the client would be minimal; instead, all of these would be delegated to the trust server in the middle, reducing the PKI code required in the client application). This allows a full and secure PKI to be deployed widely to mobile devices such as PDAs, phone and other lightweight clients with limited processing power and memory. Furthermore, this approach saves time and expense in not having to individually bolton full PKI capability within each client application.
3 Simplification summary Figure 4 summarises the traditional environment where, in order to support PKI, the client application needed to have some very sophisticated code embedded locally in order to handle certificate validation and processing. Now with a delegated approach to certificate validation, implemented using, for example, the XKMS protocol, would
Figure 3: Thin PKI client.
48
Information Security Technical Report. Vol. 8, No. 3
ISTR 0803.qxd
13/11/2003
15:41
Page 49
Liaquat Khan Delegated Certificate Validation
make the client application a lot simpler (see figure 5).
4 Trust interoperability problem This section sets out to examine the direction taken by the technology of PKI in resolving the ever-present question ‘How do we interoperate?’. The question of interoperation for PKI was partly, but not entirely, answered by standards bodies. The standards set the boundaries for technical implementations, but they did not resolve entirely the question of trust interoperability. The resolution of this needed considerable legal input to create the environment where there were warranties for users that covered the liability that was likely to arise if things went wrong. Two responses to the challenge inherent in the question ‘How do we interoperate?’ arose in the late 1990s within the financial sector. They arose independently of the other, and their paths only crossed when both were well advanced in their thinking and commitment to each proposition had been forthcoming. Identrus (www.identrus.com) and the Global Trust Authority, or GTA (www.theglobaltrustauthority.org), were born. The one feature on which both agreed was the need for a global trust point. It was this trust point, supported by the architecture and legal framework that formed the linchpin of both propositions. However, is the global trust point approach the best way to realise interoperability? This section will attempt to provide the answer.
4.1. The global point of trust The acceptance of a global point of trust proposition followed the consideration and casting aside of other propositions such as cross-certification between PKIs.
Figure 4: Traditional environment. Cross-certification necessitated the creation of inter-PKI agreements that would have become totally unmanageable, so this was considered not to be a scalable solution. Instead, it was felt that some central point of co-ordination and control was required and that this central point logically would have become the global trust point. This was then perceived as the way to proceed by the PKI industry generally and the financial sector in particular. A global trust point approach is basically, from a technical viewpoint, a PKI hierarchy. There is a root CA, which is the trust anchor, of all relying parties within the scheme (i.e. the final point of trust). Therefore, all certificate chains must end with this global trust point. The number of levels in the PKI hierarchy can vary, but typically is below four. Figure 6 illustrates a typical PKI hierarchy. Using PKI hierarchies to achieve trust interoperability has the following implications: 1. It is clear that there will never be a single PKI hierarchy for the whole world. Even within a well-organised and regulated financial sector, you have a number of global PKI schemes, of which Identrus and GTA are only two examples. So, generally
Information Security Technical Report. Vol. 8, No. 3
49
ISTR 0803.qxd
13/11/2003
15:41
Page 50
PKI re-visited – current issues and future trends
with this for existing PKIs which already have an established user base. There is also the important question of branding for these existing PKIs, which do not want to lose the investments in their own brands for the sake of the global trust point brand.
Figure 5: Simplified PKI clients. speaking, there will eventually be a need to interoperate with other external PKIs, no matter how big and successful your own PKI is or becomes. So, you need a strategy for interoperability. 2. The global trust point must be held in an extremely secure site. Any compromise of this site could lead to all certificates operating in the architecture to be revoked and re-issued. If this arose, then the integrity of the whole proposition would be undermined in the eyes of its subscribers. 3. Every CA will have to issue certificates that are rooted to the global point of trust. Those PKIs that are already operating but want to interoperate with members of the global trust point will have to change their certificates to the new trust point. The embracing of existing PKIs so that they can operate under the global point of trust will require the re-issuance of new certificates (and the re-issuance of new smartcards, if private keys are stored on smartcards for added protection) and is likely to require the introduction of new systems that comply with the new environment of operation. There is a major cost associated
50
Finally, let us examine the business rationale for the global point of trust. This is undeniably a sound proposition, if it encapsulates the current cross-border transaction volumes that take place in hard format at the moment. However, there is a growing awareness that there is a steppingstone approach to this ultimate goal. It is now clear that the first steps are going to be in closed environments, be they in the financial, legal or government sectors to name but three. The next steps are likely to be on a national basis, and only when these early steps have been satisfied will the cross-border activity begin to blossom and the rationale for a global trust point be fully justified. Therefore, a top-down approach — which is what a PKI hierarchy really is — have found it hard to get accepted. What is actually happening is a bottom-up approach, whereby individual PKI islands for specific purposes are being established. These individual PKI islands are typically hierarchical in nature, but could also be in other mesh or bridge architectures. Subsequently, with the development of individual PKI islands, there is then eventually a need to somehow link and interoperate.
4.2. Is there an alternative? There is a powerful alternative to the global trust point. In fairness, one could only have arrived at this conclusion after having explored the more appealing option, namely that of a global point of trust. The alternative is to introduce inter-PKI validation (IPV) of certificates, which would allow all existing and new PKIs to
Information Security Technical Report. Vol. 8, No. 3
ISTR 0803.qxd
13/11/2003
15:41
Page 51
Liaquat Khan Delegated Certificate Validation
interoperate without requiring these PKIs to digitally certify each other, either as part of a hierarchy or through cross-certification in some other approach. The way this works is quite straightforward: there is a central trust server that performs certificate validation on behalf of end-user applications (i.e. relying party applications), thereby shielding them from the complexities of the trust infrastructures involved in the background. In figure 7, PKI A has certified User A by issuing an X.509v3 certificate (PKI A, as illustrated, consists of a CA, an OCSP responder and a LDAP directory). User A then communicates with User B by sending a signed message (labelled ‘1’). User B is certified under PKI B, and will not therefore by itself trust the certificate of User A received as part of the signed message. Normally, this is where interoperability would fail. However, in this case User B is not required to validate the certificate locally. Using the delegated certificate validation approach, User B’s application, on receiving a signed transaction, can make a request (message 2) to its trust server asking it to build a certificate path to a trusted root CA and verify that path and check the revocation status of each certificate in the path. When the trust server receives the request, it will attempt to: (a) Build a certificate path to a trusted root CA; it will do this by retrieving relevant certificates from back-end LDAP directories and checking to see if it can construct a chain to a known root CA. Note that, if this step fails, then the trust server will respond to the certificate-using application that the certificate is ‘not valid’ for the intended purpose.
(b) If step (a) passes successfully, then the trust server will locally verify each certificate in the path. It will check the signature on each certificate, it will check the validity date within each certificate, and it will check all recognised extensions in the certificate to ensure that they are valid. Note that, if this step fails, then the trust sever will again respond that the certificate is ‘not valid’ for the intended purpose. (c) If step (b) also passes successfully, then the trust server will verify the revocation status of each certificate in the path. It will do this by contacting a realtime OCSP responder or retrieving an appropriate CRL from the relevant directory. If all certificates within the path are still considered to be correct (i.e. not revoked), then the trust server will respond to user B (in message 3) that the certificate sent in the original request is ‘valid’. Therefore, when a relying party application receives a certificate, there is no need for it to understand from which back-end PKI it came.
Figure 6: PKI hierarchy.
Information Security Technical Report. Vol. 8, No. 3
51
ISTR 0803.qxd
13/11/2003
15:41
Page 52
PKI re-visited – current issues and future trends
need to be pre-initialised with the public key of just this server but, through this, be able to interoperate with any other PKI (that the trust server considers trustworthy).
5 Benefits of delegated certificate validation
Figure 7: Interoperability. Instead, the application will send the certificate to its trust server to report back on its trustworthiness. With this approach, any number of PKIs can be supported in the background. In this way, the client application can send a certificate to its trust server and ask it to perform a number of interesting checks and return different items, for example: • Build a certificate path with valid certificate and return it to me (as I want to verify it locally). • Build a certificate path and verify it for me; just tell me a simple yes/no on whether to proceed with this transaction. • Build a certificate path and verify it for me; if the certificate is trusted then return me the public key from that certificate, as I can’t process certificates. • Is this certificate acceptable for SSL communication? • Is this certificate acceptable for highvalue funds transfer? Therefore, in the future the client application’s real trust anchor will be the trust server which provides validation information. The client application would
52
The benefits of the delegated certificate validation approach are as follows: • Simpler interoperability than using cross-certification or PKI hierarchies, since no actual certificates need to be issued between the back-end PKIs for them to interoperate. • Incorporation of existing PKIs (the existing PKIs would of course need to be assessed to ensure that they provide adequate security before allowing them to register on the IPV Server). • Ease of management (i.e. the determination of who is part of the club is managed easily by the rules at the trust server, instead of having to issue or revoke certificates). • Centralised policy control (the trust server defines how certificates are validated rather than the end-user, i.e. which extensions are checked and whether to use OCSP, CRLs or some other technology). • Future-proof (end-user applications are future-proofed against advances in PKI technology at the back-end, since they are hidden from this). • Low PKI footprint (end-user applications do not need a lot of PKI code, as most of the tasks involved in certificate validation are performed by the IPV server instead of end-user applications. This means that PKI can be deployed more widely, e.g. on mobile devices). • Greater simplicity and lower cost than having to build full certificate validation logic in each end-user application.
Information Security Technical Report. Vol. 8, No. 3
13/11/2003
15:41
Page 45
Delegated Certificate Validation: A new approach to simplifying PKI and achieving trust interoperability Abstract The trust provided by a PKI system rests on the fact that the digital certificates being used within the infrastructure are authentic and can be relied upon. As such, the process of validating certificates is central to the management of risks within a PKI and for resolving any disputes which may arise later. A major problem is that certificate validation is such a complex process, involving numerous convoluted steps, that implementing it properly has been difficult for application providers. This has hampered support for PKI within end-user application so much so that the full potential of PKI technology is not being realised. This paper shows that by transferring the task of certificate validation from end-user applications to dedicated trust servers, we can simplify the implementation and management of a PKI system. Moreover by adopting a delegate certificate validation approach, the ultimate vision of interoperability between disparate PKI “islands” can also be achieved easily. This has the potential of finally shifting PKI technology beyond closed user-groups to an open, inter-PKI communication environment. Keywords: trust; interoperability; validation
1 Introduction It has long been recognised that PKI can play an important role in the delivery of the essential security mechanisms that are required for an online world, including data integrity, user authentication, secure and scalable key distribution for confidentiality services, digital signatures and associated non-repudiation.
For over a decade, PKI has been making its way steadily across the ‘new technology curve’, a path trod by all new technologies. The late-1990s were days of extreme optimism and hype, leading to everyone clambering to get on the bandwagon. Later, with the fall of technology in general, PKI also slid down the disappointment curve as the hyped expectations were not being met. Although the picture was, and to a lesser degree still is, being painted as bleak for PKI technology, it is nevertheless progressively being embedded into commercial software (e.g. browser, e-mail, workflow, etc) and hardware (e.g. phones, smart-cards, etc). Furthermore, open standards for technical interoperability, as well as legislation to recognise the equivalence of digital signatures to handwritten signatures in legal proceedings, are both in advanced stages of maturity. Putting aside the two extremes views, currently the PKI market is in what is commonly referred to as the ‘reality check’ phase. Whilst most informed analysts believe in the potential of PKI and realise that it is here to stay (until it is either broken or something better comes along), there are still two major and justified criticisms facing the industry: 1. PKI is complex to build, and timeconsuming and expensive to deploy and manage; 2. PKI is only suited to close-user groups (i.e. inter-PKI interoperability is not possible easily). This paper looks at both of these problems in turn and shows how the single new approach of delegated certificate validation has the potential of solving both issues.
2 Complexity problem Digital certificates (in the format of X.509) have become an accepted method for
1363-4127/03/© 2003, Elsevier Ltd
45
Liaquat Khan Liaquat Khan is the technical director for Ascertia, a leading provider of digital signature and real-time certificate validation solutions. Ascertia’s certificate validation solutions include a range of client/server products, which allow a party relying on e-transaction to validate the identity of a signer in real-time. In TrustFinder OCSP, Ascertia provides the latest and most sophisticated OCSP (Online Certificate Status Protocol) server on the market. Ascertia next-generation validation servers include TrustFinder SCVP and TrustFinder XKMS. Ascertia’s signature solutions allow you to apply legalgrade digital signature to any type of document from within popular applications from Microsoft and Adobe. For further information visit www.ascertia.com Previously Liaquat has held senior crypto-related positions with the Global Trust Authority, NatWest Bank, Barclaycard, Baltimore and AdmiralCMG.
ISTR 0803.qxd
13/11/2003
15:41
Page 46
PKI re-visited – current issues and future trends
securely binding the identity of an individual or device to a public key, for the purpose of supporting public key cryptographic operations such as digital signature verification and public key-based encryption. However, prior to using the public key contained in a digital certificate, an application must first determine the authenticity of that digital certificate. Failure to do this properly undermines the security provided by any PKI-based system. It is through validating the certificate that the assertion of the binding made between the identity and the public key in each of the digital certificates can be traced back to a single point of trust (referred to as the trust anchor). So what is involved in determining the trustworthiness of a digital certificate? At a high level it can involve the application checking the following points: • ensuring the certificate was issued by a recognised and pre-configured trust anchor (not necessarily directly, but through a chain of intermediate certificates); • ensuring that each certificate in the path has not been altered since first being issued; • ensuring that each certificate in the path internally contains valid fields and extensions that comply with requirements of PKI standards; • ensuring that each certificate in the path is within its accepted lifetime (i.e. has not expired); • ensuring that each certificate in the path has not been revoked since being issued; • ensuring that each certificate in the path was issued for the intended purpose or application for which it is currently being used. Generally, these (and other checks not mentioned above) are grouped together in three logical steps which encapsulate certificate validation:
46
1. Certificate path building — i.e. building a path of certificates from the signer’s certificate to a certificate authority (CA) certificate which the verifier trusts. 2. Certificate path verification — i.e. checking the signature and other internal fields of each certificate in the path to ensure that they are correct, have not been modified, and comply with standards. 3. Certificate status checking — i.e. ensuring that each certificate in the path is still valid and has not been revoked by the issuing CA. The above operations can be performed entirely by the end-user application, or elements of the above operations can be delegated to trusted servers that are dedicated to these tasks. The next sections explain how certificate validation was handled in a traditional PKI, what the current approach is, and how things are likely to change in the future.
2.1. Certificate validation in a traditional PKI system In a traditional PKI system, the verifier’s PKI client application would need to perform each of the above three certificate validation tasks internally. The certificate status checking step would be performed by the client retrieving a CRL from a repository, as illustrated in figure 1. CRL stands for certificate revocation list, which is basically a signed list identifying all revoked certificates that have not yet expired within a particular domain. CRLs are issued periodically by CAs and posted onto online repositories. PKI client applications can then download these periodically, verify the signature on the CRL to ensure that it is authentic, and then determine whether or not the certificate being relied upon is identified as revoked within the CRL.
Information Security Technical Report. Vol. 8, No. 3
ISTR 0803.qxd
13/11/2003
15:41
Page 47
Liaquat Khan Delegated Certificate Validation
As a result, in a traditional PKI system the client application was required to perform a lot of complex PKI operations to support full certificate validation, making the application bulkier and more expensive to build (often termed ‘fat’ clients). This has led to a situation where either PKI is being completely ignored in applications where it would be useful or PKI and the associated certificate validation checks are being implemented but only partially and, as a result, leaving serious security holes. Another problem with a traditional PKI system is that the client is relying on CRLs, which have the following limitations: • they can become large, and therefore take time to download and process (in a large PKI they can grow to over 1MB in size); • they are periodic, so they do not provide the freshest information on the status of certificates (you could issue them very frequently, but then you will also be forcing users to download potentially large CRLs very frequently); • they do not provide a positive statement that a certificate is ‘valid’; • they do not provide signed evidence that a particular certificate was checked at a particular time and what response was given by the authority responsible for the certificate.
2.2. OCSP: current state-of-the-art The Internet Engineering Task Force (IETF), in its effort to simplify the checking of the revocation status of certificates by PKI client applications, developed the OCSP protocol (online certificate status protocol). With this protocol, a PKI client application no longer needs to download and process CRLs but can rely on a validation authority (VA) to perform revocation status checking on its behalf (see figure 2).
Figure 1: A traditional PKI client. The advantages of a PKI based on OCSP are: • The PKI client application is ‘thinner’, as certificate revocation checking is delegated to the validation authority or VA (i.e. the OCSP server). • OCSP is real-time, so it provides the freshest information on certificate status. • OCSP can provide signed evidence that a particular user checked a particular certificate at a particular time and a particular response was given by the VA. This is vital for dispute-resolution situations. • OCSP can provide a positive response that a particular certificate can be considered to be ‘good’. • OCSP responses only cover the certificates whose status was requested, so they are smaller in size. Currently, this is the most preferred method for certificate status checking, especially for valuable transactions (e.g. the Identrus banking PKI scheme is extensively based on OCSP technology — see www.identrus.com). There are a number of OCSP server implementations in the market, including Ascertia’s TrustFinder OCSP server.
Information Security Technical Report. Vol. 8, No. 3
47
ISTR 0803.qxd
13/11/2003
15:41
Page 48
PKI re-visited – current issues and future trends
considered trustworthy for the particular application at hand. The client application may even just ask for the trust server to return the public key extracted from the validated certificate, if it does not want even to process certificates and just wants to handle raw public keys.
Figure 2: OCSP-based PKI client.
2.3. Delegated certificate validation — the future If one extends this concept further, then a client application should really not need to know anything about what is involved in validating a certificate or even what a certificate is, if we are to really make PKI implementation easier. In such a scenario, the client application should simply ask its trusted server to validate the certificate on its behalf and provide a simple response on whether or not the certificate can be
With this in mind, currently the IETF and W3C (World Wide Web Consortium) are defining standards which transfer all aspects of certificate validation onto a dedicated trust server. These standards are referred to as SCVP (simple certificate validation server) and XKMS (XML key management specifications), respectively. Employing delegated certificate validation would lead to a truly ‘thin’ PKI client (i.e. from a PKI perspective, the actual operations being performed by the client would be minimal; instead, all of these would be delegated to the trust server in the middle, reducing the PKI code required in the client application). This allows a full and secure PKI to be deployed widely to mobile devices such as PDAs, phone and other lightweight clients with limited processing power and memory. Furthermore, this approach saves time and expense in not having to individually bolton full PKI capability within each client application.
3 Simplification summary Figure 4 summarises the traditional environment where, in order to support PKI, the client application needed to have some very sophisticated code embedded locally in order to handle certificate validation and processing. Now with a delegated approach to certificate validation, implemented using, for example, the XKMS protocol, would
Figure 3: Thin PKI client.
48
Information Security Technical Report. Vol. 8, No. 3
ISTR 0803.qxd
13/11/2003
15:41
Page 49
Liaquat Khan Delegated Certificate Validation
make the client application a lot simpler (see figure 5).
4 Trust interoperability problem This section sets out to examine the direction taken by the technology of PKI in resolving the ever-present question ‘How do we interoperate?’. The question of interoperation for PKI was partly, but not entirely, answered by standards bodies. The standards set the boundaries for technical implementations, but they did not resolve entirely the question of trust interoperability. The resolution of this needed considerable legal input to create the environment where there were warranties for users that covered the liability that was likely to arise if things went wrong. Two responses to the challenge inherent in the question ‘How do we interoperate?’ arose in the late 1990s within the financial sector. They arose independently of the other, and their paths only crossed when both were well advanced in their thinking and commitment to each proposition had been forthcoming. Identrus (www.identrus.com) and the Global Trust Authority, or GTA (www.theglobaltrustauthority.org), were born. The one feature on which both agreed was the need for a global trust point. It was this trust point, supported by the architecture and legal framework that formed the linchpin of both propositions. However, is the global trust point approach the best way to realise interoperability? This section will attempt to provide the answer.
4.1. The global point of trust The acceptance of a global point of trust proposition followed the consideration and casting aside of other propositions such as cross-certification between PKIs.
Figure 4: Traditional environment. Cross-certification necessitated the creation of inter-PKI agreements that would have become totally unmanageable, so this was considered not to be a scalable solution. Instead, it was felt that some central point of co-ordination and control was required and that this central point logically would have become the global trust point. This was then perceived as the way to proceed by the PKI industry generally and the financial sector in particular. A global trust point approach is basically, from a technical viewpoint, a PKI hierarchy. There is a root CA, which is the trust anchor, of all relying parties within the scheme (i.e. the final point of trust). Therefore, all certificate chains must end with this global trust point. The number of levels in the PKI hierarchy can vary, but typically is below four. Figure 6 illustrates a typical PKI hierarchy. Using PKI hierarchies to achieve trust interoperability has the following implications: 1. It is clear that there will never be a single PKI hierarchy for the whole world. Even within a well-organised and regulated financial sector, you have a number of global PKI schemes, of which Identrus and GTA are only two examples. So, generally
Information Security Technical Report. Vol. 8, No. 3
49
ISTR 0803.qxd
13/11/2003
15:41
Page 50
PKI re-visited – current issues and future trends
with this for existing PKIs which already have an established user base. There is also the important question of branding for these existing PKIs, which do not want to lose the investments in their own brands for the sake of the global trust point brand.
Figure 5: Simplified PKI clients. speaking, there will eventually be a need to interoperate with other external PKIs, no matter how big and successful your own PKI is or becomes. So, you need a strategy for interoperability. 2. The global trust point must be held in an extremely secure site. Any compromise of this site could lead to all certificates operating in the architecture to be revoked and re-issued. If this arose, then the integrity of the whole proposition would be undermined in the eyes of its subscribers. 3. Every CA will have to issue certificates that are rooted to the global point of trust. Those PKIs that are already operating but want to interoperate with members of the global trust point will have to change their certificates to the new trust point. The embracing of existing PKIs so that they can operate under the global point of trust will require the re-issuance of new certificates (and the re-issuance of new smartcards, if private keys are stored on smartcards for added protection) and is likely to require the introduction of new systems that comply with the new environment of operation. There is a major cost associated
50
Finally, let us examine the business rationale for the global point of trust. This is undeniably a sound proposition, if it encapsulates the current cross-border transaction volumes that take place in hard format at the moment. However, there is a growing awareness that there is a steppingstone approach to this ultimate goal. It is now clear that the first steps are going to be in closed environments, be they in the financial, legal or government sectors to name but three. The next steps are likely to be on a national basis, and only when these early steps have been satisfied will the cross-border activity begin to blossom and the rationale for a global trust point be fully justified. Therefore, a top-down approach — which is what a PKI hierarchy really is — have found it hard to get accepted. What is actually happening is a bottom-up approach, whereby individual PKI islands for specific purposes are being established. These individual PKI islands are typically hierarchical in nature, but could also be in other mesh or bridge architectures. Subsequently, with the development of individual PKI islands, there is then eventually a need to somehow link and interoperate.
4.2. Is there an alternative? There is a powerful alternative to the global trust point. In fairness, one could only have arrived at this conclusion after having explored the more appealing option, namely that of a global point of trust. The alternative is to introduce inter-PKI validation (IPV) of certificates, which would allow all existing and new PKIs to
Information Security Technical Report. Vol. 8, No. 3
ISTR 0803.qxd
13/11/2003
15:41
Page 51
Liaquat Khan Delegated Certificate Validation
interoperate without requiring these PKIs to digitally certify each other, either as part of a hierarchy or through cross-certification in some other approach. The way this works is quite straightforward: there is a central trust server that performs certificate validation on behalf of end-user applications (i.e. relying party applications), thereby shielding them from the complexities of the trust infrastructures involved in the background. In figure 7, PKI A has certified User A by issuing an X.509v3 certificate (PKI A, as illustrated, consists of a CA, an OCSP responder and a LDAP directory). User A then communicates with User B by sending a signed message (labelled ‘1’). User B is certified under PKI B, and will not therefore by itself trust the certificate of User A received as part of the signed message. Normally, this is where interoperability would fail. However, in this case User B is not required to validate the certificate locally. Using the delegated certificate validation approach, User B’s application, on receiving a signed transaction, can make a request (message 2) to its trust server asking it to build a certificate path to a trusted root CA and verify that path and check the revocation status of each certificate in the path. When the trust server receives the request, it will attempt to: (a) Build a certificate path to a trusted root CA; it will do this by retrieving relevant certificates from back-end LDAP directories and checking to see if it can construct a chain to a known root CA. Note that, if this step fails, then the trust server will respond to the certificate-using application that the certificate is ‘not valid’ for the intended purpose.
(b) If step (a) passes successfully, then the trust server will locally verify each certificate in the path. It will check the signature on each certificate, it will check the validity date within each certificate, and it will check all recognised extensions in the certificate to ensure that they are valid. Note that, if this step fails, then the trust sever will again respond that the certificate is ‘not valid’ for the intended purpose. (c) If step (b) also passes successfully, then the trust server will verify the revocation status of each certificate in the path. It will do this by contacting a realtime OCSP responder or retrieving an appropriate CRL from the relevant directory. If all certificates within the path are still considered to be correct (i.e. not revoked), then the trust server will respond to user B (in message 3) that the certificate sent in the original request is ‘valid’. Therefore, when a relying party application receives a certificate, there is no need for it to understand from which back-end PKI it came.
Figure 6: PKI hierarchy.
Information Security Technical Report. Vol. 8, No. 3
51
ISTR 0803.qxd
13/11/2003
15:41
Page 52
PKI re-visited – current issues and future trends
need to be pre-initialised with the public key of just this server but, through this, be able to interoperate with any other PKI (that the trust server considers trustworthy).
5 Benefits of delegated certificate validation
Figure 7: Interoperability. Instead, the application will send the certificate to its trust server to report back on its trustworthiness. With this approach, any number of PKIs can be supported in the background. In this way, the client application can send a certificate to its trust server and ask it to perform a number of interesting checks and return different items, for example: • Build a certificate path with valid certificate and return it to me (as I want to verify it locally). • Build a certificate path and verify it for me; just tell me a simple yes/no on whether to proceed with this transaction. • Build a certificate path and verify it for me; if the certificate is trusted then return me the public key from that certificate, as I can’t process certificates. • Is this certificate acceptable for SSL communication? • Is this certificate acceptable for highvalue funds transfer? Therefore, in the future the client application’s real trust anchor will be the trust server which provides validation information. The client application would
52
The benefits of the delegated certificate validation approach are as follows: • Simpler interoperability than using cross-certification or PKI hierarchies, since no actual certificates need to be issued between the back-end PKIs for them to interoperate. • Incorporation of existing PKIs (the existing PKIs would of course need to be assessed to ensure that they provide adequate security before allowing them to register on the IPV Server). • Ease of management (i.e. the determination of who is part of the club is managed easily by the rules at the trust server, instead of having to issue or revoke certificates). • Centralised policy control (the trust server defines how certificates are validated rather than the end-user, i.e. which extensions are checked and whether to use OCSP, CRLs or some other technology). • Future-proof (end-user applications are future-proofed against advances in PKI technology at the back-end, since they are hidden from this). • Low PKI footprint (end-user applications do not need a lot of PKI code, as most of the tasks involved in certificate validation are performed by the IPV server instead of end-user applications. This means that PKI can be deployed more widely, e.g. on mobile devices). • Greater simplicity and lower cost than having to build full certificate validation logic in each end-user application.
Information Security Technical Report. Vol. 8, No. 3