Digital Certificate Operation in a Complex Environment
navigation search
search query:

The DCOCE PKI Architecture and Requirements

4. Architecture and Procedures

4.1. User applying for a certificate

4.1.1. Introduction

To request a new certificate, a user first has to create a new key pair. The public key is sent together with her personal information to the central RA System (cRAS - see below). This step can be performed in two ways:.

  • By sending a PKCS#10 certificate request (Microsoft) or
  • By sending a SPKAC request (Netscape etc.).

The cRAS holds the request until an RA has approved it and the attributes that it contains. Then the certificate is created and signed by the CA and sent back to the user via the cRAS. The user can opt to store the certificate and private key (in an encrypted, secure form) in the LICS as well, in case she needs to move to a different machine and still use her certificate for authentication, later. Users who do not wish to use the LICS or who have generated a certificate/key pair from a secure device, such as a smart card or USB device with 'crypto chip', can choose not to use the LICS.

The investigations of the DCOCE team resulted in the proposal of two main RA procedures. These were due to the need for different initial user registration procedures in different types of departments or colleges. Some organisational units (OUs) are able to process the necessary data about new starters beforehand and to send them letters that contain the URL and a few instructions regarding how to apply for their certificates. Some OUs will not be able to do this and the RAs will enter the new starter's details as he stands in front of them. Therefore, the initial few steps differ in each case, although both have components in common. The latter option may involve more work for the RA, but this is a procedure that our architecture must take into account.

                 Illustrative figure showing the registration process for obtaining
                 a certificate.

Figure 4.1 Applying for the first certificate - part 1: Certificate request and the RA

Figure 4.1. (above) is a summary of the certificate request and RA procedures. Figure 4.2 continues on from this diagram and outlines the procedures with respect to the certification authority (CA) and includes the options of storing the certificate and private key in the LICS (see below).

4.1.2. Users with multiple 'identities'

A good public key infrastructure PKI should attempt to have one authentication token (a personal digital certificate) and leave multiple roles to a sophisticated authorization system. However, there are some 'real world' challenges that serve to constrain this theoretical advantage. For example, a user who works part time in the Department of Physics may also be studying at a College. Only one organisational unit can be placed on a certificate, but the user clearly has two roles. We believe that a higher education PKI will often have to tie identity to organisational unit. This is certainly the case at Oxford University. The problem is compounded by devolved RAs being unable to 'vouch' for the attributes delivered due to the membership of an unrelated organisational unit. For these reasons, we find it necessary to issue more than one certificate to the same individual in certain cases.

The cases of the same individuals having multiple roles is relatively uncommon, but by no means rare. Our proposed solution can accommodate this technically. However, the cost is probably that end users may have to handle the complexity of having multiple certificates. Where the LICS is to be used, the encrypted container will house all of the users certificates.

4.1.3. Initial user interface and certificate request Option one: user has letter/instruction from RA

Where it is possible that the RA has prior knowledge of the new starter and is able to send a letter or set of instructions beforehand, the procedures are as follows. The technical shorthand for this approach is the request first procedure.

The RA sends a letter to the new starter, encouraging her to apply for a digital certificate from a computer where she will usually be based. The letter contains the URLthat should be used and very few instructions. Before visiting the RA, the user connects to that URL, with her preferred web browser and fills in her details via an HTML form and makes a certificate request as set out in the Common Procedures section below.

The user then visits her local RA and is physically authenticated using a photo ID and/or employing the usual registration procedures for new starters to the organisational unit. The RA marries up the user to the request that is lodged with the cRAS and checks the name, organisational unit and any other attributes that are included with the request. Where the cRAS database is not fully integrated with the institution's directory service, a reconciliation is made between the name given alongside the certificate request and the institution's data held in the directory service. This may mean that it would be efficient for the RA to be able to amend the centrally-held data if they are found to be inaccurate. *

* As noted above, the DCOCE project employed a discrete Pseudonyms Database but in a production system the data would be held within the institutional directory service and therefore discrepancies in data may present at this stage.

If the user has made a mistake (e.g. by selecting a wrong 'status'), the RA should be able to correct the information at this stage. If the request is valid, the user is whom she appears to be and is truly affiliated with the organisational unit, then the RA asserts to the cRAS that the request should be processed (and a flag is set in the relevant database). From here on, the procedures are as outlined in 4.1.4, below and onwards. Option two: user visits the RA before issuing the certificate request

In many cases the user will visit the RA as part of his initial starting or registration procedure. In such cases, the RA can verify the user directly before he has made his certificate request (from the computer). Thus, the user is physically authenticated using a photo ID and/or employing the usual registration procedures for new starters to the organisational unit. He is given instructions encouraging him to apply for a digital certificate from a computer where he will usually be based. The letter contains the URL that should be used and very few instructions. The letter also includes a 9 digit code that must be supplied when he applies for the certificate. The technical shorthand for this approach is the 'RA first' procedure request or (pre-authentication).

The user applies for the certificate in the same way as outlined in the paragraphs within the Common Procedures section below. The only exception to those procedures is that he is prompted to enter his nine digit code. The personal details (name, status etc.) are presented to him and cannot be changed. (If the user considers that any of the details in the application are wrong, then he can make an application as per the method outlined in Option one and visit his RA again.

If the pre-authenticated request is valid, then a flag is set in the relevant database within the cRAS. There is no need for the further attentions of a RA. From here on, the procedures are as outlined in the The central Registration Authority and multiple RAs section below and onwards. Certificate request procedures in common to options one and two

During the on-line application process the following details must be supplied, either by the user (Option one) or by the RA (later checked by the user, Option two).

  • First name
  • Last name
  • Email address (optional)
  • Date of Birth
  • Status (Staff/student etc.)
  • Affiliation - College/Department etc. (Organisational Unit)

The user indicates whether she is going to employ a hardware token or software (browser or operating system) to generate her key pair. (This is phrased in a more user-friendly way). In addition, at this time, she is presented with the option of using the LICS to save an encrypted backup of her private key and certificate*. Once all details in the form have been completed, she submits the request and a certificate request is generated (in a variety of formats depending upon the browser). For those users who opted to use the LICS, this process is mediated by a Java applet.

This procedure is reliant upon the existence of a Java Virtual Machine installation and this can therefore be a constraint for some users. The Java version is tested and users are sometimes encouraged to update the Java installation. If the user cannot make use of Java, then she can still apply for a certificate. However, no backup will be possible (and therefore it can be a more technically challenging task to use their certificate in different places or to re-install their certificate after a desktop system change).

If using the applet, a short test of the quality of the pass phrase is undertaken at this stage, and a warning given if the string is not of sufficient quality (i.e. not containing mixed case and non alphanumeric characters etc.). This ensures that good encryption is used for the encrypted private keys in the LICS.

The request is then stored at the cRAS. For those using the applet and the LICS, a copy of the encrypted private key is also stored within the cRAS. The applet ensures that the private key cannot be obtained without the pass phrase, even by a sysadmin working on the LICS/cRAS.

Upon arrival at the cRAS, a Distinguished Name (DN)is created as part of the request. The Subject Name field of the DN is populated with a short name that reflects their organisational unit, followed by a random number. The unique DN is stored in the Pseudonyms Database. *

* The Pseudonyms Database was part of the cRAS in the DCOCE pilot. However, as noted earlier, this database should be integrated with a directory service in production.

For those users storing their private key in the browser or operating system key store, the browser/operating system's procedure will probably prompt for a pass phrase with which to protect the key store. The user will already have seen some text informing her of how to create a good pass phrase. She will also be aware that the security of the pass phrase will be tested later. (Note that a pass phrase may already be in place, as the user may already have personal digital certificates). The user is encouraged to type a reminder for the pass phrase on the screen. The user can then print out a summary that includes the pass phrase reminder. The reminder is stored in the cRAS in case the user forgets the pass phrase in future.

4.1.4. The central Registration Authority and multiple RAs

Many Registration Authorities (RAs) exist in this architecture, but there is one central point to which requests are made, before they are passed on to the Certification Authority (CA). This central point is under the control of the central Registration Authority - where logs and audits are kept/actioned and from where the devolution to the actual (local to the user) RAs takes place. The server(s) or holding point for certificate requests (and their signed returns) is therefore referred-to as the central Registration Authority System (which also includes other functionality).

The cRAS receives the user's request along with her supporting information (as outlined above). As outlined, the user's local RA approves her request, as long as she has been positively verified and her Oxford University attributes are valid. At the same time information, including the pseudonymous Subject Name, is added to her record in the organisation's directory service*, thereby creating a 'mapping' between her unique but unintelligible Subject Name and a real, traceable identity. A flag is set next to the record in the cRAS so that it can be passed to the CA in the next 'batch' so that the certificate may be issued (see below).

* Again, the DCOCE project pseudonyms database and cRAS was not integrated with the 'Oxford LDAP' (Directory Service) as they should be if this system were to come into production for the majority of users at the institution.

There may be a delay of several hours before the CA creates (and signs) the digital certificate.

Note that users may apply for the differing types of certificate: authentication, signing and encryption and the RA may have to process each. We propose that, if a PKI were to support signing and encryption certificates, then these could be applied for using an authentication certificate (no physical authentication step required)**.

**As noted in the aims section, above, the DCOCE project only sought to build a system of issuing and using authentication certificates.

4.1.5. The Certification Authority (CA)

The CA 'piece' is designed to be technically independent of the rest of the architecture. Therefore, the CA could be any commercial provider or independent organisation that respects the Certificate Policy that is implicitly described by these registration procedures.

Simply, the CA trusts that the RAs have followed the correct procedures and will sign any request supported by the RAs.

There are a variety of ways of doing this, and each external CA will have its preferences. The CA for the DCOCE project received requests in batches from the cRAS and these were processed and returned to the cRAS in a few seconds. Where appropriate, the cRAS can email the user to indicate that the certificate is ready for collection.

Figure 4.2. below shows the final stages of the certificate request, including the procedures for storing the certificate in the LICS (see the LICS section below).

                 Illustrative figure showing the registration process for obtaining
                 a certificate.

Figure 4.2. Summary of certificate download and LICS procedure

4.1.6. The user receives the signed certificate

This stage has two possibilities: a manual (non-Java) download to a software key store or secure hardware device, and a Java-assisted similar download where the user is making use of the LICS. In both methods, the user will have either received an email containing the URL of the certificate container to download and/or will have a code to enter to download the certificate. The user thus visits the certificate issuing web site and either goes straight to the certificate download or enters the code and initiates the certificate download process. Manual download - no backup in the LICS

The user must do this from the same machine using the same browser from which the request was made. The signed certificate is downloaded from the cRAS and is installed in her key store in her operating system or within her browser software or on her secure hardware device.

If this 'self management' option is chosen and a hardware device is not being employed, the browser's own process for importing the certificate is invoked (which will usually prompt for the pass phrase) and the registration and certificate issuing processes are thus complete (and section 4.1.7 may be ignored). Similarly, if the request was made using a hardware token, the hardware device's API may be called to import the certificate into the device, or the user may be instructed to 'follow the manufacturers instructions' and then the registration and certificate issuing processes are complete (and again section 4.1.7 may be ignored). Download and backup in the LICS

In this case, the download of the certificate does not need to be carried out from the same machine (or browser) from which the request was made. After entering the emailed URL or entering his code, a Java applet is invoked. Upon entering the original pass phrase (used at the time of application), the signed certificate is downloaded from the cRAS and is installed in the key store in his operating system or within his browser software. See section 4.1.7 for further details.

4.1.7. Encryption and storage in the LICS

This is explained within the above sections (especially and It is the objective of this design that the private key cannot be obtained without the pass phrase, even by a sysadmin working on the LICS/cRAS. Therefore, the strength of the pass phrase is critical.

The LICS server incorporates a cracking routine that attempts to decrypt the containers. If it succeeds, the user is sent a notification that her certificate has been revoked (see the section on Revocation) and she must repeat the procedure of applying for a new certificate (back to the stage outlined earlier).

4.2. User employing his certificate from his personal computer

4.2.1. Authentication to a service

When the user accesses a web-based service that requires certificate authentication, he is prompted for the certificate to use (most relevant if there are >1 certificates in his store). The first time that this occurs in a browser session (or an operating system session, depending on the operating system and browser used), the user may be prompted for his key store pass phrase*. Once, this has been supplied correctly, the digital certificate is provided to the service with data that is also signed by his private key. The service checks the validity of the certificate (trusted CA and expiry date etc.) and may check the certificate revocation list (CRL - see section 4.6, below). Once, all of these checks have been passed successfully, authentication is completed and authorization may begin.

This is dependent on the browser. Further, it is possible for the user to choose not to pass phrase protect the key store, or for the pass phrase prompt to appear every time the certificate is used.

4.2.2. Authorization within a service

Once authenticated to the service (i.e. the certificate appears valid, not revoked etc.), the service may read the contents of the certificate. A local service may allow access to all members of the organisational unit. For example a service that allowed access by all people with a Keble College or Computing Services certificate, would add the following to a configuration file (e.g. to the virtual host configuration within an Apache server using mod_ssl, after the trust of the certificate chains had been established separately).

SSLRequire %{SSL_CLIENT_I_DN_CN} == "GlobalSign PersonalSign
                Class 1 CA" \
           and %{SSL_CLIENT_S_DN_O} == "Oxford University" \
           and %{SSL_CLIENT_S_DN_OU} == "keble"
           or %{SSL_CLIENT_S_DN_OU} == "oucs"

In this case, the above may be all that is required.

According to our requirements gathering exercise, the filtering of certificates using the organisational unit (OU) will be the most common, and clearly takes moments to set up. However, some services may still require the equivalent of user lists. In these cases, the authorization is established within the RA interface to the certificate issuing server.

For example, the project helped to establish certificate-mediated access to applicant data for a particular application with widespread (across the organisation), but relatively few users. The users of the application were distributed across all of the Oxford colleges. Therefore, the pseudonyms of all authorized users could be added to the appropriate .htaccess file. This file could contain lines similar to the following:

{SSL_CLIENT_S_DN_O} == "Oxford University" \
and  ( \
      %{SSL_CLIENT_S_DN_CN} eq "keble-abcdefgh" \
      or   %{SSL_CLIENT_S_DN_CN} eq "green-12345678" \
      or   %{SSL_CLIENT_S_DN_CN} eq "lina-23456789" \

However, there is a more elegant method of doing this. The main configuration file could read:

SSLOptions           +FakeBasicAuth
AuthName             "Put any text here"
AuthType             Basic
AuthUserFile         /path/to/external/file/httpd.passwd
require              valid-user

The httpd.passwd file would contain a list of 'authorized' pseudonyms, for example:

/CN=hertford-510b099a/O=Oxford University/OU=hertford:xxj31ZMTZzkVA
/CN=jesus-52e091ec/O=Oxford University/OU=jesus:xxj31ZMTZzkVA
/CN=jesus-fbf0f348/O=Oxford University/OU=jesus:xxj31ZMTZzkVA
/CN=keble-df188849/O=Oxford University/OU=keble:xxj31ZMTZzkVA
/CN=magdalen-5f2663fa/O=Oxford University/OU=magdalen:xxj31ZMTZzkVA

The pseudonyms can, as above, be included in the main configuration file itself. However, the advantage of the main configuration file calling an another file to be read means that the list of users/pseudonyms can be updated daily, or hourly, or on any change, depending on how the system administrator would wish to configure it.

Thus, the reading of OU is very simple to establish. However, the use of lists of pseudonyms requires a little more work. More pertinent to the possible difficulties with maintaining the pseudonym lists is the authorization level of the RA. For example, the RA may be trusted to establish whether the person is on the Oxford University IT Support Staff list (by checking their identity and checking the ITSS list) and therefore authorize the user to access the ITSS pages. However, the RA may have difficulties authorizing the user to be able to access the web site of the drama society (which may not publish the list of its members). Nevertheless, the DCOCE project succeeded in overcoming these issues for the few services that it established and trialled.

4.3. User moves 'personal' computer and employs her certificate

4.3.1. Introduction

This 'scenario' assumes that the user has moved to a computer other than the one where she usually works, and where her digital certificate and private key are safely held. The 'other computer is one that is relatively secure and not shared with many other users. This could be her computer at home or in another office within the University or Colleges. An alternative scenario is where the user moves to a public computer, such as a machine in an internet café or a multi-user library computer. This scenario is dealt with in section 4.4, below.

Users who have chosen to use secure hardware devices (such as smart cards or USB devices containing a 'crypto' chip) are not usually able to extract the private key from such a device, and therefore may not store their private key and certificate in the LICS. These users need only be concerned that the correct drivers are installed on the new computer so that the hardware device will work at this point.

4.3.2. Retrieval of certificate from the LICS

From the new machine, the user accesses a web page that represents the on-line interface of the LICS. She is asked whether she is at a relatively secure point or at a public computer. In the former case, she will download an applet that mediates the process of obtaining her private key and certificate from the LICS. In scenarios covered by the latter case, please see section 4.4, below.

Figure 4.3., below shows the general procedure of the interaction with the LICS via the Java applet. The procedure is as follows:

  1. The user is prompted to enter her pass phrase. The pass phrase itself does not leave the client computer, but instead a hash (using an algorithm such as SHA-1) of it is sent to the server. (Recovering a user's pass phrase from a secure hash is computationally infeasible).
  2. This hash is compared to those stored in a file (or database) on the LICS server.
  3. When a match is found for the hash, the corresponding encrypted key container (in PKCS#12 format - see section 4.1.7 above) is delivered to the user by the applet. (However see note in section 4.3.3 below regarding users with more than one certificate).
  4. The applet now installs her digital certificate and private keys into her browser. If the browser is not supported for this purpose by the LICS applet, the user may also be able to access some instructions and import the certificate and private key manually.

                     Illustrative figure showing the  process for obtaining private key and 

Figure 4.3. Using the LICS to obtain the private key and certificate.

4.3.3. Users with more than one certificate

Note that, as outlined in section 4.1.2 above, a user may be forced to have more than one certificate, due to her roles within different organisational units. In this case, after entering her pass phrase, she will be prompted with a choice of certificates. She can choose the certificate that she wants or she can repeat the procedure if she needs both (or all) of her certificates.

4.4. User wishes to use certificate at a public computer

4.4.1. Introduction

The concept of a 'public computer' was first raised in section 4.3.1 above, and includes machines in internet cafés or multi-user computers in situations, such as libraries or colleges. The general LICS solution, as outlined above, should not be used in these situations, as private keys can be left, all too easily, on public computers to create easy pickings for would be attackers. However, the educated user could possibly do this safely if he was to carefully remove his private key from the machine afterwards. It is possible that an applet could be written that does just this and some institutions have already developed examples of this, but the applet tends to be browser and probably operating system specific.

Our proposed solution for this would be to use short-term certificates, having minimum level assurance (see section 2.2 above). There are two main ways that these could be accessed or used and these are outlined below in sections 4.4.2 and 4.4.3.*

* The DCOCE project did not fulfil this part of the architectural design. However, this architecture, and the two options outlined formed our solution to this problem.
Of course, in future, having certificates and private keys on secure USB devices (and possibly even smart cards) may be the simplest and most reliable solution. Drivers are likely to be available in operating systems by default for such devices, and this would be by far the easiest and most secure solution.

4.4.2. Procedure using applet and hash

When the user needs to access a protected service from a public workstation, he will probably visit the same web page as outlined in section 4.3.2 above. Upon indicating that he is in a public place, the applet prompts him for his pass phrase (the same one that he protects his 'usual' key store and his PKCS#12 container in the LICS). The hash of that password passes over the network, protected by SSL/TLS (as in 2) above) and, once it has been verified, he is sent a temporary certificate and private key to install on the alien computer. As mentioned above, this certificate conveys minimum level assurance, but this will probably be sufficient for most of his needs.

4.4.3. Procedure using other authentication measures

At the University, there are other authentication mechanisms available. Some, such as those involved in single sign on, may be used to give access to a range of services. It is possible that a user could authenticate via one of these other trusted mechanisms and obtain a temporary certificate and private key in that manner.

At Oxford University, there is a new single sign on mechanism, based on Kerberos, known as WebAuth. There may not be a precedent of using a digital certificate to authenticate to WebAuth (as opposed to presenting a username and password), and this may prove technically difficult, but it seems theoretically feasible. Alternatively, a system could be built that could issue temporary certificates after authenticating to WebAuth via username and password. One other alternative could be to protect the LICS via WebAuth and for users to receive their certificates and private keys after successful authentication in WebAuth.

Various options exist for the co-existence of certificates alongside, or in front of an institional single sign on system. However, care needs to be taken to avoid the combined system from being too cumbersome and to avoid the need for new passwords (as much of the demand for single sign on comes from the desire to avoid multiple passwords) when the user's key store needs to be protected.

4.4.4. Problems to consider when using 'public' workstations

One issue to consider when downloading temporary certificates is that the certificate or key store in the browser or operating system may already be encrypted. This may occur if a user has already made use of the key store and password protected it. It may be that the subsequent user cannot access this store so that she can use it, even temporarily. This could effectively 'lock' that workstation and exclude the use of certificates entirely for most users.

For those users wishing to use their smart card or - currently, more likely - their secure USB device in a public place, there is a reliance on the correct drivers being in place, as mentioned above.

The reliability of the applet that allows the user to obtain a short-term certificate could also be a threat. This threat comes from what is now often termed as 'phishing'. The web page or site that issues the applet is guaranteed via the use of an SSL/TLS certificate. This is a reliable mechanism, but one which is poorly understood by many users. Therefore, this site and applet can be spoofed by attackers, whereby a very similar looking site and applet may be presented to the user (phishing) who then gives up his pass phrase as part of the process. This kind of attack is relatively unlikely to succeed when working on a University-managed workstation, but the likelihood of the attack being successful is much higher in public places. Therefore, when in an internet café, the user could reveal his pass phrase whilst obtaining a short-term certificate. This would then give an attacker access to the user's key stores on the LICS. If this was perceived to be a major threat if/when taking the DCOCE architecture into wide-scale production, one defence could be to insist upon longer pass phrases and, for example, users would know that they only ever give the first ten characters of these pass phrases to obtain a short-term certificate from a public workstation.

Another problem is general security. In public places, especially internet cafés, the likelihood of threats from trojans or keystroke recorders, etcetera is much greater. This could give rise to the pass phrase to the key store (and therefore the PKCS#12 containers themselves) becoming known to attackers. In one sense, this is a danger of any authentication mechanism that can be employed outside the managed University domain and this is mitigated for partly by policies that insist on passwords being changed frequently. However, it is arguably more of a challenge when certificates are used as the installation mechanism is quite an onerous step, and it would be desirable to avoid forcing the user to change pass phrases on a very frequent basis. Nevertheless, this could be introduced.

4.5. Renewing certificates

4.5.1. Introduction

Renewal is the term generally used to describe the process of applying for another certificate when the certificate that the user holds is about to expire or has already expired. For example, user certificates may be issued for 13 months and each user (e.g. a student) is encouraged to obtain a new certificate before the old one expires. If the user does this, then she does not have to go through the onerous registration procedures again, and can carry out the operation merely on-line (i.e. she does not have to re-visit her local RA).

The reasons for renewal are multiple. Users may move departments, get married and change name (although this is relevant only where the name appears on the certificate). However, most importantly, digital certificates can contain attribute fields that confer authorization privileges. These privileges can change and this may require a certificate renewal.

Note that the renewal process will be limited by an 'account expiry date' that is held in the user database. The institution must update account expiry dates periodically. Users will not be able to renew certificates beyond the 'account expiry date'. Similarly, that date will also act as an upper limit to the new certificate expiry date. *

*The DCOCE project did not build this as part of the prototype, but the architecture outlined here is our recommended solution .

4.5.2. Institution-initiated renewal procedure

In the case of a user's certificate about to reach expiry and the institution is certain that the user is eligible for another year's certificate use (e.g. students entering their second year of study), the procedure is as follows:

  1. The user receives an email informing him that he must renew his certificate within one month. The email includes a URL and basic instructions .
  2. The user follows the URL and downloads the applet for this task .
  3. The applet generates a certificate request but the request is also signed with the user's existing private key. This extra signature asserts to the cRAS that the request is genuine and that it does not need to be supported by a local RA.
  4. The final procedures are very similar to those outlined in section 4.1, above. However, the user may be encouraged to make use of a novel pass phrase .

If the user does not carry out the renewal procedure within one month, then he must visit his local RA and follow the full registration/certificate request procedures as outlined in section 4.1, above.

4.5.3. Self-initiated renewal procedure

Some possible reasons for self-initiated renewal are outlined in section 4.5.1, above. The procedures are very similar to those outlined above in section section 4.5.2, with the exception that:

  • The user is led to the applet via a link from the cRAS help pages.
  • (If applicable) a system of checking the new attributes is invoked whereby central RA personnel check the validity of the new attributes and forward the request to the CA.(Note that this procedure has not been fully outlined because, at present, the DCOCE project has no definite plans for the use of such attributes in the certificates).
  • The old certificate is automatically revoked one month after renewal, unless the expiry date has already passed.

4.6. Revocation

Certificates that have been revoked will appear on a Certificate Revocation List (CRL) as a minimum. Online Certificate Status Protocol (OCSP) should also be used, where possible, to give as wide support to revocation procedures as possible. However, this is in the hands of the Certification Authority (CA). One of the approaches that the project team has taken is to attempt to avoid putting extra CA procedures in place that could preclude the use of an external or commercial CA.

It is good practice for revocation lists to contain the serial numbers of revoked authentication certificates that have not yet reached their expiry date. Once revoked authentication certificates are expired, they are removed from the list.

Signing or encryption certificates (see earlier section) may have to remain on revocation lists for the lifetime of the lists.

This is beyond the scope of the project but is noted here due to the importance of these kinds of certificates that would certainly have to be considered if this architecture were to move into production. It may be best practice to keep revocation lists of authentication, signing and encryption certificates separate.

4.7. Limitations on certificate use

As noted above (see sections 1.2, 4.1.4 and 4.6) certificates have a variety of uses, but each certificate should be limited for use for authentication, signing and encryption. Authentication certificates will have a reasonable expiry period, typically thirteen months in a higher or further education environment, but signing or encryption certificates may never expire. Procedures for the escrow of encryption certificates may need to be invoked, but this goes beyond the scope of this document.

Up: Contents Previous: 3. Architecture and Components Next: 5. Summary

Oxford University Computing Services Mimas Athens access management services Oxfore e-Science Centre Systems and Electronic Resources Service Joint Information Systems Committee