3 PKI Architectures

3.1.1 There are several models or architectures that PKIs can employ to provide a 'chain of trust' from a public key that is known to be authentic through to a specific user's public key. For instance, when users authenticate themselves to an e-Government application, the application's cryptographic software will verify the user certificate's signature using the public key of the CA that created the certificate. If the CA's key is not listed as a root key, then the certificate containing it will also have to be validated with the public key of the CA that signed that certificate; and so on until a certificate in the 'trust-chain' can be verified with a trusted 'root' key. The validated chain then implies authenticity of all the certificates, including the end-user's one.

Figure 1 - Chain of Trust

3.1.2 There are six broad variations that could be used to form such a chain; each has pros and cons when considered for use in the New Zealand Government context.

3.2 Web-of-Trust Model

3.2.1 The easiest model for a small group to get started with is a Web-of-trust system such as employed by NAI's Pretty Good Privacy (PGP). In this type of system each user creates and signs certificates for the people he or she knows. Therefore, no central infrastructure needs to be developed.

Figure 2 - Web of Trust Model

3.2.2 This model works very well for small groups who have pre-existing relationships, but it doesn't scale well for large groups or where consistency of assurance (e.g. level of authentication required before a certificate is issued) is important. Communication of certificate status to Relying Parties (such as if a certificate is revoked) is also very difficult with this model.

3.3 Single CA Model

3.3.1 A simpler model for larger groups is to assign one person or organisation the role of Certificate Authority. In the Single CA model each person (Subscriber/Relying Party) is provided with the CA's public key in a secure out-of-band manner, and there is only one place to check whether a particular certificate has been revoked. This model is often extended by having Registration Agents (RAs) who are remote from the CA but local to specific user groups, for instance located at each departmental branch office. The RA is responsible for verifying the Subscriber's identity and, if necessary, authorisations, before approving the application for a certificate. They are also often tasked with setting up a preliminary trust relationship between the Subscriber and the CA either through a shared secret or by exchanging public keys.

Figure 3 - Single CA Model

Figure 3 - Single CA Model

3.3.2 In larger or more diverse groups there may be a requirement to have more than one CA. For instance in the commercial arena in New Zealand there are already several potential choices of CA. In this situation there needs to be a capability for subscribers from each CA to be able to inter-operate with those from the other CAs. The remaining models describe various ways to solve this issue.

3.4 Hierarchical Model

3.4.1 The traditional multiple-CA implementations are formed around a very hierarchical structure with a Root CA at the top, one or two layers of CAs below that (i.e. with their public keys in certificates signed by the Root CA) and then Subscribers and RAs under (signed by) them. Each user's most trusted key (the 'root' of any certificate chain they verify as a Relying Party) is the Root CA's public key. This model allows enforcement of policies and standards throughout the infrastructure, producing a higher level of overall assurance than the other multiple-CA models. However, the hierarchical nature may not fit so well with the peer-to-peer business relationships between departments and business in New Zealand and internationally. For instance, if a country is to have one PKI, who should control the Root CA? And how is interoperability achieved with other countries unless we allow one country to control the Root CA for the world? However, in highly structured cultures, such as the military and large corporations, this architecture can work extremely well.

Figure 4 - Hierarchical Model

3.5 Browser Trust-list Model

3.5.1 The most common PKI implementation is that of the Browser Trust-list model - also referred to as the CA list or User-centric model - where each user application has a list of the public keys for all the CAs that user 'trusts'.

Figure 5 - Browser Trust-list Model

3.5.2 This model - implemented in Netscape and Microsoft web browsers - allows each user a great deal of flexibility to add and remove CAs from his or her 'trust list'. However, a malicious party could potentially append a bogus CA certificate into the list and from then on have their bogus user certificates validated by the browser.

3.5.3 The primary concern with this model, however, is that there is no differentiation between a 'strong' PKI and a 'weak' one; for instance most users of VeriSign certificates will not normally look to see which policy (Class 1 to 4) a specific certificate is issued under before they rely on it. Most of the commercial PKIs included in the bundled CA list do not include many of the controls expected of government-approved CAs.

3.5.4 An advantage of this model is that each application can choose to trust a different set of CAs. Given that each application will have a different user base, this is appealing, for example a health sector CA would be likely to trust HealthCert as well as the S.E.E. CAs.

3.5.5 There is emerging support for signed Certificate Trust Lists, providing a standard for secure storage of lists of CAs.

3.6 Policy Trust list model

3.6.1 Our ideal trust list would also let us restrict access based on the policy under which the certificate was issued.

3.6.2 For example, we would like to create a list like this:

CA1 key + policy oid A CA2 key (all certs issued by this CA satisfy our needs) CA3 key + policy oid A CA3 key + policy oid B

3.6.3 With the development of a new standard like Certificate Trust Lists, but also specifying Policy OIDs, we could perhaps also embed other trust lists, e.g.

CA1 key + policy oid A CA2 key Trust list 1 signed by key 4 (e.g. S.E.E. Key list) CA3 key + policy oid A CA3 key + policy oid B

3.6.4 This model gives us great precision over which certificates to trust, and these decisions can be made on a per application basis.

3.6.5 It also means that a CA does not have to run a separate CA for each certificate policy it operates, potentially reducing costs significantly.

3.6.6 However, there is currently no vendor support for filtering on Policy OID despite recommendations to do so in the X.509 V3 Certificate RFC.

3.7 Policy Trust list model with OUs

3.7.1 This is like the Policy Trust list model but instead of using Policy OIDs, we would set a more widely supported certificate field like OU to a Policy OID equivalent, for example "S.E.E. Key v1.5", and configure servers to filter access based on this OU + CAs.

3.7.2 The trust list would look like this:

CA1 key + (OU=S.E.E. Key v1.5) CA2 key CA3 key + (OU=S.E.E. Key v1.5)

3.7.3 This approach doesn't give us the ability to embed other trust lists (refer 3.6.3), but is nonetheless more flexible than the Browser trust list model.

3.7.4 However, using OUs is still a custom configuration. Application software would need to be configured to restrict access, and some application software would require custom development to work at all.

3.7.5 Implementation would usually require the configuration of two parts of an application - that responsible for choosing which certificate to trust for authentication (for the list of CAs), and that responsible for authorising access to the application (for OU filtering). The OU based trust list isn't visible, and would become complex as we add CAs and policies, and so is prone to mis-configuration.

3.7.6 This option is not recommended due to the difficulty in configuration, and that it is not a standard approach.

3.8 Cross-certificate Model

3.8.1 A model that is in effect a compromise between the preceding two models is the Cross-certificate model as used in Entrust's PKI architecture. In this model each CA creates certificates for the CAs that it has verified as of equivalent 'strength' to its own. As in the hierarchical model, each user only has one 'root' public key, but in this model that key is their local CA's key not the key of a central Root CA. The chain of certificates is navigated in the same way, but the view of the structure differs depending on the user's CA.

Figure 6 - Cross-certificate Model

3.8.2 One problem with this model is the difficulty for the user application to determine a certificate chain between users whose CAs do not have a direct cross-certificate link.

3.8.3 This model does confront the issue of "who is the root CA?" (no one / all CAs), allowing CAs to be in peer structures rather than hierarchies, but like the Web Of Trust model, cross certification struggles to produce uniform or deterministic levels of assurance across the whole system.

3.9 Bridge CA Model

3.9.1 Because of the various issues raised with the preceding models, cross-organisational implementations sometimes employ a Bridge CA. For instance, the US Federal Bridge CA will provide a trust bridge (through cross-certificate pairs) between the various Hierarchical and Cross-certificate PKIs being developed by the US Federal Government. This implementation - crossing multiple vendors and models - may end up being highly complex and might require modification of the end-user PKI modules if they are to be capable of finding a trust chain between any two users within the structure. While the US Bridge CA is being developed for technical reasons as much as political ones, the concept of a bridge CA for interoperability between Government, commercial and international domains appears reasonable for many reasons, but is likely to be very complex to work into the end-user cryptographic software.

3.10 Summary

3.10.1 It is suggested that in the New Zealand Government context:

• The PGP model is infeasible.

• The Single-CA model is technically feasible and simple to implement, but may be unpopular for commercial reasons.

• The Browser Trust-list model is available now and works, but is less manageable and less secure in the default configuration currently provided by the major software vendors.

• The Policy Trust list model would be ideal, but there is no application support, and the OU based approach is prone to misconfiguration.

• Both the Hierarchical and Cross-certification models can provide a much higher level of assurance than the Browser Trust-list model, but their suitability depends on the structure and ownership of PKI services in New Zealand, and is not currently supported by the installed base.

• A Bridge CA may or may not be required depending on the models and structures selected by government and business in this country, and our secure interoperability requirements with organisations overseas. However, this model should be avoided if possible, at least until more of the technical interoperability issues have been settled by the major PKI vendors.

The following table summarises the relative strengths and weaknesses of each model.

Trust-List Model		Advantage	Disadvantage
PGP Model		No central infrastructure Agency autonomy Very low initial costs	Doesn't scale well No consistency of authentication process Difficult to keep up to date Users must manage the PKI and need to have in-depth understanding about it
Single CA model		Cheap and simple to implement Simple and fast from a user perspective No interoperability issues Supportedby all PKI enabled applications	No competition All our eggs in one basket
Browser Trust-list Model (recommended)		Easy to implement Very  flexible Supported by all PKI enabled applications Application autonomy over which CAs to trust	Potentially easier to exploit No differentiation of authentication strength between certificates Difficult to manage
Policy Trust List Model		Extremely flexible Excellent differentiation among certificate types Application autonomy over which CAs to trust Potentially lower cost certificates	Not a COTS solution Difficult to manage
Policy Trust List Model with OUs		Extremely flexible Excellent differentiation among certificate types Application autonomy over which CAs to trust Potentially lower cost certificates	Potentially easier to exploit Requires custom configuration Difficult to manage Prone to misconfiguration
Hierarchical Model		Management is structured Potentially strong Minimal interoperability issues	Who holds the Root key? Top-down approach does not fit with departmental management Inflexible
Cross-certification Model		Not hierarchical Reasonably flexible	Interoperability can be difficult User software can have problems with finding a certificate chain The directory may be more critical (to find the certificate chain)
Bridge CA Model		Can link PKIs that use different CA software or from different domains (e.g. NZ and Aust., govt and banking, etc). Can be 'retro-fitted' to existing PKIs	Could be an interoperability nightmare from an implementation and user perspective Not a COTS solution

3.10.2 Of the above, the key contenders are the single CA and the Trust list options.

3.10.3 The architecture recommended for the S.E.E. PKI is a modification of the Browser Trust-list model. In effect, there will be a small number of S.E.E PKI Certification Authorities (one to three). There will be Registration Agents where required - generally at least one at each S.E.E. member agency, or an agent thereof - who will be Subscribers of one or more of the CAs and will pass user registration, revocation and change requests to the CA administrators for processing. Each CA will be autonomous, in that there will be no need for cross-certification. However, each CA will need to agree to comply with the S.E.E PKI Accreditation standards and procedures, so will be linked conceptually through the standards they have in common.

3.10.4 It should be noted that any CA public key approved for S.E.E. PKI use may only be used to issue certificates under the certificate policies approved for S.E.E. PKI (i.e. the CA must agree not to issue lower assurance certificates with that CA key).

3.10.5 In future we may wish to move to the Policy Trust List model if and when there is broad application support for this model. The adoption of the Browser Trust list model will not impede such a move.

3.10.6 Each agency will need to make a risk management decision on which CAs to add to or leave in the trust-list based on their business requirements. This is especially critical for servers. Addition and removal of CAs from the list will require changes to all machines within the S.E.E. This could be done by running a certificate management utility on each machine.

3.10.7 The simplicity of this model from both an implementation and users perspective will ensure that it is simple and fast to deploy and use with the COTS solutions available. The relative disadvantages of this solution will be:

• the difficulty of securing the trust-list;

• the need to add and remove CAs from the list; and

• if the default Trust-lists are retained, the risk of accepting 'weak' authentication from non-S.E.E PKI CAs.

3.10.8 In comparison with some of the PKI initiatives overseas, the S.E.E. PKI will be relatively small (up to 20,000 users). In fact, it is possible that the S.E.E PKI could operate with just a single CA using the model proposed. This would further simplify governance, management and interoperability within the S.E.E environment.

[ Previous | Next ]