Internet.Security

scheme. The X.509 strong authentication is an example of an authentication scheme that utilises digital signatures.

Careful selection and appropriate protection of the prime numbers p and q, of the primitive element g of p and of the private and public components x and y of each key are at the core of security in digital signatures. Therefore, whoever generates these keys and their parameters is a vital concern for security. PCAs are responsible for defining who should generate these numbers.

When generating the key for itself and its CA, each PCA needs to specify the acceptable algorithms used to generate the prime numbers and parameters. For example, a larger p means more security, but requires more computation in the signing and verification steps. Thus, the size of p allows a trade-off between security and performance. Each PCA must

specify the range of p for itself, its CAs and its end users. The range of p is largest for the PCA and smallest for the end user.

Y L One-way hash functions and digital signatureFalgorithms are used to sign certificates

and CRLs. They are used to identify OIDs for public keys contained in a certificate. SHA-1 is the preferred one-way functionMfor use in the Internet PKI. It was developed by the US government for use withAboth the RSA and DSA signature algorithms. However, MD5 is used in other legacy applications, but it is still reasonable to use MD5 to verify existing signatures. RSA andEDSA are the most popular signature algorithms used in the Internet. They combine TRSA with either MD5 or SHA-1 one-way hash functions; DSA is used in conjunction with the SHA-1 one-way hash function. The signature algorithm with the MD5 and RSA encryption algorithm is defined in PKCS#1 (RFC 2437). The signature algorithm with the SHA-1 and RSA encryption algorithms is implemented using the padding and encoding mechanisms also described in PKCS#1 (RFC 2437).

6.3 Functional Roles of PKI Entities

This section describes the functional roles of the whole entities at all levels within the PKI. It also describes how the PAA, PCAs, CAs and ORAs perform.

6.3.1Policy Approval Authority

The PAA is the root of the certificate management infrastructure. This authority is known to all entities at all levels in the PKI and creates the overall guidelines that all users, CAs and subordinate policy-making authorities must follow.

The PAA approves policies established on behalf of subclasses of users or communities of interest. It is also responsible for supervising other policy-making authorities.

Figure 6.3 illustrates the PAA functions and their performances. Each PAA performs the following functions:

•Publishes the PAA’s public key.

•Sets the policies and procedures that entities (PCAs, CAs, ORAs and users) of the infrastructure should follow.

•Sets the policies and procedures, if any, for a new PCA to join the PKI.

Team-Fly®

6.3.2 Policy Certification Authority

PCAs are formed by all entities at the second level of the infrastructure. Each PCA describes the users whom it serves. All PCAs have both policy and certification responsibilities, and must publish their security policies, procedures, legal issues, fees, or any other subjects they may consider necessary. For PCAs, the users may be people who are affiliated to an organisation or part of a specific community, or a non-human entity. All PCA security policies are published and stored on an end user’s local database. Each PCA performs the following functions as illustrated in Figure 6.4.

•Publishes its identification and locality information, such as directory name, e-mail address, postal address, phone number, fax number, etc.

PCA functions

Figure 6.4 Illustration of PCA functions.

ORA functions

Receive certificate revocation requests, verify the validity of the requests, and if valid, send the request to the CA

Figure 6.6 Illustration of ORA functions.

•Delivers the CA’s public key and its predecessor’s public keys as well as the certificate to the user if returned.

•Receives certificate revocation requests, verifies the validity of the requests, and if valid, sends the request to the CA.

6.4 Key Elements for PKI Operations

This section describes operational concepts of the PKI. In order to comprehend the overall PKI operation, one must understand how it conducts its various activities. Each activity is broken down into functional steps. The resources required for each functional step within each activity must be defined. The resources required for an activity are presented in relation to the entities such as User, KG, CA, ORA, PCA or Directory. The steps associated with PKI activities are applied to all PKI relationships: User – CA, User – ORA, ORA – CA, CA – PCA and PCA – PAA.

This section also presents the architectural structures for the PKI certificate management infrastructure. These structures should allow users to establish chains of trust that contain no more than a few certificates in length. The functions and responsibilities of the CAs and PCAs are briefly reviewed and then how the CAs are interconnected to permit establishment of reliable certification paths. Some major activities associated with the PKI operations are presented subsequently.

6.4.1 Hierarchical Tree Structures

Chains of trust follow a strict tree hierarchy with a root CA (PAA or PCA) to which all trust is referenced. Each CA certifies the public keys of its users and the public key of the root CA is distributed to all PKI entities. Thus every entity is linked to the root CA via a unique trust path. Figure 6.7 depicts such a tree structure. A number of hierarchies may be joined together by cross-certifying their root CA directly or using bridge CAs. Figure 6.8 illustrates a bridge-type scheme joining a hierarchical tree structure to a mesh structure.

PAA

(root CA)

Figure 6.7 Hierarchical tree structure.

Figure 6.8 A mixed structure using a bridge CA.

With a mesh structure, entities may be connected via several chains of trust. PGP is a PKI that uses a mesh structure, with every entity acting as their own CA. Gateway structures are new structure appearing in VPN applications. In a gateway structure, each domain is separated and relies on its gateway to provide external PKI services. Figure 6.9 depicts a gateway structure with three cross-certified gateways through which the trust of the network is channelled. Horizontal structures offer improved robustness to penetration by distributing the trust path horizontally. Multiple platform structures can be used to introduce redundancy into a PKI structure and thus reduce risk. The public key of each user is authenticated in each platform. This is a particular advantage with hierarchical structures because it can remove a single point of failure.

6.4.2 Policy-making Authority

Chains of trust are based on appropriate policies at all levels in the infrastructure. Associated with the entire PKI is a policy-establishing authority which will create the overall guidelines and security policies that all users, CAs and subordinate policy-making authorities must follow.

•The PAA has the responsibility of supervising other policy-making authorities. The PAA will approve policies established on behalf of subclasses of users or of communities of interest.

•The PCAs will create policy details that expand or extend the overall PAA policies. Each PCA establishes policy for a single organisation or for a single community of interest. PCAs must publish their security policies, procedures, any legal issues, any fees or any other subjects that they consider necessary.

•The CAs are expected to certify the public key of end users or of other CAs in accordance with PCA and PAA policies. The CA must ensure that all key parameters

Figure 6.9 A gateway structure.

are in the range specified by the PCA. Therefore, the CA either creates key pairs according to the PCA regulations or examines the user-generated keys to ascertain that they satisfy the requirements of the range. A few CAs are associated with PCAs, but the majority are plain CAs at all points in the infrastructure.

•The ORA submits a certificate request on behalf of an authenticated entity. The CA returns the signed certificate or an error message to the ORA. The ORA or certificate holder requests revocation of a certificate to the issuing CA. The CA responds with acceptance or rejection of the revocation request. Certificate Revocation Lists (CRLs) contain all revoked certificates that CAs have issued and have not expired. The CA returns the signed certificate and its certificate or an error message to the end user. The CA posts a new certificate and CRL to the repository.

6.4.3 Cross-certification

Suppose the CA has its private/public-key pair and the X.509 certificate issued by the CA. If a user knows the CA’s public key, then the user can decrypt the certificate with the CA’s public key and verify the X.509 certificate signed by the CA. Thus the user can recover his or her public key contained in the X.509 certificate; the user’s public key is verified as illustrated in Figure 6.10.

hm

E SHA-1 D KPc

USER

Figure 6.10 Certification of the user’s public key.