What is PKI?

Introduction

Background

This document provides a brief introduction to the topic of Public Key Cryptography. It contains a brief history of cryptography, explains what problem a Public Key Infrastructure (PKI) addresses, describes the components of a PKI, and lists some common issues faced by organisations when deploying a PKI.

Audience

This document is intended as an introduction to PKI and supporting concepts. It assumes little or no prior knowledge.

In particular, this document attempts to explain the myriad acronyms and other terminology used to describe components and people involved in a PKI.

Definitions, Acronyms and Abbreviations

Certificate – a Digital Certificate, used to bind a Private Key to its rightful owner.

Certificate Holder – a person to whom a certificate has been issued by a CA.

Certificate Policy (CP) – a document listing the rules to be abided by when issuing and managing Certificates.

Certificate Practice Statement (CPS) – lists the procedures to be followed when issuing and managing Certificates.

Certificate Revocation List (CRL) – a list of certificates that are no longer trusted by the issuing CA.

Certification Authority (CA) – issues and manages the lifecycle of Digital Certificates.

Ciphertext – Encrypted information; plaintext that has been scrambled using a cryptographic algorithm and key to render it meaningless for anyone that does not know the key.

Digital Signature – the digital equivalent of a hand-written signature.

Evidence of Identity (EOI) – the processes followed by an Registration Authority (RA) to identify and authenticate a Certificate Holder before issuing them with a Certificate.

Hardware Security Module (HSM) – a hardware device used to store sensitive information, such as cryptographic key material. It is virtually impossible to extract information from the HSM without the proper authorisation (some HSMs will actually destroy all information contained within them if they detect an unauthorised attempt to extract that information). HSMs are more secure than Smartcards and provide improved performance.

Key-Pair – the two keys (public and private) used in an asymmetric algorithm.

Passphrase – like a password except that it is typically much longer. Helps protect against brute-force guessing attacks, and is often comprised of a series of English words, for example “the sun rises in the east unless something goes terribly wrong at night”. Typically used to control access to a Private Key held in software.

Personal Identification Number (PIN) – like a password except that it can only contain numbers. Typically used to control access to a Private Key held on a Smartcard.

Plaintext – information that is not encrypted or otherwise cryptographically protected; the underlying data in a transaction.

Private Key – one of the two keys used in an asymmetric algorithm, this key is held by the key owner only, and must be kept securely.

Public Key – one of the two keys used in an asymmetric algorithm, this key is given to anyone who wants to transact securely with the owner of the matching Private Key.

Public Key Cryptography (PKC) – also known as "Asymmetric Cryptography", this is a collective term to describe cryptography based around asymmetric algorithms.

Public Key Infrastructure (PKI) – the components, policies and processes supporting the issuing and management of Digital Certificates (which contain the public keys.

PKI Disclosure Statement (PDS) – a type of Certificate Policy. PDSs are generally written following a standards based format which is substantially simpler and more succinct than earlier CP standards.

Registration Authority (RA) – the interface between a CA and the Subscribers.

Relying Party – a person or application relying on the contents of a Digitally Signed message.

Revocation – the act of a CA terminating their prior certification of a digital certificate.

Smartcard – a credit-card sized card that contains memory on which a Private Key & related Digital Certificate information can be securely stored. Smartcards also include a processor so that sensitive cryptographic operations can be performed securely on the card.

Subscriber – an organisation obtaining Digital Certificates from a CA. Subscriber Agreement – a contract between a Subscriber Organisations and the CA, informing Subscribers of their responsibilities and liabilities.

References

1.            IETF, Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework, RFC3647, 2003.

A Brief History of Cryptography

The word Cryptography comes from the Greek for “Hidden Word”.

In one of the earliest documented uses of cryptography, Julius Caesar wrote to Cicero and his other friends in Rome more than 2000 years ago, employing a cipher in which each letter in the plain text was replaced by the third later letter in the Latin alphabet. Using this cipher CAESAR would yield FDHVDU.

However it did not take long for this basic cipher to be broken – leading to the development of better and stronger ciphers. In fact, since Caesar’s time there have been many periods (sometimes lasting hundred of years) where the best ciphers could not be broken by anyone – followed by equally long periods where even the best known ciphers could be broken.

All modern ciphers contain two basic components, the cipher “algorithm”, and the “key”. The algorithm is generally well known and studied – it describes the way that the original information (the plaintext) is scrambled, and is generally built into software components and the like. In contrast, the key is a random value that is used by the algorithm to cipher the message creating a “ciphertext”. The same key is then used to decipher the ciphertext in order to recover the original message”. The security of the ciphertext therefore relies on the security of the key. This is shown diagrammatically in Figure 1 below [ 1 ].

Figure 1 – Encrypting and Decrypting using a shared key.

The problem with this approach

Up until the last century, one fundamental problem with all ciphers existed – namely the need to exchange the “key”. For you to read the ciphered message I was sending you, you would need to know the “key” I used to encrypt it with – so that you could decrypt it and read it. And if I could not convey the key to you safely – then we would have no means of safely communicating.

For the military in particular, this remained a fundamental obstacle. Even if the Germans had suspected that some of their Enigma codes had been broken, it would have been very difficult to change them – as the logistics involved in safely sending new keys to their battlefield commanders would have proven extremely difficult.

The invention of the Asymmetric Algorithm

In the 1970s a solution to this key distribution problem was finally found. It involved a completely new type of cipher known as an “asymmetric algorithm”. Asymmetric cryptography was first discovered by a mathematician working for the British defence forces. Its significance was quickly appreciated, and the British wisely decided to keep the secret under wraps.

Some years later a second asymmetric algorithm was discovered by some American academics. When they published their findings, the US Defence forces were somewhat slower to react. Although attempts were made to suppress details of the algorithms, the secret was out.

For many years, the US and several other countries tried to prevent export of cryptographic algorithms and associated technology to other countries. The laws governing export of cryptographic algorithms were often the same laws governing export of munitions such as guns and fighter planes. In practice this hasn’t worked, and increasingly now these export restrictions are being relaxed.

How Asymmetric Algorithms work

Using an asymmetric algorithm two keys are used – collectively known as a “Key Pair”. The key used to encrypt information is completely different (but mathematically related) to the key used to decrypt it.

Each person’s Key Pair consists of a “Private” Key, held only by him or her, and a “Public” Key – which they can safely share with anyone who wants to communicate with them.

If a message is encrypted for you using your Public Key, then you can decrypt it using your Private Key. Because you are the only person with the correct Private Key – only you can decrypt the message. Figure 1 below shows how the encryption and decryption processes work using an asymmetric algorithm.

As one of the keys in the Key Pair is generally made public, asymmetric cryptography is also known as “Public Key cryptography”.

Storage of Private Keys

Keeping your Private Key safe is essential if public key cryptography is to work. There are three primary ways to store a Private Key, listed below in order of increasing security:

• In software – in which case it must be protected with a password or passphrase
• On a Smartcard – where it is protected by a PIN, or
• On a Hardware Security Module (HSM).

About Digital Signatures and Certificates

The need for Security in eBusiness

In the paper based world we write letters and sign them, perhaps have a witness verify that our signature is authentic, put the letters in envelopes and seal them, and send them – perhaps by certified mail – to their recipients.

The function of the envelope is to give the recipient confidence that the message had not been read by anyone else, and that the contents of the envelope are intact.

The signature on the letter provides the recipient with confidence that the letter came from the person who claimed to have sent it. Additionally, the signature provides the recipient with confidence that the person who sent it can not later deny having sent the letter.

In the world of eBusiness, we need reliable ways of achieving the same level of confidence in transactions we send and receive across insecure mediums such as the Internet. To do this, four key requirements have to be addressed.

The four key requirements of Electronic Business

For eBusiness to be possible four key requirements have to be addressed. We need confidence in a message’s:

• Confidentiality – assurance that only we have read it
• Authentication – assurance the person claiming to have sent the message really was that person
• Integrity – that the message wasn’t tampered with or altered in transit, and perhaps most importantly for business…
• Non-Repudiation – the confidence that the person sending the message cannot later deny having written it.

In the previous section we introduced the concepts of Asymmetric Algorithms and Public Key Cryptography and explained how Public Key Cryptography could be used to cipher messages sent between different people.

While confidentiality is sometimes important in electronic communications it is usually not the most important characteristic.

To illustrate this, consider a lost pay cheque. While most people might be mildly embarrassed if someone else were to discover what they earned (Confidentiality), they would be far more concerned if:

• the bank refused to honour the pay cheque because they couldn’t confirm who issued it (Authentication)
• the company that issued the pay cheque could deny having issued it (Non-Repudiation)

and, both issuer and bank would be very concerned if anyone could change the amount shown on the cheque to suit themselves!

To provide Authentication, Integrity and Non-Repudiation, digital signatures are required.

About Hashing Algorithms

Before the concept of a Digital Signature can be understood, we first need to introduce the concept of a Hashing 2 Algorithm…

A Hashing Algorithm is a mathematical function that takes a piece of data (the message) and converts it to a number – called a ‘hash’.

The most important feature of a hashing algorithm is that any change to the message – even changing the order of two words or adding a full stop -will result in a completely different hash. For this reason the hash is sometimes referred to as a “digital fingerprint”.

Hash Algorithms have several other important features:

• it is impossible [ 3 ] for someone in possession of a hash to work out what the original message was, and
• it is (almost) impossible for someone to generate two different messages that will result in the same hash.

Figure 3 - Creating a hash

Digitally Signing a document

Digital Signatures are really just a clever application of Public Key Cryptography – outlined in Section 2.3. As explained in this section, each person in the eBusiness community holds their own Private Key – known only to them.

For now, let’s assume my name is Tom Jones and that I want to send a message to my bank authorising them to transfer $1,000,000 to another account. I can use my Private Key to decrypt confidential messages sent to me. But I can also use my Private Key to prove to the bank that I am the originator of a message authorising the transfer.

Figure 4 below shows how a digital signature is created. The message authorising the transfer is first passed through a Hashing Algorithm to produce a Hash of the message. The message Hash is then encrypted using my Private Key. This encrypted Hash is the “Digital Signature”.

I can now attach the Digital Signature to the message and send it to the bank.

Verifying the Signature

When the bank receives my message, they use a similar process to verify the signature as shown in Figure 5 below.

Firstly, the bank passes the message through the same Hash Algorithm that was used when creating the Digital Signature – producing a Hash of the received message.

Secondly, the bank decrypts the Digital Signature using my Public Key-producing a second Hash.

If the two hashes are the same, then the bank can be sure that:

• the document came from me – as only I could have created a Digital Signature that decrypted correctly using my Public Key (Authentication)
• the message was not tampered with in transit – if it had been tampered with, the hash of the tampered message would have been different to the original hash (Integrity), and
• that I cannot deny having sent the message – as only I could have created that particular Digital Signature (Non-Repudiation).

The need for Digital Certificates

There is one more problem to solve. How can the bank (in this instance) be sure that my public key really belongs to me? The banks needs to have confidence that the public key belongs to the real “Tom Jones” - before they can trust the signed message.

This problem is solved through use of a Digital Certificates as shown below.

Digital Certificates

A Digital Certificate, often just referred to as a Certificate, is really no more than an electronic message digitally signed by an organisation that everyone trusts.

A Certificate contains:

• details about the owner – the person who holds the Private Key, and
• details of the owner’s Public Key
• details about the Certificate issuer (the trusted organisation that vouches for the accuracy of all information contained in the certificate)
• validity and expiration dates
• a range of possible “certificate extensions” – which provide more information about the owner of the certificate and its applications
• details of the Certificate Policy under which the Certificate was issued – explaining what rules were applied in issuing the certificate, what identity checks were performed by the CA, and what the certificate can be used for, and (most importantly)
• a Digital Signature of the Certificate contents.

As the Digital Signature on the Certificate is created by a trusted organisation – known to all players in the eBusiness community – they can have confidence that the contents of the certificate are accurate. These trusted organisations are referred to Certification Authorities or CAs.

PKI Components

A Public Key Infrastructure typically consists of everything that is needed to create, manage and distribute digital certificates.

But there is a lot more to a PKI than just technology…

As there are normally several different parties involved in a PKI, policies and procedures need to be documented govern agreed contracts need to be agreed between each of the various players outlining their roles, responsibilities and liabilities. These policies, procedures and contracts from part of the PKI.

Components of a typical PKI include:

• one or more Certification Authorities
• one or more Registration Authorities
• a Directory, and
• a number of Policies Procedures and Contracts.

Certification Authority (CA)

The CA system is the trusted party described above. It provides the trust basis of a PKI, as it issues and manages Digital Certificates for their whole life cycle. The CA’s responsibilities include:

• issuing certificates
• (sometimes) publishing certificates to a directory
• ensuring Certificates are revoked (marked as untrustworthy) when necessary, and
• publishing details of revoked certificates in Certificate Revocation Lists (CRLs).

When implementing a PKI, an organisation can either operate its own CA system, or use the CA service of a Trusted Third Party (such as Verisign) or Thawte.

When are Certificates Revoked?

A CA may revoke a certificate for a number of reasons, some of which are listed below:

• the CA has been compromised
• the Private Key that corresponds to the certificate may have been compromised (for example, the key owner may have had their token that contains the Private Key stolen), or
• the status of the certificate owner has changed (so that the information contained in the certificate is no longer correct, because for example the owner’s surname may have changed).

CA’s periodically publish a list of revoked certificates. These are called Certificate Revocation Lists (CRLs). Some CAs also offer to respond to requests to provide up-to-the-minute information on certificate status and validity. A special protocol for requesting information about certificate status exists called Online Certificate Status Protocol or OCSP.

Applications that rely on digital certificates to authenticate people or transactions should check the CRL published by the issuing CA; if the certificate is listed then it should not be trusted.

Certificate Hierarchies

A Certificate can be self-signed (i.e. not authorised by any CA), but this doesn't provide any benefits over simply using Symmetric Keys – as there is no way for a Relying Party to trust the information contained in the certificate.

In practice, most Certificates are signed by a CA.

CAs own public keys are held in certificates and these CA Certificate signed by another CA. And so on. The last CA in the chain is known as the 'Root CA'. In theory, this certificate chain can be infinitely long. However in practice most certificate chains do not exceed 3 or 4 certificates. A Root CA’s Certificate is “self-signed” meaning that the Root CA uses its own private key to sign the certificate.

By trusting the ‘Root CA’, or one of the Subordinate CAs, the Relying Party trusts all certificates that this CA has signed. If this includes a Subordinate CA certificate, then the Relying Party additionally trusts all certificates signed by that Subordinate CA, and so on down to the Certificate Holder certificates. This is how the Relying Party can trust the contents of a Certificate Holder’s Certificate, even though they may never have had any prior relationship with the owner of that certificate.

To make this easier, most commercially available browsers contain a list of “trusted” Root CA certificates as part of their default installation. Certificates issued by these Root CAs, or CAs that are subordinate to them, are automatically trusted by the browsers.

Registration Authority (RA)

The RA is a person or organisation that is responsible for checking someone’s credentials before a certificate is issued. RAs are in effect agents of the CA. Where a certificate states that someone works for an organisation in a particular role, or has a particular qualification, then the RA is also responsible for confirming the accuracy of this information – before the certificate is issued.

The quality of this authentication process determines the level of trust that can be placed in the certificates.

In the US and Australia, the Post Office often takes on the role of Registration Agent – as their local points of presence make it easy for them to perform face-to­face checks on someone’s credentials.

The RA is normally obliged to keep records of the people or organisations that have requested Certificates.

Directory

An X.500 directory is often used by CAs to provide a distribution point for certificates and Certificate Revocation Lists (CRLs).

It may also be used to store other information about the Certificate Holders.

Policies and Procedures

In a paper-based environment, a document could be worth a million dollars, or only the paper it’s written on, depending on:

• who issued it
• who signed it
• how easy it is to forge, and
• the legal framework that exists to support the document.

Similarly, the effective use of keys and certificates imposes certain obligations on the parties involved. Certificate Holders must protect their Private Key from compromise. This is the fundamental building block of the PKI. If a Private Key is compromised, it must be reported immediately so the CA can revoke the Certificate. The obligations of the CA are to:

• use due diligence in verifying the identity of Certificate Holders
• securely manage any keys and Certificates that it has access to, and
• promptly revoke a Certificate suspected of compromise.

The obligation of Certificate Holders is to safeguard their private keys and promptly report its theft or compromise.

The obligations of Relying Parties are to:

• verify the certificate
• confirm it is not listed by the CA as revoked, and
• ensure the certificate is used only for the purposes stipulated in the applicable Certificate Policy (CP).

Certificate Policies and Certificate Practice Statements enable a user to determine the level of assurance they can place in the integrity and authenticity of the Digital Certificates issued by the CA. They are referenced in the Certificates issued by a CA.

Certificate Policy (CP)

A Certificate Policy [ 4 ] describes the rules under which a particular certificate is issued. These include the rules governing generation, distribution, and administration of the Digital Certificates, and the policies to be followed in the event of any possible Key compromises.

A CA may define a different CP for each different type of Certificate it issues. This is quite common practice – especially where a CA applies different rules in checking the credentials of different classes of Certificate Holders.

Certificate Policies often make explicit statements on the CA’s liability to a Relying Party in the event that information in a certificate is shown to be wrong.

Relying Parties should check the CP before deciding whether or not to trust the Certificate.

It is important to note that, many commercially available PKI enabled products do not allow users to configure a list of trusted Certificate Policies in the same way that they allow users to configure a list of trusted CAs. For this reason some organisations such as Verisign typically use different sub-CAs to issue certificates under different policies (in effect having one sub-CA per policy).

Certification Practice Statement (CPS)

The CPS contains a more detailed description of the practices and procedures a CA follows when issuing and managing Digital Certificates. It is tailored to the organisation's PKI operating environment and organisational structure.

Where a CP defines what the rules are, the CPS describes how to implement those rules.

Appendix [ A.1 ] provides more information on the legal difference between a PC and CPS.

Other Contracts and Agreements in a PKI

Several other contracts and agreements are commonly used in a PKI.

CA/RA Agreements

CA/RA Agreements are typically used where an external organisation is responsible for acting as a Registration Authority on behalf of the CA. They define the responsibilities of both the CA and RA. Importantly, the CA/RA agreements usually seek to define who will be liable in the event that it can be shown that the RA failed to exercise due diligence in checking someone’s evidence of identity. Typically, the CA attempts to divest some of this liability to the RA!

Subscriber Agreements

Many CAs allow larger organisations to undertake evidence of identity checks on their own staff. This saves their staff having to visit an external Registration Authority and establish who they are and who they work for – when typically they would have had to do this anyway on joining the organisation.

Like CA/RA agreements, Subscriber Agreements seek to define the responsibilities of both the CA and the external organisation. CAs almost always use Subscriber Agreements to ensure that the external organisation can be held liable in the event that they failed to exercise due diligence in checking an employee’s evidence of identity

Certificate Holder Agreements

CAs often require people being issued with certificates to sign a subscriber agreement before they are willing to issue them with a certificate. Certificate Holder agreements (sometime referred to as End User Agreements or Key Holder Agreements) spell out to Certificate Holders their obligations to keep their token secure at all times, not tell anyone their password, only use their Certificates for authorised purposes and promptly report loss or theft of their token.

How these contracts and agreements are used:

Use of each of the contracts and agreements is illustrated by the hypothetical scenario shown in Figure 6 below.

Acme Global Enterprises runs a number of CAs for different purposes. Most do not accept any form or liability whatsoever, but some Acme clients insist that the CA accepts some liability. To protect its own interests, Acme sets up a separate company “Acme Liability Limited” that run the Acme Liability CA.

A Subscriber Agreement is signed between the Acme Global Enterprises and the Acme Liability Limited. Under the terms of this Subscriber Agreement, Acme Global Enterprises agrees to use its CA to issue a certificate to the Acme Liability CA, but accepts no liability whatsoever for certificates issued by Acme Liability Limited.

The Acme Liability CA issues Certificates under a range of different Certificate Policies depending on how people register with them. People can register:

• by presenting their credentials to the Acme Liability Limited directly
• by presenting their credentials to an approved Registration Authority such as Bogg’s Registration Services, or
• if they work for a company such a Colossal, by presenting their credentials to Colossal’s HR department.

All certificates issued by the Acme Liability CA state:

• the name of the person holding the certificate
• who they work for, and
• their position within that company.

All certificates issued by the Acme Liability CA are issued under Certificate Policies which cap Acme Liability Limited’s liability to any Relying Party to $10,000 in the event that the Relying Party can prove that Acme failed in its duties to establish someone’s identity correctly, or failed to publish a CRL on time – leading to the Relying Party suffering a demonstrable financial loss. Acme also disclaims responsibility for any incidental, consequential or punitive damages.

Albert Direct wants to register directly with the Acme Liability Limited. He brings his passport, and a letter from is employer vouching for his employment to the Acme office. Acme staff check is passport, phone his employer to confirm the letter is authentic, and then have Albert sign an Certificate Holder Agreement. The Certificate Holder Agreement requires Albert to: • only use his Certificate for authorised purposes

• keep his token and password safe at all times
• promptly notify Acme Liability Limited if he is fired or his position changes, and
• promptly notify Acme Liability Limited if he loses his token or suspects someone else may have had access to it.

Bogg’s Registration Services have offices throughout the country and want to make money by registering Acme Liability Limited clients. They enter into a CA/RA agreement with Acme Liability Limited under which they agree to:

• perform the same registration checks on members of the public as Acme Liability Limited do, and to the same degree of rigor
• keep records of all documentation collected and verified whenever a member of the public is registered
• promptly notify Acme Liability Limited of any request to revoke a certificate
• accept liability, capped at $12,000, in the event that Acme Liability Limited can prove that they failed in any of these duties

in return for which, Acme Liability Limited will pay them a small fee for each registration.

Colossal Enterprises needs to issue certificates to a large number of its staff and doesn’t want to have them take time off work to visit Acme or an approved Registration Authority. Firstly Catherine, who works for Colossal’s HR department, registers for a certificate directly with Acme Liability Limited. A Subscriber Agreement is then signed between Colossal and Acme Liability Limited under the terms of which:

• the Acme Liability CA agrees to issue certificates in response to (digitally) signed requests received from Catherine
• Colossal agrees to accept all responsibility for checking their staff credentials before certificates are issued
• Colossal agrees to accept all liability for transactions signed using a certificate issued under the terms of this agreement.

Figure 6 -Use of Contracts and Agreements

APPENDICIES

[ 1 ] Note that, the process of ciphering the message is referred to as “Encryption” and the process of deciphering the message is referred to as “Decryption”.

[ 2 ] Sometimes referred to as a “Digest” algorithm.

[ 3 ] The term ‘technically infeasible’ is often used, which basically means that if you had a huge amount of computing power and left it going for a very long time then the algorithm could be broken, but that level of computing power is not currently available, nor expected to be in the near future.

[ 4 ] Sometimes referred to as a “PKI Disclosure Statement”.

[ A.1 ] What is the Difference between a Certificate Policy and a Certificate Practice Statement?

The terms CP and CPS often create significant confusion – or are incorrectly used interchangeably. They are in fact quite different as illustrated in this Appendix.

Below are some definitions of the terms “Certification Practice Statement” and “Certificate Policy”.

[ A.1.1 ] Certification Practice Statement (CPS) Definitions

A statement of the practices which a CA employs in issuing certificates.

(From: American Bar Association, Digital Signature Guidelines, 1996)

A certification practice statement is a detailed statement by a CA as to its practices, that potentially needs to be understood and consulted by subscribers and certificate users (relying parties).

(From: Chokhani and Ford, RFC 3647: Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework, 2003).

A document that sets out what happens in practice to support the policy statements made in the CP in a Public Key Infrastructure.

[ A.1.2 ] Certificate Policy (CP) Definitions

A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements.

(From: Chokhani and Ford, RFC 2527: Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework, 1999).

A document that sets out the rights, duties and obligations of each party in a Public Key Infrastructure.

[ A.1.2.1 ] Differences between the Certification Practice Statement (CPS) and the Certificate Policy (CP)

In broad terms, the difference is that the CP states what assurance can be placed in a certificate issued by the CA, whereas the CPS states how the CA establishes that assurance.

Several authoritative statements discussing the differences between the CP and CPS have been published. For example, the extract below is from RFC 2527: Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework, 1999:

“The concepts of certificate policy and CPS come from different sources and were developed for different reasons. However, their interrelationship is important.

A certification practice statement is a detailed statement by a certification authority as to its practices, that potentially needs to be understood and consulted by subscribers and certificate users (relying parties). Although the level of detail may vary among CPSs, they will generally be more detailed than certificate policy definitions. Indeed, CPSs may be quite comprehensive, robust documents providing a description of the precise service offerings, detailed procedures of the life-cycle management of certificates, and more -a level of detail which weds the CPS to a particular (proprietary) implementation of a service offering.

Although such detail may be indispensable to adequately disclose, and to make a full assessment of trustworthiness in the absence of accreditation or other recognized quality metrics, a detailed CPS does not form a suitable basis for interoperability between CAs operated by different organizations. Rather, certificate policies best serve as the vehicle on which to base common interoperability standards and common assurance criteria on an industry-wide (or possibly more global) basis. A CA with a single CPS may support multiple certificate policies (used for different application purposes and/or by different certificate user communities). Also, multiple different CAs, with non-identical certification practice statements, may support the same certificate policy. “

The main difference between certificate policy and CPS can therefore be summarized as follows:

(a) Most organizations that operate public or inter-organizational certification authorities will document their own practices in CPSs or similar statements. The CPS is one of the organization's means of protecting itself and positioning its business relationships with subscribers and other entities.

(b) There is strong incentive, on the other hand, for a certificate policy to apply more broadly than to just a single organization. If a particular certificate policy is widely recognized and imitated, it has great potential as the basis of automated certificate acceptance in many systems, including unmanned systems and systems that are manned by people not independently empowered to determine the acceptability of different presented certificates.”

Another example is from the Model Certificate Policy: Part A ~ Introduction and Approach, by the USA Government Information Technology Services, Federal PKI Steering Committee, Legal Policy Working Group, 1998. This document claims that a CP and a CPS differ in terms of:

• authorship
• purpose
• specificity, and
• approach.

These differences are summarized in the table below.

	Certification Practice Statement (CPS)	Certificate Policy (CP)
Author	Always defined by the CA.	May be defined by the CA, or by the Certificate User or a Government authority or industry association.
Purpose	“How” it is adhered to. Contains practices and procedures.	“What” is to be adhered to. Contains requirements.
Specificity	More detailed and specific.	High level document.
Approach	Tailored to the CA. A CA will typically have one CPS.	Independent of the CA. One CA may support many certificate policies. Also, a CP may be supported by more than one CA. A CP may be used to define and limit the use of a certificate.

 

[ A.1.2.2 ] Sample Clauses Illustrating the Difference

Sample CP Clause

"Users will inform the Operating Authority immediately upon discovery that their private key has suffered unauthorized disclosure."

Sample CPS Clause

"All users (including end-users and operators of CAs) will be informed of the requirement to report unauthorized disclosure of their private key in an agreement, which they will sign prior to their being issued a certificate. Upon discovery of the unauthorized disclosure of the private key, users will be required to contact their CA, within one working day. The method of contacting the CA will be one of those listed in the CPS. When not in use, users will be required to keep all copies of their private key either on their person, or in a locked place."

 (From: Model Certificate Policy: Part A ~ Introduction and Approach, Government Information Technology Services, Federal PKI Steering Committee, Legal Policy Working Group, 1998)

[ A.1.2.3 ] Summary of the Different Uses of a CPS vs a CP

Uses of a CPS

Uses of a CP

To protect itself against claims (limiting liability) To positioning its business relationships with subscribers and other entities Provides trust to Certificate Holders about certification services For due diligence by corporate users/businesses Provides minimum operational requirements required subsidiary businesses and TTP services For auditing of certification services Reflects current policy, procedures and controls Provides education and understanding to community of users

Provide common security requirements for a Certificate type Define and limit the use of certificates Specify requirements and obligations of Subscriber, the Certification Authority, and Relying parties Define liabilities for Subscriber, the Certification Authority, and Relying Parties Accreditation, which may be required and the criteria by which accreditation is completed Specify policy administration process Specify governing law