This paper introduces the concept of delta certificate policies to allow generic organizational certificate policies to be augmented incrementally to fulfil the requirements of specific business functions or applications. This concept permits interoperability within the organization and with other organizations after cross-certification, and eliminates the proliferation of distinct certificate policies and allows a single certificate to serve multiple purposes.
 
 

We would like to thank Line Lafrance, Department of Foreign Affairs and International Trade for her help in developing some of the concepts elaborated here. The challenges presented by DFAIT’s environment have helped refine our vision of future developments in public and private PKIs.
 
 

Introduction

Electronic commerce, cross-organization interoperability, secure communications over the Internet and many other business needs are leading organizations to Public Key Infrastructure (PKI) services as the basis for the various security requirements for their applications. Of the many activities required to establish a PKI¹, these organizations will invariably need to write certificate policies - certificate policies specify a set of rules and requirements that must be followed by a certification authority (CA) in issuing keys and certificates to a particular community of users with similar security requirements.
 
 

Certificate Policies

Certificate policies, in fact, define the technical and operational requirements that must be met in order for a CA to establish the level of assurance in the identity and key certification process that is required to support an application or a set of applications.

Certificate policies are rather lengthy documents which generally follow the structure defined in the Certificate Policy and Certification Practices Framework — issued by the Internet Engineering Task Force (IETF). A brief summary of the sections’ content is provided below.

Anyone who has had to write organizational certificate policies will have invariably faced an important dilemma. It is recognized as a great benefit to keep these certificate policies as few and as generic as possible, so as to fulfil the needs of broad ranges of business functions with similar security requirements and so as to promote interoperability. However, certain business functions will exhibit security requirements that are specific to their needs and more stringent than those defined in generic certificate policies serving common application requirements. This would then seem to lead to a few generic and a slew of specific certificate policies. In short, a rapidly unmanageable situation that defeats the interoperability goal of a PKI.

A solution to this quandary can be found in the very structure of X.509 certificates – which contain a PKI user’s name and public key along with various other user attributes.
 
 

Object Identifiers

Each certificate policy is uniquely represented by an "object identifier" (OID) which is a numeric string that is contained in a field of each certificate that is issued according to a given certificate policy. In order to ensure interoperability and uniqueness of each OID, these are registered with recognized international bodies according to a structure defined in X.208 from the International Telecommunications Union (ITU) (the structure can be examined at http://www.alvestrand.no/objectid/top.html).

Conceptually, the OID field of a certificate must be examined by the user process to understand the requirements enforced during the issuance of the certificate. The user, or the user process, can then decide to rely, or not to rely, on the certificate for a given transaction.

Recommendation X.509 also allows the OID field to contain several OIDs to specify that a given certificate fulfils the requirements of more than one certificate policy. Herein lies the solution to the generic/specific certificate policy problem.
 
 

The Solution

We have stated that our problem arises when a business function's requirements cannot be entirely mapped to any of the generic certificate policies defined or adopted by the organization. Experience has shown us, however, that one can generally find one of these generic certificate policies that does provide a close match only but for a few of the policy provisions. And in fact, experience again has shown us that the needs exhibited by the business function in those specific policy provisions are generally more stringent than what can be fulfilled by the generic certificate policy (otherwise one would simply adopt the certificate policy that meets and exceeds the requirements of the business function).

The solution is to create a "delta certificate policy" which builds upon another certificate policy. Based on the generic certificate policy that more closely matches the business function's requirements, a delta certificate policy would address only the policy provisions that are not met by the generic certificate policy. We would then create a type of certificate that would be issued by a CA based on generic certificate policy upgraded by the delta certificate policy that would completely meet the requirements of the business function. The delta certificate policy would be considerably more succinct than its explicitly associated generic counterpart since it would only address the specific policy provisions that are lacking in the generic certificate policy.

The delta certificate policy would have its own associated OID. This OID would be added in the OID field, along with the OID of the generic certificate policy, for each certificate issued according to the provisions of both. Certificates issued according to the generic certificate policy augmented by the delta certificate policy would then possess two (2) OIDs in the OID field.

The software application that implements the business function would verify that each certificate it is asked to rely on possesses both the required generic OID and the incremental delta OID. The benefit is that this allows a user to possess a single certificate when engaging in transactions within the special business function as well as other business functions that rely on certificates meeting solely the provisions of the generic certificate policy. Since the "delta certificate" issued meets the provisions of the generic certificate policy and in fact exceeds it for the provisions addressed by the delta certificate policy, the user does not require two certificates. "Generic" applications would verify that the certificate possesses the generic OID and would ignore the delta OID.

Conceptually, it is also possible for a certificate to contain several delta OIDs if it required that it be used in several different business functions with associated incremental delta certificate policies.

Experience has shown us that in certain circumstances, an organization may even wish to not publish the delta certificate policy because it alludes to internal or sensitive business requirements.

Note that when a CA accepts to support the added provisions of a delta certificate policy it would likely need to adapt its practices and update its certification practices statement accordingly.
 
 

Cross-Certification or How Interoperability Is Achieved

When an organization enters into cross-certification with another, an analysis ensures a thorough mapping between the provisions of one or many certificate policies from each organization. It is likely that generic certificate policies from each organization would be the candidates for cross-certification analysis. Once cross-certification establishes equivalence between two certificate policies with distinct OIDs, each organization's application becomes able to accept the other organization's OID as equivalent.

If one (or both) organization has implemented delta certificate policies, mapping of generic certificate policies across organization would not be affected. As was the case for the organization's own generic applications, the other organization would simply disregard the delta OID since it would not have any knowledge if its particular provisions.
 
 

Conclusion

We have introduced the concept of delta certificate policies to solve the problem of proliferating distinct certificate policies and to allow a single certificate to serve multiple purposes. This concept permits interoperability within the organization and with other organizations after cross-certification, and allows generic organizational certificate policies to be augmented incrementally to fulfil the requirements of specific business functions or applications.