1 Introduction

1.1　 Introduction

The promotion of PKI (Public Key Infrastructure) interoperability is one of the most important issues today for creating a true PKI. This issue is especially important for GPKI (Government Public Key Infrastructure), where PKI must run on various applications across broad and diverse authorization domains.

One key to the success of Digital Government PKI is the distribution of easy-to-use, secure Digital Government applications. For Digital Government to become a reality requires the development of a critical mass of fully interoperable PKI/GPKI Digital Government applications, and a wide availability of COTS (Commercial Off-the-Shelf) products.

However, when it comes to the actual attempt to develop GPKI-ready applications, developers encounter several difficulties. The lack of currently running implementations, the lack of development and test environments, and difficulty in positing credible testing schemes are only some of the problems encountered when dealing with interoperable technology for GPKI.

Once developed, the solutions to the issues of GPKI interoperability will generate momentum behind the creation of GPKI-ready Digital Government applications, also resulting in a broad range of GPKI security schemes, delivered at a reasonable cost.

This report, titled "Development of Interoperable Assistive Technology for Digital Government Information Security" is one product of the Information-Technology Promotion Agency's soliciting public submissions in pursuing one of its directives to "investigate and develop information security technology". The Agency adopted suggestions submitted by the NPO Japan Network Security Association (JNSA) for inclusion in this report.

1.2　 Report and Project Objectives

In addition to this report, the Information-Technology Promotion Agency (IPA) sponsored the "Challenge PKI 2002 Project" calling for the creation of GPKI test case design sheet, PKI interoperability test suite development, and GPKI application sample implementations. JNSA has been entrusted with the project.

During the "Challenge PKI 2001", also entrusted by the IPA last fiscal year, several of the CA (Certificate authority) products submitted by various parties were tested for multi-vendor PKI interoperability. These tests confirmed the interoperability of multi-vendor PKI and multi-domain PKI including that for bridge models. Challenge PKI 2001 focused on CA, but it was clear that there are technological difficulties related to bridge models in ensuring interoperability of the PKI application that is interpreting the certificate issued by the CA.

Most of the specifications required for bridge models (or hybrid models) used by GPKI (Government Public Key Infrastructure) include the basic PKI standards such as the ITU's X.509 and the IETF's RFC3280. Accordingly, applications required for GPKI should run properly as long as these standards have been strictly implemented. However, X.509 and RFC3280 are at best general purpose specifications, and it is very difficult to implement them all in every case.

PKI systems, including GPKI, must maintain interoperability over a wide range of possible situations. The adoption of a narrower profile out of the X.509 and RFC3280 standards will lead to interoperability within the more narrowly defined framework. The Government Public Key Infrastructure Interoperability Specification (GPKI Interoperability Specification) defines specifications ensuring interoperability for GPKI. GPKI is structured with multi-vendor PKI and multi-domain PKI extensibility, but a high degree of interoperable technology is still necessary. Perhaps the most technologically difficult matter is the verification of the certificates issued by the bridge certificate authority and the domain certificate authority performing cross certification. In general, certification path construction and path verification are conducted during this certificate verification process. The specifications for this path construction and path verification should be the same for all GPKI applications.

The requirements for GPKI applications are described in the GPKI Interoperability Specification; however, the existence of these specifications alone does not mean that the task of development is any easier. The GPKI bridge certificate authority is expected to provide cross-certification with the Local Government Public Key Infrastructure (LGPKI) of local and regional governments, and with Japanese Public Key Infrastructure (JPKI, or Japanese PKI). In the future, cross-certification may also be performed internationally.

In this manner, the party requiring signature verification of the certificate (relying party) will encounter a broader range of domains to verify, but this serves to highlight the advantages offered by a bridge model, which is another technological issue by itself.

The relying party requires certificate verification from the domain providing cross-certification with the bridge certificate authority. At this time, it is necessary for the relying party to be able to construct a path for the appropriate certificate and perform path verification, selecting from among the many intermingled certificates issued across the wide range of domains. It is no simple task to implement applications conforming to GPKI which efficiently handle this type of path construction and path verification. It may be even more difficult to develop applications with assured interoperability across the expanded range of domains that accompany LGPKI and Japanese PKI.

Given this environment, we believe that the following should also be considered in addition to standard specifications when attempting to promote the development of applications conforming to the GPKI Interoperability Specification.

l Description of standards forming the basis of GPKI specifications

l Development environment for GPKI

l Test environment for GPKI

l Test cases for GPKI

l Examples of real-world implementations

At the heart of the Challenge PKI 2002 Project was the goal to provide the types of resources listed above. The Project also has its sights on expanding beyond GPKI, facilitating cross-certification for LGPKI and Japanese PKI, as well as international cross-certification.

Included in this report are sections covering path construction, path verification standards, future trends in path verification standards, implementations using Microsoft CryptoAPI (Microsoft's cryptography framework), implementations in the Java environment, and testing methodologies, all of which are common requirements for the applications conforming to the GPKI. In addition, this report uses results from the Challenge PKI 2002 Project to illustrate interoperability test suites, GPKI test case specifications, and samples of Microsoft CryptoAPI and Java implementations.

Figure 1-1 shows the scope for the Challenge PKI 2002 as well as the scope for this report.

Figure 1‑1 Challenge PKI 2002 Scope

In the past, there have been several debates and discussions related to cryptography and the creation of deliverables for Digital Government, as well as the performance of verification testing for Digital Government applications. However, the scope of arguments and results related to the Challenge PKI 2002 were extremely limited. One major objective of this report is to provide information that fills in the apparent gaps.

1.3　 Path Construction / Path Verification Standards

While bridge models (or hybrid models) used with GPKI allow for flexible authorization domain extension, the associated applications require a high degree of interoperable technology. Such implementation and testing are particularly difficult for the path construction and path verification on the part of the relying party.

The profile for the certificate issued by GPKI is described in the GPKI Interoperability Standard. One can consider this GPKI certificate profile as a subset of X.509 or RFC3280 standards. The diagram below illustrates the relationship among X.509, RFC3280 and the GPKI certificate profile.

Figure 1‑2 Relationship among the X509,RCF3280 and GPKI Certificate Profiles

While GPKI applications require interpretation of the GPKI certificate profile, this implementation can be thought of as a "subset" of the implementation required by RFC3280 and other standards. However, implementation of a major portion of the specification described for RFC3280 is still required. Further, many of the requirements for such an implementation deal with processing revocation lists in X.509 Certificate V3 format and CRL V2 format.

The X.509 V3 and CRL V2 formats are defined in the 1997 X.509 3^rd Edition. Each of these formats has an extended partition termed X.509v3 extension and CRLv2 extension, respectively. Additionally, a "standard extension" has been defined for each of these extended partitions.

Those who wish to implement GPKI applications must have a thorough knowledge of these standard extensions. However, the X.509 3^rd Edition and the newly revised X.509 4^th Edition, as well as the RFC2459 and the newer RFC3280 referenced by the GPKI Interoperability Specification, constitute a significant amount of documentation, requiring an extensive technical background to understand correctly.

Section 2 of this report, "Certification Path Construction/ Path Verification Overview", will discuss these specifications in further detail.

1.4　 Certificate Verification Server Model

Bridge models require the handling of complex certificate verification. The most commonly implemented model is one that requests certificate verification from a server. This is dictated not only by the difficulty and complexity in handling path construction and path verification, but also the desire to limit the need to continually upgrade client software due to changes in specifications driven by an ever-increasing range of domains that must be verified. In fact, a GPKI certificate verification server has been created precisely because of these factors.

However, the current GPKI certificate verification server has several problems:

(1) Certificate verification servers used for GPKI are only in use among government agencies, and have yet to be adopted into an overall Digital Government scheme.

(2) There is a lack of standardized access protocols for GPKI certificate verification servers.

There are reasons behind each of these problems. Related to (1) above, the response message from the certificate verification server itself is what receives the signature from the certificate verification server. This means that the user trusting the signature of the certificate verification server must be a user on the same domain as the server. In other words, to use a certificate verification server in a private setting, there must be an installed certificate verification server offered by a private certificate authority.

The reason behind issue (2) above is that no standards exist currently. The lack of standards creates a situation where it is very difficult to introduce a certificate verification server model for either private or GPKI settings (Digital Government as a whole).

As a related issue, it is difficult to develop applications using certificate verification servers, since the protocols for a GPKI certificate verification server follow independent specifications. However, the GPKI certificate verification server is used within a government agency domain, which means that when performing cross-certification internationally (as one example), there is no effect on the certificate verification request from overseas.

The IETF is working on standardization of protocols for implementations such as the GPKI certificate verification server. In addition to the IETF, the W3C is similarly proposing specifications for X-KISS (XML Key Information Service Specification), a part of XKMS which performs key management within the XML framework.

Section 3 of this report provides a description of the GPKI certificate verification server itself, as well as associated trends in standardization.

1.5　 The Importance of a Testing Environment

GPKI consists of PKI domains (authorization domains) for a multiple number of different subjects, with certificates issued to each PKI domain according to each CP/ CPS (Certificate Policy/ Certificate Practice Statement). A PKI with a multiple number of PKI domains (multi-domain PKI) can extend the PKI domains (authorization domain). However, multi-domain PKI presents certain problems when attempting to build a testing environment.

In the case of GPKI, multi-domain PKI is only part of the complexity. Also involved is a hybrid environment made up of a combination of PKI components from a variety of vendors, as well as a variety of architectures. The combination of these factors makes it difficult to structure an effective test environment. To create a completely identical test environment, one would have to pull together all of the products from every vendor at once.

Challenge PKI 2001 was a means to test the interoperability of multi-vendor and multi-domain PKI. A wide range of CA products were subject to test, and testing resulted in a certain level of successful results. However, despite the many labor hours involved in setting up a valid test environment, this environment was dismantled after testing.

Given the situation described above, the Challenge PKI 2002 put together an interoperability test suite capable of simulating a certificate authority given a number of general arbitrary specifications. This interoperability test suite was able to create an arbitrary profile certificate required by GPKI, CRL and OCSP responder message, as well as being able to simulate a GPKI bridge certificate authority, an existing government certificate authority, a private certificate authority, and a commercial registration certificate authority.

Figure 1-3 illustrates the structure of the Interoperability Test Suite.

Figure 1‑3 Structure of Interoperability Test Suite

Section 7 offers a further description of the above-mentioned interoperability test suite.

1.6　 The Importance of Test Cases and Test Criteria

Discussions related to the security of systems using PKI point to the importance of encryption strength and the management and audit of certificate authorities. Meanwhile, it does not appear that much concern has been given to whether Digital Government applications operate in conformance with GPKI specifications. Naturally, if actual Digital Government applications do not comply with specifications required by GPKI, security cannot be assured. Of particular importance is the handling of all manner of constraint extensions related to path verification for multi-domain PKI such as GPKI.

For multi-domain PKI, all manner of constraint extensions are handled in the path verification for a variety of certificates issued from a wide range of domains. These constraint extensions are established by the X.509 V3 certificate extension, and it is very important that the certification path processing subject to this constraint extension is conducted in a way that complies with the original objective of the certification. If an error occurs during this processing, a certificate with a low level of assurance could be mistakenly accepted by an entity requiring a higher level of assurance.

Testing conformity with the GPKI specification would be easy if general-purpose test cases were available. Unfortunately, designing valid test cases for this situation is extremely difficult. To design test cases, a developer must be intimately familiar with the many standards (explained in Section 2, below) involved, as well as with the GPKI Interoperability Specification, and other documentation. Not only must one understand the standards and specifications involved, but one must also be aware of the problems in developing and running a test environment, which is in and of itself a very complex and time-consuming project.

The Challenge PKI 2001 performed interoperability tests for multi-vendor PKI, and included the design of test cases for the test environment constructed for the project. However, these test cases relied solely on the test environment set up specifically for the Challenge PKI 2001, and the test environment itself was dismantled at the conclusion of the tests. Consequently, re-testing the test cases designed for Challenge PKI 2001 cannot be accomplished quickly or easily.

Challenge PKI 2002 attempted to resolve the problem by developing an easily constructed test environment for an interoperability test suite. In addition, test cases were designed to be re-usable. Challenge PKI 2002 took advantage of the abundance of test case designs and test criteria creation references available from overseas sources in designing its own test cases.

Section 4 contains a description of actual PKI interoperability test criteria used in overseas testing. In addition, Section 8 includes an overview of a test case designed for Challenge PKI 2002. A detailed description of the test case itself is available separately in the "GPKI Test Case Design Sheet".

1.7　 Implementation of Path Construction, Path Verification

Standards and specifications without accompanying implementations are hardly worth the time and effort that go into creating them in the first place. In the past the IETF and other standards organizations drafted simplified specifications for suggested protocols, allowing concurrent implementation to confirm their validity. In the next stage, the suggested protocols go through a process to resulting in more precise standards. However, today's high level security demands are of a complexity that requires highly specialized knowledge and skills to implement.

Challenge PKI 2002 demonstrated sample implementation methods for path construction and path verification using already-existing components. In addition to demonstrating this implementation, this report also provides an explanation of an implementation based on specifications required by GPKI. We expect that such a demonstration will aid in providing a greater understanding of the standards and specifications themselves.

Many current path verification implementations conform to RFC2459, the prior version of RFC3280. However, all of these implementations amount to nothing more than a subset of RFC2459. The following illustrates the major relationships among specifications required for the CryptoAPI up through Windows 2000, Windows XP CryptoAPI, and the Certificate Path Library and GPKI added to JDK 1.4.

Table 1‑1 Relationships among Implementation Types and Functions Offered

	Microsoft CryptoAPI Win-2000	Microsoft CryptoAPI Win-XP	JDK1.4 Cert. Path lib.	Sample Implementation	GPKI req's (path construction, verification)
Basic Constraint Extensions	○	○	○	○	Necessary
Policy Constraint Extensions	×	○	○	○	Necessary
Policy Mapping Extensions	×	○	○	○	Necessary
Name Constraint Extensions	×	○	○	○	Necessary
AIA EXTENSIONS / OCSP	×	×	×	○	Necessary (Gov't only)
Dynamic Path Construction	×	△	○	○	Necessary
*CRL IDP 1**	×	○	×	○	Necessary

The path construction and path verification for these Java/ JDK and Microsoft CryptoAPI implementations are provided by a security framework provider. GPKI is handed off from the aforementioned provider to a separate GPKI provider. This setup allows for PKI applications to conform to GPKI without creating the need to change the applications themselves.

For Challenge PKI 2002, a GPKI sample implementation was conducted in which the switchover was made to a GPKI compatible provider. The GPKI compatible provider has implemented X.509 Certificate V3 extension, CRL V2 extension, and OCSP certificate revocation verification required by the GPKI Interoperability Specification.

The Java JDK 1.4 provides a reference implementation of a path verification library compatible with PKIX (namely, RFC 3280). FigureFigure 1‑4 Java Path Verification Library1-4 shows the structure of a path verification library with a provider capable of supporting GPKI.

Figure 1‑4 Java Path Verification Library

The Microsoft CryptoAPI has been designed with an interchangeable cryptographic module, eliminating reliance on applications using PKI. For example, if one is using a hardware token such as an IC card, the module relying on the IC card can be integrated as a CSP (Cryptographic Service Provider). In the same fashion, a Revocation Provider can be substituted for a CSP to perform certificate verification, which was the method adopted for the sample implementation.

Figure 1-5 shows a CryptoAPI implementation.

Figure 1‑5 CryptoAPI-based Implementation

Section 5 provides a more detailed explanation about the path verification library provided standard in Java currently, and a discussion of a Java sample implementation.

Section 6 discusses the current state of Microsoft's CryptoAPI, and demonstrates a sample implementation.

1.8　 Other Objectives, Conclusions

Multi-Domain PKI Problems	Explanation	Challenge PKI 2002 Objectives
Vague Standards	Multi-Domain PKI, etc. references new standards, the vagueness of which causes problems.	Clarify vague portions through implementations and testing, provide feedback to IETF/ PKIX. Make announcements at periodic IETF meetings. 54^th IETF: Yokohama; 55^th: Atlanta; 56^th: San Francisco
Test Criteria	Even with Multi-Domain PKI implementations, relatively few test cases exist, and it is unclear whether they conform to standards.	Mainly design test cases for GPKI. Create easy-to-extend test cases, making it possible for testing outside of GPKI.
Test Environment	Extremely difficult to construct Multi-Domain PKI test environments.	Develop and deliver PKI Interoperability Test Suite targeting Multi-Domain PKI. Simulate many CA environments on one Linux machine.
Reference Implementation	Difficult to understand certificate verification implementations required by Bridge model (GPKI, etc.)	Offer reference sample implementation for Microsoft platform and Java environment. Test and publish results.
Clear, Concise Explanatory Documents	Difficult to understand relationships among standards, tests, implementations, and future direction of technology.	Create reports explaining X.509 and RFC3280 standards, test cases, and implementations.
Shared Test Platforms	Difficulty in creating Multi-Domain PKI test environment not limited to Japan. Need for a world-wide shared test platform.	Examine feasibility of exporting test suite overseas. Advise IETF related to test standardization; examine feasibility of making test DB an Informational RFC.

2 Standards and specifications for certification path construction and path verification

2.1　 Overview of Certification Path Construction and Path Verification

A certificate determines the substance of a certain public key depending on its purpose, while the certificate authority (CA) issues a signature. The following is an example:

1． When a signer signs a certain piece of data, it signs with its own private key.

2． A certificate issued by the public key corresponding to the private key is attached.

3． Signed data is transmitted.

4． The party verifying the signature uses the public key embedded in the attached certificate to perform verification on the data to be verified. If the signature is correct, the attached certificate is verified.

The following is necessary when the certificate is verified as in step 4., above.

1. Certification Path Construction
A certificate chain is created from the verifier's trust anchor to the certificate being verified. Information is collected to ascertain whether the certificate(s) included in the certificate chain has been revoked.

2. Certification Path Verification
Regarding all the certificates in the certificate chain created during certification path construction:

1. Certificate has not expired as of the time of verification

2. Certificate has not been revoked

3. Constraints within the certification path (path length, naming constraints, etc.) are not violated

4. Ascertain the existence of a valid certificate policy

This section details the standards and specifications related to certification path construction and path verification.

2.1.1 Path Construction Overview

Certification path construction is the process when one wishes to verify the signature of a certain signer, the trust point certificate (trust anchor)—or the key information—of the party desiring the verification (verifier) and the public key certificate of the signer subject to verification are combined as input used to acquire an intermediate certificate from a database ("repository") linking the certificate issuer (issuer) and the name of the subject and/or the signature and signing key. Through this process a certificate chain is obtained forming a chain from the trust anchor to the digital signature of the certificate signer.

If the path cannot be created, the signature of the signer is determined to be invalid.

Figure 2‑1 Certification Path

Figure 2-2 shows the flow of path construction and path verification. The trust anchor (TA) certificate (the trust point of the verifier) and the certificate of the signer who is the subject of verification (end entity, or EE, certificate) are inputs used by the path construction algorithm to construct the certificate chain linking the names of the certificate issuer and subject. Narrowly defined, path construction is used to acquire the certificate chain; however, in a broader sense path construction can also be viewed as a means to obtain revocation information (from ARL, CRL, OCSP and other information).

Inputting the "verification policy" (a prerequisite for performing verification) and the certificate path into the path verification algorithm allows for verification of the validity of each individual certificate existing in the path, resulting in a determination of the validity of the signer's certificate.

Figure 2‑2 Path Construction and Path Verification Flow

2.1.2 Path Verification Overview

Certification path verification is the term used to describe the process of determining whether each certificate in the certificate chain (created during the aforementioned certification path construction) fulfills the following requirements:

(1) Signature Verification (including name chain)

Does the name chain link properly? Is the signature correct?

(2) Expiration Date Check

Is the certificate valid (not expired)?

(3) Policy Control

Has the criteria required by the certificate's issuance policy been met? Can different criteria for each certificate authority be handled correctly (= policy mapping)?

(4) Other Constraints (CA flag, path length constraints, namespace constraints, key usage, etc.)

Is the certificate for the correct certificate authority? Does the certificate subject's name meet the defined namespace constraints?

(5) Revocation Verification

Is the certificate in question included in the certificate revocation list (CRL)?

2.1.3 Certificate Profile, CRL Profile

The certificate and the CRL form one structured data file. Figure 2-3 illustrates a certificate structure.

Figure 2‑3 X.509v3 Certificate Structure

The extensions in the extended partition have an important significance in PKI path construction and path verification. The Certificate Profile determines what extensions can be in the basic fields, issuer's signature, and extended partition that forms the structure of a certificate. Defining a Certificate Profile allows setting limits to the usage rules of a general-use X.509 certificate, and allows for the strict and simplified implementation of applications.

In addition, the CRL consists of the following structure. The CRL also has an associated profile (called the CRL Profile), providing the same capability for rule limitations and application implementation as with the Certificate Profile.

Figure 2‑4 CRLv2 Structure

2.2　 ITU-T and IETF PKIX Working Groups

The main standards related to PKI are the international standards drafted by the ITU-T (International Telecommunication Union Telecommunication Standardization Sector) and the ISO/IEC JTC1, as well as the standards the IETF (Internet Engineering Task Force) PKIX-WG established to work on issues related to Internet-based PKI. The ISO/IEC JTC1 is established cooperatively by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC).

Table 2‑1 ITU-T and IETF RFC Characteristics

Organization	Document	Features
ITU-T	X.509 4th	Foundation for PKI usage
IETF PKIX	RFC series	Modify X.509 4^th for Internet; some simplifications, extensions

The latest ITU-T specification has been published in X.509 4^th Edition (see cited works "X509.4"), and the latest PKIX specification has been published in the RFC series, including RFC3280 and RFC2560.

The ITU-T X.509 specification is based on the X.500 directory, while the RFC (from the IETF's PKIX-WG) was conceived as a more Internet-oriented specification for PKI usage. Although these specifications were created with nearly identical goals, each has subtle differences that must be understood in order to implement path construction and path verification correctly.

Figure 2‑5 ITU-T and IETF Specification Genesis

2.2.1 ITU-T X.509 4^th Edition

The X.509 4^th Edition ("X509.4") was published by the ITU-T in October 2001 (the actual text is dated March 2000). A summary of the contents is listed below:

l Public Key Certificate Framework

l Attribute Certificate Framework

(PMI:Privilege Management Infrastructure)

l Public Key Certificate and Attribute Certificate Directory Framework

Table 2‑2 X.509 Version

X.509 Edition	Certificate Format	CRL Format	Comments
1^st Edition 1988	V1	V1	V1 format exists for old top CA certificate
2^nd Edition 1994	V2	V1	Mostly not used
3^rd Edition 1997	V3	V2	14 (v3) standard extended fields
4^th Edition 2000	V3	V2	8 standard extended fields added ※1

※1: Standard extension fields added in X509 4^th Edition

【certificate 】inhibitAnyPolicy, freshestCRL

【CRL】crlScope,orderedList,crlStreamIdentifier,

statusReferrals, baseUpdateTime,deltaInfo

2.2.2 IETF PKIX-WG

The IETF PKIX Working Group was established in 1995, engaging in activities related to the usage of X.509-based PKI on the Internet. One must refer to several RFCs in order to understand the path construction and path verification contained in PKIX. Table 2-3 outlines the particularly important details.

Table 2‑3 RFC Necessary for PKI

RFC	Details
3280	Certificate, CRL profile, path verification algorithm
2459	(old) certificate, CRL profile, path verification algorithm
2587	LDAPv2 PKI schema
2585	Uses HTTP, FTP for certificate repository
2560	OCSP (online certificate status confirmation service)
[pkix-ldap3-draft]	LDAPv3 PKI schema (draft)
[pkix-rmap]	Future PKIX Working Group developments

2.3　 Certification Path Construction

In certification path construction, the self-signed certificate of the certificate authority at the verifier's trust point (= trust anchor) and the public key certificate of the signer are the inputs forming each end of the chain (issuer and subject), creating a certificate chain referencing the issuer and subject at each end.

The following is an overview of certification path construction:

· Look up the subject name and issuer name contained in the certificate.

· Acquire the certificate from the chain originating from the repository.

² Acquire the certificate from the directory. (or)

² Acquire the certificate using other protocols such as HTTP and FTP.

To discern the content of a certificate, one must understand the Certificate Profile; to acquire a certificate from a directory, one must understand directory schema; and to acquire a certificate from repositories other than a directory, one must understand the acquisition method. We address these issues in this section.

2.3.1 Certificate Profile Necessary for Path Construction

The following table lists basic field attributes and/or extensions used in certification path construction within the certificate profile.

Table 2‑4 Certificate Attributes Necessary for Path Construction

	Primary Partition Attribute Names/ Extension Names	Details
Primary Partition	Issuer	Certificate issuer name
	Subject	Certificate subject name
	AuthorityKeyIdentifier	Key identifier for issuer signing key
	SubjectKeyIdentifier	Subject's public key identifier
	authorityInformatinoAccess ※1	Issuer information location
	subjectInformationAccess ※1	Subject information location
	cRLDistributionPoints ※2	CRL distribution point
	Freshest CRL ※2	Delta CRL distribution point

※1:Only IETF extension ([RFC3280] sections 4.2.2.1, 4.2.2.2)

※2:Used with path construction for ARL, CRL acquisition (broad)

As the goal is to create a certificate chain using the certificate's subject name and issuer name, the major attributes are those related to names and keys. If a multiple number of certificates exist in the repository, the value of the AuthorityKeyIdentifier and SubjectKeyIdentifier extension (if it exists) can be used to target the certificate comprising the path.

Refer to Section 3 for more information related to the certificate profile.

A new authorityInformationAccess (AIA) extension was added to "RFC2459". This extension stores an attribute value making it possible to directly acquire a certificate from a certificate authority, and to designate the location of the OCSP responder (see Section 2.6) capable of verifying the certificate on-line. The extension is only valid for the IETF standard, but use of this extension can greatly facilitate path construction. The AIA attribute values are summarized below (See "RFC3280" Section 4.2.2.1).

Table 2‑5 Attribute Values for authority Information Access

AIA Attribute

Value Types

Details

cAIssuer

Information for CA issuing certificate. If directory name is designated, CA certificate is included in crossCertificatePair attribute value of the entry with that directory name.

ocsp

URI of OCSP responder capable of verifying that certificate

2.3.2 Directory Schema

The repository from which the certificate and revocation list is acquired generally utilizes a directory service.

A description of the PKI schema definition can be found in Chapter 11 of the ITU-T X.509 4^th Edition ("X.509.4"). The IETF's LDAPv2 PKI schema is located in Chapter 3 of the "RFC2587" referenced in Cited Works at the end of this report.

PKIX-WG is in the process of consolidating the content of "RFC2587" and "RFC2256", and drawing up the "pkix-ldap3 draft", which includes a schema definition corresponding to LDAPv3. Chapter 3 of this draft contains a definition of the new schema, which is being revised to conform to "X.509.4".

Developers must pay attention to the attributes related to the CA certificate and revocation information for path construction.

Table 2‑6 Schema Necessary for Path Construction

Drafting Organization			ITU-T	IETF PKIX-WG
Specification			X.509 4^th	RFC2587+ RFC2256	Draft
Directory Service			X.500	LDAPv2	LDAPv3
	Purpose	Directory Attribute Name
Path Construction	EE certificate	userCertificate ※2	○	○	○
	CA certificate	cACertificate ※3	○	○	○
	CA certificate	crossCertificatePair	○	○	○
	Temp path storage	pkiPath	○		○
Path Verification	Revocation information	authorityRevocationList	○	○	○
		certificateRevocationList	○	○	○
		deltaRevocationList	○	○	○
	Policy	certificatePolicy	○		○
		cpPointer	※1		○
		cps,certificationPracticeStmt	○		○
		cpsPointer	※1		○
	Other	supportedAlgorithms	○		○

※1: Does not exist as an attribute, but can be obtained from the higher tier attributes.

※2:The object class containing these attributes is the strongAuthenticationUser according to the "RFC2256" issued by the LDAP working group. This is pkiUser in the PKIX's RFC and "X.509.4".

※3:The object class containing these attributes is the certificationAuthority according to the "RFC2256" issued by the LDAP working group. This is pkiCA in the PKIX's RFC and "X.509.4".

The pkiPath attribute is new to the "X509.4" and "pkix-ldap3 draft". This new attribute can be used to make more efficient path construction by preserving the cross-certification certificate details (or part thereof) of the certification path leading to other CAs that are frequently used.

Chapter 2 of the "RFC2587" indicates that one must note that the dynamic nature of the LDAP object class specification means that required attributes for "X.509.4" may be optional in PKIX, and therefore the attribute may not necessarily be contained in an entry.

One cannot find any such indication in the succeeding "pkix-ldap3 draft".

2.3.3 Differences in Repositories

To construct the certification path linking the trust anchor and the end entity certificates, an intermediate certificate and revocation list must be acquired from a repository (see the definition of repository at "RFC2585" Section 1.1").

Table 2-7 offers a comparison of the protocols used to acquire the necessary certificate/ revocation information used for path construction from the repository. In "RFC2585" Section 1.2 the Internet-oriented PKIX indicates, "The directory is…the normal distribution mechanism for certificates to be acquired from repositories. However, Directory Services are not available in many parts of the Internet today. The File Transfer Protocol (FTP) and the Hypertext Transfer Protocol (HTTP) offer alternate methods for certificate and CRL distribution."

Table 2‑7 Comparison of Repository Access Protocols

ITU-T X.509.4th

IETF PKIX RFC

Certificate, CRL repository

X.500 directory

※URI for revocation list can be designated, protocol cannot be designated

LDAPv2(schema rfc2587,protocol rfc2559)

Reference available URI

HTTP (RFC2585)

Ex. http://www.your.org/pki/id22.{cer,crl}

FTP(RFC2585)

Ex. ftp://ftp.your.org/pki/id48.{cer,crl}

2.3.4 The IETF PKIX-WG Roadmap

The PKIX-WG plan has been presented in the form of a roadmap. Section 5.1.3 (cited works "pkix-rmap") discusses two items related to certification path discussion.

l Regarding Authority Information Access Extensions for Certificates

Various arguments were put forth concerning the method to use to efficiently obtain the CA certificate in cases where the CA and/or the CA repository is not easily acquired from the certificate's subject name. A final determination was made to use the certificate's Authority Information Access extension to contain the "access method and location of the CA's information and services". Implementing this scheme means that the issuer's certificate can be acquired (facilitating path construction), even in cases where the subject name and the directory name do not agree. (Reference "RFC3280" Section 4.2.2.1 AIA)

l Selection of cACertificate and crossCertificatePair from an Identical Certificate Registration Domain

After much debate about whether to place the certificate authority (CA)'s PKC in the cACertificate attributes within the directory or in the crossCertificatePair (CCP), the following two methods have been promoted:

· [Method 1]

² Only a self-signed certificate for the cACertificate

² Certificate to this CA for the CCP's issuedToThisCA element

² Certificate from this CA for the CCP's issuedByThisCA element

· [Method 2]

² All certificates to this CA for the cACertificate

² Certificate to this CA from other domains for the CCP's issuedToThisCA element

² Certificate to CA of other domain from this CA for the CCP's issuedByThisCA element

Method 2 is much more efficient, but both methods are in wide use currently. Accordingly, the PKIX-WG came up with a proposed Method 3 as a compromise. This method supports implementation of either Method 1 or Method 2:

· [Method 3: Adopted Suggestion]

² Certificate from the CA's self-signature and identical domain for the cACertificate

² All certificates to this CA for the CCP's issuedToThisCA element

² All certificates from this CA for the CCP's issuedByThisCA element

2.4　 Certification Path Verification

Signature verification, expiration date check, policy and other constraint handling, and revocation verification are all performed during path verification. Refer to Section 2.5 regarding revocation verification.

Chapter 10 of "X.509.4" (see Cited Works) offers a detailed explanation of the certification path verification algorithm of the X.509 4^th Edition. The path verification algorithm for RFC3280 is described in Chapter 6 of "RFC3280" (see Cited Works). Section 6.1 of that document details the basic verification algorithm. Section 6.2 states, "…the path validation algorithm presented in Section 6.1 defines the minimum conditions for a path to be considered valid...Depending on the application, the algorithm may be extended."

Table2-8 illustrates the differences between the input, state variable, process details, and output between X.509 4^th Edition and RFC3280. (Note: Particularly important differences are marked with a ○ symbol.)

Table 2‑8 Differences between X.509 4^th and RFC3280 Path Construction

ITU-T(X.509 4^th Edition)

IETF PKIX(RFC3280)

Input

Collection of certificates forming path

Trust anchor information

Initial values for policy verification

Current time and date (as necessary)

Collection of certificates forming path

Trust anchor information

Initial values for policy verification

Current time and date

Expected certification path length: "n"

State Variable

Policy verification:

○Policy state in table format

○No critical flag processing

for name constraint

path length management

Policy verification:

○Policy state in tree format

○Critical flag in node

for name constraint

path length management

○Issuer and public key during operation

process issuerUniqueIdentifier

(※not used under GPKI)

Processing

Details

Verify certificate validity

Verify basic constraints

Policy verification

Name constraint verification

Verify certificate validity

Verify basic constraints

Policy verification

Name constraint verification

Output

Pass/ fail flag

Policy verification status (table format)

Error codes

Pass/ fail flag

Policy verification status (tree format)

Error codes (no description)

Minor

Differences

No description of keyUsage processing

No critical flag processing

No clarification of subjectAltName name constraint

As seen in Table 2-8, though some minor differences exist, the input, state variable, process details, and output are largely the same, with the only difference being whether the data structure for storing the policy state is a table format or a tree structure. The important fact is that the results are exactly the same in either case.

2.4.1 Certificate Profile Necessary for Path Verification

Table 2-9 summarizes the basic field attributes and extensions in the Certificate Profile needed for path verification.

Table 2‑9 Basic Field Attributes and Extended Field Attributes Necessary for Path Construction

	Partition	Attribute Name	Details
Signature verification	Signature		Certificate issuer signature
	Basic	Signature	Signature algorithm
	Basic	Issuer	Certificate issuer identification name
	Basic	Subject	Certificate subject identification name
	Basic	subjectPublicKeyInfo	Subject public key information
	Extension	authorityKeyIdentifier	Certificate authority key identifier
	Extension	subjectKeyIdentifier	Subject key identifier
	Extension	subjectAltName	Subject alternate name
	Extension	issuerAltName	Issuer alternate name
Expiration	Basic	Validity	Expiration date
Policy constraints	Extension	certificatePolicies	Certificate policy
	Extension	policyMappings	Policy mapping
	Extension	policyConstraints	Scope of policy influence within path
	Extension	inhibitAnyPolicy	Do not allow anyPolicy
Other Constraints	Extension	basicConstraints	Basic constraints (CA, path length)
	Extension	nameConstraints	Name space constraints
	Extension	keyUsage	Key usage purpose
	Extension	extendKeyUsage	Extension key usage purpose
Revocation Verification	Basic	serialNumber	Certificate serial number
	Basic	Issuer	Certificate issuer identification name
	Extension	cRLDistributionPoints	CRL distribution point
	Extension	freshestCRL	Delta CRL distribution point
	Extension	authorityInformationAccess	Issuer information (for OCSP)

2.4.2 X.509 4^th Edition Policy Verification

One major characteristic of the X.509 path verification algorithm is the use of table formatted data for policy verification. Figure 2-6 is an illustration of a simple policy verification using table formatted data. (Note: The process of the policy modifier has been omitted for the sake of clarity.)

Figure2‑6 X.509 4^th Policy Verification (Certification Path Example)

Figure 2‑7 X.509 4^th Policy Verification (Initial State)Figure 2‑8 X.509 4^th Policy Verification (Loop)

Figure 2‑9 X.509 4^th Policy Verification (Post Processing)

The end of the "X.509.4" Section 10.2 related to the output of the path processing procedure warns that even if the verification algorithm succeeds, a determination must still be made whether to accept this result based on other information in the policy modifier and certificate. "RFC3280" does not mention the need to make a separate determination of the results from the policy modifier.

2.4.3 RFC3280 Policy Verification

One major characteristic of the RFC3280 path verification algorithm is the use of a tree structure for the policy verification data format. Figure 2-10 illustrates a simple policy verification process. (Note: The critical flag and policy modifier processes have been omitted for the sake of clarity. Also, the tree structure branches are depicted extending from left to right for easier viewing.)

Figure 2‑11 RFC3280 Policy Verification (Certification Path Example)

Figure 2‑12 RFC3280 Policy Verification (Initial State)

Figure 2‑13 RFC3280 Policy Verification(Loop)

FFigure 2‑14 RFC3280 Policy Verification (Post Processing)

2.5　 CRL Revocation Verification

Either a CRL-based method or an OCSP-based method can be used for certificate revocation verification. The OCSP method is covered in Section 2.6. This section addresses revocation verification utilizing CRL.

Annex B of "X.509.4" discusses CRL type identification, acquisition of the appropriate CRL, and verification of the CRL validity. Section 6.3 of "RFC3280" covers the certificate revocation verification algorithm utilizing CRL. This section covers all of the aforementioned subjects in detail.

2.5.1 CRL Type Identification and CRL Validity Verification in X.509 4^th Edition

CRL is a mechanism to determine whether a verifying party can trust a certificate. Unfortunately, due to the issues detailed below, acquiring a CRL to verify a certificate is not a completely simple matter: (Refer to Section 10.5 for a summarization of "X.509.4" CRL types.)

· Depending on the certificate authority, sometimes the following methods are used to prevent a CRL from becoming too large:

² Use of a delta-CRL

² Separate a CRL into one for certificate authority use and one for end entity use

· A single certificate authority CRL is used in some cases, while a multiple certificate authority CRL may be used in other cases.

Since there are cases where the CRL is divided depending on the target, it can be difficult to determine which CRL needs to be referenced for a particular certificate verification. Because of this, "X.509.4" provides a crlScope extension that can store information related to the scope of the certificate managed by the CRL. ("RFC3280" does not define this extension.)

Annex B of "X.509.4" describes an algorithm to identify the CRL type and acquire the appropriate CRL, even if there is no crlScope extension.

The certificate user may store the following types of basic CRL, depending on the CRL issuance policies of the issuance authority:

· Complete CRL for all entities

· Complete EPRL

· Complete CARL

· Distribution Point Based CRL/EPRL/CARL

"X.509.4" Annex B 5.1 discusses methods to determine the category of a CRL.

In addition, the freshestCRL extension of the certificate is very important. In instances where the certificate user policy supports delta-CRL confirmation, delta-CRL processing will be available to the certificate user. Annex B 5.2 of "X.509.4" describes the method used to confirm whether the delta-CRL is appropriate.

In order to perform basic CRL revocation verification, the CRL in question must be completely unmodified since its distribution, as well as fulfill the conditions below:

(1) The certificate user must be able to obtain the public key of the CRL issuer, and must be able to use the public key to verify the signature of the CRL. (CRL signature verification)

(2) If the nextUpdate field exists, the field time/date recorded in the field must be later than the current time/date.(confirms the latest CRL)

(3) The issuer name written in the CRL must match the issuer name of the certificate subject to revocation verification.※

※Except for cases where the CRL is acquired from a location indicated by the certificate's CRL DP, and the CRL DP extension includes the CRL issuer element. In this case, the CRL issuer element and the issuer name of the CRL must match.

In addition, to perform delta-CRL revocation verification, the CRL in question must be completely unmodified since its distribution, comply with (1) and (2) above, and meet the following condition:

(4) The issuer name included in the delta-CRL must match the issuer name of the certificate subject to revocation verification. (delta-CRL verification)

See "X.509.4" Annex B 5.3 and 5.4 for a detailed description of conditions (1) through (4).

2.5.2 The RFC3280 Certificate Revocation Verification Algorithm using CRL

The certificate revocation verification algorithm using CRL requires the following input:

/certificate (certificate serial number and issuer name)

/delta-CRL use/ non-use(use-deltas flag)

The revocation verification algorithm initiates verification processing, assuming that the supplied certificate has not been "revoked". The CRL check continues until either a determination has been made that the certificate has been revoked, or until the completion of a CRL check sufficiently covering all of the reason codes.

Revocation verification is performed along the following steps for the local CRL cache corresponding to each CRL for each distribution point of the certificate CRL distribution point (DP) extension.

Step (1) acquisition of revocation information (CRL, delta-CRL)

Step (2) verification of the revocation list

Step (3) verification of revocation reasons (reasons_mask)

Step (4) path verification of the revocation list issuer

In Step (1), the CRL and delta-CRL are acquired, and the local CRL cache is updated as necessary.

In Step (2), the CRL issuer and scope are verified. Also, if a delta-CRL is used (use-deltas flag is set), the issuer and scope of the delta-CRL is verified.

In Step (3), the CRL-supported revocation reasons (interim_reasons_mask) are aggregated. Next, a verification is conducted to determine if this set contains one or more reasons not included in the heretofore processed revocation reason aggregation.

In Step (4), the certification path for the CRL issuer is acquired/ confirmed, and the signature in the CRL is also confirmed.

Performing the preceding processes determines the revocation status, returning the cert_status element. If the revocation status was not determined, the above-mentioned process is repeated using all of the possible CRLs issued from the certificate issuer (though this is not clearly demonstrated by the distribution point). If the revocation status is still not determined, then the process will return UNDETERMINED.

Section 6.3 (CRL Validation), paragraphs (a) through (k), of the "RFC3280" contain a detailed description of Steps (1) through (4) described above.

2.6 RFC2560 OCSP

This section addresses verification methods using OCSP.

2.6.1 Validity Confirmation through OCSP

During the certification path verification process, the certificate forming the certification path must be checked for current validity. In general, a CRL issued by a certificate authority is used as the means for conducting this certificate validity confirmation. However, validity confirmation utilizing a CRL poses several possible problems:

・ Performance
As the number of certificates issued by the CA increases, there is a proportionate increase in the number of revoked certificates, resulting in significant increases in the size of the CRL itself. As the CRL grows larger, more time is required to download the entire CRL, resulting in longer wait times for certification path construction and path verification.
Furthermore, to verify the certification path, validity confirmation must be performed for all intermediate certificates and user certificates included in the certification path, which means that a multiple number of CRLs must be obtained and searched, making the process of certification path verification even longer.

・ Real-Time Processing
CRLs are periodically issued by the CA. Because of this, once a CRL has been acquired, it is cached until the next update, improving certification path verification performance. On the other hand, any information related to certificate revocations subsequent to a CRL update will not be reflected until the following update, which means that certificate status cannot be confirmed in real-time.

Several solutions to these problems have been developed and are in current use. First, a CRL can be broken into several smaller fragments to reduce the size of an individual download from a CRL-DP (CRL Distribution Point). Second, a so-called delta-CRL can be distributed, consisting of only the portions of a CRL that have changed. This eliminates the need to download the entire CRL every time.

The aforementioned solutions are the basic means used reduce the size of CRL downloads used for CRL-based validity confirmation. In contrast, RFC2560 offers a standardized OCSP (Online Certificate Status Protocol) certificate validity confirmation, completely separate and independent from CRL-based methods.

Under OCSP, the verifier sends a request to the OCSP responder (OCSP server) regarding the status of a certificate. The OCSP responder then sends back a response in this client/server-based validity confirmation model.

OCSP verification has several advantages. First, the size of the request and response is small, allowing for quicker transmission. Second, the close correspondence between the CA (certificate authority) and the OCSP responder provide real-time validity confirmation for a certificate. Third, a multiple number of certificate validity confirmations can be handled in a single request/response transaction, decreasing the overall number of requests and responses for confirming the validity of a certificate forming a certification path in cases where an OCSP responder handles several certificate authorities.

Following is a more detailed explanation of the OCSP request and response cycle, as well as the OCSP responder trust model, which is indispensable to the practical implementation of OCSP. We will also include a short description of OCSPv2 currently being proposed and debated by the IETF's PKIX WG.

2.6.2 OCSP Requests

Figure 2-14 illustrates the OCSP request message format.

tbsRequest				Request
	version			Version	Perscribed Value V1(0)
	requestorName			Requestor Nmae	Option
	requestList			Individual Request(multiple)
		reqCert		Requested Certificate Information
			hashAlgorithm	Hash Algorithm
			issuerNameHash	Issuer DN Name Hash Value
			issuerKeyHash	Issuer Public Key Hash Value
			serialNumber	Certificate Serial Number
		singleRequestExtensions		Extended Partition for each Individual Request	Option
	requestExtensions			Extended Partition for Entire Request	Option
optionalSignature				Requester Signature	Option
	signatureAlgorithm			Signature Algorithm
	signature			Signature Data
	certs			Certificate(multiple)	Option

Figure 2‑15 OCSP Request Message Format

In OCSP, the goal is to limit the message size as much as possible; therefore, a certificate itself is not what is verified, but rather it is the smallest amount of information that can accurately identify the certificate that is verified. More specifically, three pieces of information are defined for the CertID element: (1) the hash value (issuerNameHash) for the name of the CA certificate authority (issuerName) issuing the certificate, (2) the hash value of the public key of the CA certificate authority (issuerKeyHash), and (3) the serial number of the certificate in question (serialNumber).

A multiple number of certificate information requests (requestList) can be defined within one request.

In an OCSP request, two types of extensions (extended partition) can be defined for each portion of certificate information or for an entire request. The extended partitions defined by RFC2560 for OCSP requests include Nonce (used to prevent reply attacks), and Service Locator (used to give the certificate's AIA extension information to the OCSP responder). The AIA extension is a certificate extension provided for by RFC2459 and RFC3280 (but not included in X.509 4^th Edition), and in cases where a certain certificate authority uses an OCSP responder, it can indicate the URI to the OCSP responder in the AIA extension of the certificate issued by the certificate authority. This provides a mechanism whereby the verifier receiving the certificate issued by the certificate authority knows where to issue the OCSP request for validity confirmation.

The verifier may also add a signature to the request, but this is generally not done.

2.6.3 OCSP Response

Figure 2-15 illustrates the OCSP response message format.

responseStatus							Response Status	successful(0) malformedRequest(1) internalError(2) tryLater(3) (4 is unused) sigRequired(5) unauthorized(6)
responseBytes							Response	Option
	responseType						Response Format	id-pkix-ocsp-basic
	response						Response Data(OCTET STRING)
		tbsResponseData					Response(entire)
			version				Version	Prescribed Value V1(0)
			responderID				Responder ID
				byName			Responder Name	Selection(String)
				byKey			Responder Public Key Hash Value	Selection(OCTET STRING)
			producedAt				Response Creation Time/Date
			responses				Individual Response (multiple)
				certID			Certificate ID
					hashAlgorithm		Hash Algorithm
					issuerNameHash		Issuer DN Name Hash Value
					issuerKeyHash		Issuer Public Key Hash Value
					serialNumber		Certificate Serial Number
					serialNumber		Certificate Serial Number
				certStatus			Certificate Status
					good		good	Selection(NULL)
					revoked		revoked	Selection(SEQUENCE)
						revocationTime	Revocation Time/Date
						revocationReason	Revocation Reason	Option
					unknown		unknown	Selection(NULL)
				thisUpdate			Expiration of Status (from)
				nextUpdate			Expiration of Status (to)	Option
				singleRequestExtensions			Extended Partition for each Individual Request	Option
			responseExtensions				Extended Partition of Entire Response	Option
		signatureAlgorithm					Signature Algorithm
		signature					Signature Data
		certs					Certificate (multiple)	Option

Figure 2‑16 OCSP Response Message Format

The first part of the response message contains the responseStatus (status of the response), and the actual response message (responseBytes) will follow only if the responseStatus has been successful.

The response message contains the responseType (type of response message), but at the current moment, only the id-pkix-ocsp-basic response type (Basic response) has been defined formally.

The Basic response header contains the response format version (version) and OCSP responder information (responderID), as well as the time/date information related to when the OCSP responder created the response. After this information, the response information for each individual certificate is listed.

The CertID and certificate status (certStatus) for each certificate(s) in question, as well as the status expiration date (thisUpdate, nextUpdate) is included in the response information for each certificate. The certificate status is determined as good (valid), revoked (expired), or unknown. An unknown status may occur in cases where the OCSP responder cannot correspond with the certificate authority that issued the certificate.

As with the request message, the OCSP response has an extended partition for each certificate and one for the entire response. Extended partitions provided for by RFC2560 include CRL references, which return information from the referenced CRL when the OCSP responder is determining the status.

A signature from the OCSP responder is always included in the OCSP response. This signature is used by the OCSP client to determine whether the response from the OCSP responder is trustworthy.

2.6.4 OCSP Responder Trust Model

The OCSP responder trust model deserves closer investigation as it relates to constructing the OCSP responder. This trust model supports the mechanism for the OCSP client (verifier) to trust the signature attached to the OCSP response.

In general, three different types of OCSP responder trust models exist:

・ Direct CA Trust Model(Figure 2-16)
Under this model, the OCSP client only trusts the CA directly. The OCSP responder signs the response with the corresponding CA's private key.
This model is used for the Ministry of Justice's commercial registration certificate authority OCSP responder.
Under the direct CA trust model, the OCSP responder must share the same private key as the corresponding CA; however, problems can arise related to the management security for the private key. In general, the CA and the CA's private key are stored in locations not externally accessible. Unfortunately however, if the OCSP responder cannot be directly accessed from external sources, it cannot accomplish its original purpose. Consequently, the challenge is allowing external access to the OCSP responder while attempting to preserve private key security.
In addition, it is fairly common to use a long key in order to extend the expiration date of a CA certificate, but longer keys mean that it takes longer to sign the OCSP response, likely degrading the performance of the OCSP responder server.

・ Figure 2‑17 Direct CA Trust Model

・

・ Direct VA (Validation Authority) Trust Model(Figure 2-17)
This is a model whereby the OCSP responder issues a self-signed certificate, and the OCSP client directly trusts the certificate from the OCSP responder (VA).
Directly trusting the certificate from the OCSP responder leads to the same key management issues identified in the prior model. In addition, the key length is increased in order to raise the level of OCSP responder certificate trustworthiness, leading to possible server performance issues.

・ Figure 2‑18 Direct VA Trust Model

・ CA Delegated Model(Figure 2-18)

Figure 2‑19 CA Delegated Model

2.6.5 OCSPv2

OCSP was standardized as RFC2560 in June 1999 by the IETF's PKIX WG. Since then, several problems have been pointed out related to actual operation. In addition, the group has also recognized the need for compatibility with the newly instituted attribute certificate.

To overcome these OCSP-related problems and add new functions, OCSP Version 2 (OCSPv2) that expanded the function of OCSP was proposed to the PKIX in December 2002.

OCSPv2 has the three following major characteristics:

・ Compatibility with attribute certificates
Facilitate validity confirmation for not only the certificate, but for the attribute certificate as well (no special protocol-related extensions).

・ CertID extension
Added as two options for methods to designate certificate subject to certification in addition to CertID. One method is to send the certificate in its entirety. The other method consists of sending the certificate issuer's name and serial number, the tbsCertificate element hash values, and the certificate signature.

・ Designating CRL reference information
By adding the crlLocator extension, the OCSP client can designate the OCSP responder by copying the CRL reference information (this CRL stores revocation status of the certificate in question) from the CRL distribution point extension (CDP) of the certificate.

2.7 GPKI Interoperability Specification

This section offers a discussion of the GPKI Interoperability Specification.

2.7.1 GPKI Overview

One feature of GPKI is the performance of cross-certification through a BCA (bridge CA) between a government CA and private CA. Since cross-certification is conducted via differing domains, processing must take place according to shared specifications within the framework of GPKI.

Figure 2-19 illustrates a conceptual overview of interoperability across differing domains through a BCA.

Figure 2‑20 Conceptual Overview of BCA Interoperability

2.7.2 Component Specifications/ Structure

Here we will comment on the main functional requirements of components comprising GPKI necessary to ensure interoperability related to applications using GPKI.

/Functional requirements

1. BCA

² ―Issues self-signed certificates, CRL/ARL, cross-certification certificates

² ―Stores self-signed certificates, CRL/ARL, and cross-certification certificate pairs in a repository

² ―CA key update functions

2. Government, Private CA (PCA)

² ―Issues self-signed certificates, CRL/ARL, cross-certificate certificates, EE certificates

² ―Stores self-signed certificates, CRL/ARL, cross-certificate certificate pairs in a repository

² ―CA key update functions (option)

3. Repository

² ―Searches certificates, CRL/ARL

² ―Referrals to other repositories

4. OCSP responder

² ―Receives certificate verification request from certificate owner, and returns verification results

5. Certificate verification server

² ―Receives certificate verification request from signature verifier, and returns verification results

² ―Certification path construction, verification

6. EE (End Entity)

² ―Signature and signature verification for data

² ―Acquires certificate CRL/ ARL from repository

² ―Path construction to its own domain PCA (option)

² ―Functions performing inquiries to OCSP responder and certificate verification server

Figure 2-20 illustrates a conceptual overview of the PKI components comprising GPKI.

A more detailed explanation of the components comprising GPKI is found in "2. PKI Component Specifications" in the GPKI Interoperability Specification.

Figure2‑21 Components Comprising GPKI

2.7.3 Interoperability among applications

Here, we will show the necessary functions and recommended models to ensure interoperability among applications used within GPKI.

(1) Certification path construction/ verification specification overview

Applications performing signature verification among differing domains within the GPKI framework must conduct the following tasks:

1. Path construction

2. Path verification

3. Handle various constraints conditions related to certificate policies, etc.

For more details, please refer to "3.7 Certification Path Construction and Verification Methods" in the GPKI Interoperability Specification.

(2) Repositories

When performing certification path construction and verification, the certificate and revocation information contained within the path must be acquired from the repository using LDAPv3. There are some repositories that return LDAPv3 Referral, depending on the search content accessing the repository. Applications must be able to interpret the Referral returned in the form of search results.

For more details, please refer to "3.6 Repository Access" in the GPKI Interoperability Specification.

(3) Certification path construction

It is necessary to acquire all certificates forming the certificate chain. Path construction is performed to accomplish this task. Methods to acquire these certificates come down to attaching and sending a signed document from the signing party, or the having the signature verifier accessing a repository. Several methods can be used for the signature verifier to create a certification path to the signer's certificate. The certification path construction method to move from the trust anchor of the signature verifier and back to the signer's certificate is written in detail in "3.7.2 Certification Path Construction" in the GPKI Interoperability Specification.

(4) Post key update path construction

Since the CA's private key is updated periodically, there will be several new and old keys in existence at the same time. A link certificate (self-issued certificate) is issued in order to make possible the certification path construction using already-existing valid certificates in this situation. By using link certificates, path construction for already-existing certificates is possible by linking new and old self-signed certificates.

A more detailed description of this is found in "3.7.2.6 Path Construction after Key Updates" in the GPKI Interoperability Specification.

(5) Certification path verification

Basically conforms to the "Certification Path Validation" found in RFC3280. In general, verification beginning with the certificate of the CA most trusted by the signature verifier and performing verification in the direction of the signer's end entity certificate is the most efficient and desirable method of certification path verification. Items for verification include certificate chain, certificate expiration date, signature verification, revocation verification, etc.

Please refer to "3.7.3 Certification Path Verification" of the GPKI Interoperability Specification for more details.

(6) EE model and certificate verification server model

Conducting signature verification over differing domains is complex under GPKI.

Figures 2-21 and 2-22 illustrate the EE model and the certificate verification server model, respectively, used for application models implementing signature verification.

・ EE model
A model whereby the end entity performs all of the complex processing for signature verification and certification path construction/ verification.

・

Figure 2‑22 EE Model

・
Under this model, the OCSP client directly trusts the CA only, and indirectly trusts the certificate from the OCSP responder issued by the CA. In this case, in order to clearly indicate that the CA itself has devolved the response related to the certificate status of the certificate issued by the CA to the OCSP responder, a special signifier called an OCSPSigning must be inserted into the extended key usage extension of the certificate issued vis-à-vis the OCSP responder.
In the CA Delegated Model, changes in the OCSP responder certificate do not require corresponding changes on the client side; therefore, the expiration date of an OCSP responder certificate can be set fairly short, and then frequently updated. This increases the trustworthiness of the certificate from the OCSP responder.
However, as illustrated in the Figure, this is a two-stage process wherein the certificate used for signing the OCSP response is issued from a self-trusting CA, for which verification is made as to whether the OCSPSigning has been attached. Then this certificate is used to verify the signature.

・ Certificate Verification Server Model A model wherein a certificate verification server is set up to perform certification path construction and verification, while applications run as a client of the certificate verification server.

Figure 2‑23 Certificate Verification Server Model

2.7.4 PKI Intra-Domain Specifications

The following two specifications must be met to perform interconnection with BCA for GPKI.

1. Key Update
The CA private key must be updated periodically, in consideration of the expiration date of the self-signed certificate.

2. Link Certificate
If several self-signed certificates exist in conjunction with the key update, the BCA issues a link certificate to ensure the relationship between the new-generation key pair and the old-generation key-pair, and to allow certification path construction by the existing valid certificate (after it has been updated).

Further details are available in the GPKI Interoperability Specification ("5.2.1 Key Update").

2.7.5 Profile

In this section we will introduce several characteristics of the GPKI certificate profile.

Required fields in the GPKI environment

・ policyMappings

・ keyUsage

・ certificatePolicies

・ authorityKeyIdentifier(keyIdentifier)

Other

/Ignore certificates with issuerUniqueID and subjectUniqueID fields.

See "7 Profile" in the GPKI Interoperability Specification for more details.

3 3 New Models of Certificate Path Construction/ Path Verification Server

3.1 Certificate Path Construction/ Path Verification Server Overview

As described in Section 2, in cases where the verifier receiving the digital certificate performs certificate verification, certification path construction and verification of the certification path must be performed.

In general, certification path construction and verification of the certification path require the verifier themselves to collect the information necessary for the certificate and CRL/ ARL. However, methods to perform part or all of this process on the server side are being investigated or are in current use (hereinafter, the term "certificate verification server" will be used to indicate the server performing the certification path construction and verification, while the associated client will be called the "certificate verification client").

Server-side certification path construction and path verification feature advantages such as those following:

・ Simplified implementation of the certificate verification client
By performing certification path construction and path verification on the server-side, the verifier (certificate verification client) need only conform to the communication protocols with the certificate verification server, eliminating the need for certificate and revocation information acquisition protocols, as well as the need for the verifier to perform certification path construction and path verification. One major advantage is that this makes possible the proper certification path construction and path verifications for devices such as PDAs, cell phones, and other handhelds, for which PKI application had been deemed too problematic due to resource limitations (limited processing power, memory, and communications capacity).

・ Performance
Having a high-performance certificate verification server acquiring the necessary information and conducting path construction and verification dramatically reduces the time needed to create and verify the certification path. In addition, as the server caches the certificate and revocation information acquired, the path construction and path verification requests will be processed more efficiently.

・ Path Construction/ Path Verification Uniformity
If certification path construction and path verification are performed by the verifier, differences in verifier implementation may cause differences in resulting behavior. Unifying all of these different implementations is a difficult task, to say the least. In addition, updating all current verifiers as changes are made in certification path construction and verification specifications would cost enormous amounts of time and money. In contrast, conducting certification path construction and verification on the server-side reduces operational costs, since path construction/ verification methods can be more easily unified, and changes in specifications require corresponding changes to the certificate verification server only.

Given the obvious advantages to this model, the IETF/PKIX has been debating protocols and specifications for server-side certification path construction and verification for several years. In actuality, this approach has made it possible to install a certificate verification server for each government entity, unifying the certification path construction and verification process across these servers for GPKI implementation.

In this section, we will cover the current state of standards for client-server protocols necessary to conduct server-side certification path construction and path verification. We will also address the functions and protocols of the certificate verification servers in actual use for GPKI, and make a comparison with specifications currently being considered for formal standardization.

3.2 DPV/DPD REQ

This section will provide a more detailed explanation of RFC3379 "Delegated Path Validation and Delegated Path Discovery Protocol Requirements" (hereinafter referred to as DPV/DPD REQ), standardized by the IETF's PKIX Working Group (hereinafter referred to as IETF/PKIX).

First, we will briefly cover the process leading to the formation of DPV/DPD REQ, followed by a discussion of the DPV/DPD REQ content.

3.2.1 The Process leading to DPV/DPD REQ

PKIX discussions related to a certificate verification server model began in June of 1999. Table 3-1 shows some of the many new protocols and OCSP extensions that have been suggested.

Table 3‑1 Proposed PKIX Protocols

One important thing to note here in connection with OCSPv2+DPV+DPD is the proposal of DPV (Delegated Path Validation) and DPD (Delegated Path Discovery) as two types of services for the certificate verification server, as well as the functional requirements defined for DPV and DPD as related to DPV/DPD REQ.

DPV performs all operations from certification path construction through verification on the server-side. The certificate verification client is able to verify the certificate used for a signature by simply making an inquiry of the certificate verification server.

DPD performs only certification path construction and the collection of revocation information (CRL or OCSP response) of the certificate forming the path on the server-side. Policy matching and other certification path verification work must be conducted on the client-side. In DPD, a verifier (wishing to conduct the certificate verification process itself) can have the server-side perform just the overhead-intensive work of certification path construction and revocation information collection.

DPV/DPD REQ was standardized in RFC3379 in September 2002. Currently, PKIX is conducting discussions to standardize protocols (as defined requirements in DPV/DPD REQ) allowing actual utilization of DPV/DPD. The current protocols that are candidates for DPV/DPD are SCVP, CVP (Certificate Validation Protocol), DPV and DPD over OCSP, and DVCS (Data Validation and Certification Protocols).

In addition, the W3C is drafting protocols for certificate validity verification utilizing XML. This is found in X-KISS (XML Key Information Service Specification) within XKMS (XML Key Management Specification).

The following sections offer a more detailed description of DPV/DPD REQ. Section 3.5 discusses SCVP, one protocol for implementing DPV/DPD. Section 3.6 provides an overview of other relevant specifications.

3.2.2 DPV Conditions

DPV provides protocols for performing all certification path construction and verification on the server-side.

As mentioned above, the advantages of DPV include simplified implementation of certificate verification client, improved certificate verification performance, and a means for unified certificate verification methods.

DPV/DPD REQ includes the following requirements for DPV:

・ Certificate verification complying with a validation policy

・ Verification of certificate validity as of a certain point in the past

・ Signature attached to the response

Validation policy is a condition set used when certification path construction and path verification are performed. The client determines the validation policy when the certificate verification is requested. Conditions that should be included in the validation policy are the following:

・ Trusted certificate authority(Trust Anchor)

・ Constraints(Name Constraints, Policy Constraints)

・ Initial value for the RFC3280 certificate verification algorithm

・ Existence of revocation information in response

・ Conditions that the certificate subject to verification must meet (KeyUsage, etc.)

In addition, the DPV must be able to conduct not only validity verification for the certificate at the current point in time, but also for points in time in the past. This is done in cases where confirmation is performed to determine whether a certificate used for a signature was valid at the time (in the past) of the signature.

Because the DPV response must be received from a DPV server trusted by the certificate verification client, the DPV server must sign the DPV response.

3.2.3 DPD Conditions

Under DPD, certification path verification is conducted on the client-side; however, DPD protocols are used when the client requests that the server collects the certificate information (for the certificate forming the certification path) and the certification revocation information (CRL and OCSP response).

One advantage of DPD is the simplified implementation of the certificate verification client.

DPV/DPD REQ includes conditions of DPD such as the following:

・ Certification path construction conforming to path discovery policy

・ Responses for more than one certification path

The path discovery policy comprises the validation policy (or a portion thereof). The client must define the path discovery policy for the DPD server.

In addition, when more than one certification path is discovered by the DPD server, the response must be able to include multiple certification paths.

The purpose of the DPD server is to collect information related to the certificate (making up the certification path) and revocation information only. The actual verification of the signature of the certificate authority for the CRL and certificate and/or the signature of the OCSP responder for the OCSP response, as well as the verification of the certification path, is performed on the client-side. Because of this, the DPD response carries no particular level of trustworthiness. Attaching a signature to the DPD response is available as an option.

3.2.4 DPV and DPD Policy Query

DPV/DPD REQ includes definitions of protocols used for the client to acquire validation policies and/or path discovery policies capable of being utilized by the DPV/DPD server.

The DPV/DPD server must respond with an entire policy list or with the default policy available to the DPV/DPD server when a request is received from a client.

3.3 SCVP

During the writing of this document (February 21, 2003), the PKIX WG announced through their mailing list the only protocol being considered for acceptance as the DPV/DPD protocol is SCVP (Simple Certificate Validation Protocol). In this section, we will comment on SCVP, the DPV/DPD protocol proposed by the PKIX WG and likely to be standardized as an RFC in the future.

3.3.1 SCVP Overview

SCVP has been discussed over a longer period of time than any of the other candidates for DPV/DPD protocols. SCVP was first proposed in June 1999, being revised over time to conform to DPV/DPD REQ standards. The current draft, as of late February 2003, is the 11^th version (we will comment on version 11 here). SCVP is a protocol fundamental to the realization of DPV, and can also be used in conjunction with DPD, since it defines the processing functions required of the server by the client. In addition, protocols to acquire validation policies and path discovery policies have also been defined so as to allow conformance with DPV/DPD REQ. Under SCVP, both the certificate and the attribute certificate are subject to verification.

SCVP uses CMS (Cryptographic Message Syntax) as the protocol format for certificate verification server-client transactions. Four new types have been defined for the ContentType stored within CMS:

・ SCVP Request

・ SCVP Response

・ Validation Policy Request

・ Validation Policy Response

Accordingly, when necessary, a CMS-compliant signature is attached to requests and/or responses.

3.3.2 SCVP Request and Response

Figure 3-1 shows the SCVP request message format.

Figure 3‑1 SCVP Request Message Format

The query element portion of the request identifies the request contents. (certificate subject to verification and trust anchor, policies, etc.) In addition, it also identifies the process requested of the SCVP server (DPV/DPD) using checks. Further, wantBack is used to define information to be included in the response (whether certification path certificate and revocation information is included).

Figure 3‑2shows the SCVP response message format.

Figure 3‑3 SCVP Response Message Format

The header of the response includes the response status (responseStatus), server information (responder), and the time and date of the response creation (producedAt). replyTypeOfCheck indicates the verification results for the certificate. In addition, replyWantBacks returns information defined by the client-side.

Under SCVP, a single request will return only a single certification path. However, DPV/DPD REQ requires that if multiple certification paths are discovered, then multiple certification paths are returned. To conform, SCVP includes serverContextInfo in a response. When the client creates and sends a copy of the serverContextInfo that was included in a previous response with a client request related to the same certificate, the server can return a different certification path than the one previously returned. This mechanism allows for requesting a separate certification path in cases where a different certification path is required on the client-side.

3.3.3 Validation Policy Request/ Response

Figure 3-3 shows the validation policy request/ response message formats:

Figure 3‑4 Validation Policies Request/ Response Message Format

The formats for validation policy request/ response messages are as seen in Figure 3-3. The validation policy request simply forwards the OID and SCVP version for the request, while the response from the SCVP server returns the OID list corresponding to the SCVP server policy.

3.4 Other Proposed Standards

During the preparation of this document (mid-January 2003), the PKIX WG called for a vote through its mailing list in order to choose from among the four candidates for protocols to realize DPV/DPD. The four candidates were SCVP, CVP, DPV/DPD for OCSP, and DVCS. On February 21, 2003, the PKIX WG announced the selection of SCVP as the protocol to be used for implementing DPV/DPD. Over the next several months, SCVP will go through a period of discussion and final modifications before final standardization. However, we believe it is still beneficial to include herein a short description of the other three candidates for DPV/DPD: CVP, DPV/DPD for OCSP, and DVCS. We will also briefly discuss XKMS, currently under discussion by the W3C.

3.4.1 CVP

CVP (Certificate Validation Protocol) is one of the protocols defined for DPV/DPD. Among those proposing CVP was the author of DVP/DPD REQ, who was designing new protocols for DVD/DPD. One interesting characteristic of CVP is that in addition to communicating CVP requests and responses between the CVP client and server via HTTP, two methods are defined for directly communicating the CVP protocol, and also for sending CVP requests and responses via email. At present (late January 2003), the latest version of CVP is version 3, which is the version referenced in this report.

CVP offers the capability to contain three functions (DVP, DPD, and policy request) in a single request/ response cycle. If a certification path's certificate and revocation information are included in the DPV and DPD response, the response data volume increases proportionately, tending to result in a corresponding increase in time needed for signature and verification. Under CVP, rather than signing the entire response, only the newly added information in the area subject to response—the hash value data of the certificate and revocation information—is subject to signing, avoiding the aforementioned problem. As with SCVP, CVP contains serverContextInfo as a means to communicate multiple certification paths in response to the user.

3.4.2 DPV/DPD OCSP

DPV/DPD OCSP (DPV and DPD for OCSP) represents the minimum extension for OCSP. This protocol was recently proposed in January 2003 with the goal of allowing DPV or DPD to be used for OCSP. DPV/DPD OCSP defines an extended partition (extension) for OCSP requests and responses, and interprets the information stored therein according to its intended usage. Making use of the existing OCSP allows for minimum implementation modifications, providing the ability to extend the OCSP client as DPV/DPD client.

Under DPV/DPD OCSP, the extended partition related to a request is ExtendedOCSPRequest, while the extended partition for the response is defined as ExtendedOCSPResponse. The applicable validation policy and path discovery policy, trust anchor information, flags defining information that should be included in the response, and maximum value of the path storable within the DPD response, etc. can all be defined within ExtendedOCSPRequest. The usage of these elements varies depending on whether they are used under DPV or DPD. Also, the requested certificate information can be stipulated within the standard OCSP request. For ExtendedOCSPResponse, the time-stamp token and the set of revocation information and the certificate forming the path, as well as the OID of the applicable policy can be defined. The certificate verification result under DPV is contained in the OCSP standard CertStatus.

One characteristic of DPV/DPD OCSP is the ability for the client to define the maximum number of paths to be included in the response in the numPaths field when utilizing DPD. If the number of discovered paths matching the server-side policy exceeds the value in numPaths, the server will return only the path information in numPaths to the client. If no value is defined for numPaths, only information for one path will be returned by default. If the target path is not received in the response, the client can increase the value for numPaths, and resubmit the request in order to locate the target path.

3.4.3 DVCS

DVCS (Data Validation and Certificate Status) was proposed as a protocol to enable TTP (Trusted Third Party) to incorporate non-repudiation services, becoming a standard as RFC3029 in September 2001. Although DVCS was not defined specifically as a protocol for DPV/DPD, it does act as one DVCS service to verify the validity of a certificate at a certain point in time. DVCS was proposed as a candidate for DPV/DPD since it accomplishes certificate verification using the same protocols as services that prove ownership of other data and that verify digital signatures.

A DVCS server provides the following four services, returning a data validation certificate (DVC) to guarantee the corresponding results:

l Certification of Possession of Data (CPD)
Certifies that the requesting party is the owner of the data. The requesting party forwards data to the DVCS server, and the DVCS server issues a data validation certificate certifying that the requesting party was the owner of the data at that point in time.

l Certification of Claim of Possession of Data (CCPD)
Certifies that the requesting party has ownership of the data. The difference between this and CPD is that the requesting party send not the data itself, but the hash value of the data to the DVCS server.

l Validation of Digitally Signed Document (VSD)
Performs verification of a digital signature, and issues a data validation certificate verifying the results. Performs a verification of the certificate used for the digital signature when verification of the digital signature is performed.

l Validation of Public Key Certificates (VPKC)
Provides verification of a certificate's validity at a specified point in time, and issues a data validation certificate certifying the certificate validity.

DVCS service rules and policies define what information is used to conduct certificate verification on the DVCS server. The client can specify a certificate verification method by specifying policies and/or additional information.

If the DVCS server conducts a successful verification, it issues a data validation certificate, and returns it to the client. The data validation certificate includes the following information:

l Verification results
Certification and/or verification results

l Serial number
Assigns a simply increasing, unique serial number to each data validation certificate.

l Time stamp
Attaches the time or a time stamp token to indicate the time that verification was conducted.

l Policy
Attaches the OID indicating the policy used at the time of certificate verification.

The DVCS server grants a digital signature to the digital signature data validation certificate. At that time, an OID indicating that the certificate is for DVCS server signature usage must be included in the Extended Key Usage Extension.

A data validation certificate is used for the purpose certifying for another user (the verifying party) that as of a certain point in time, a certain piece of data was in possession, and that the digital signature is correct. The verifying party can use the received data validation certificate itself to conduct verification using a DVCS server.

3.4.4 XKMS/X-KISS

X-KISS (XML Key Information Service Specification) is being promoted for standardization by the W3C as a part of XKMS (XML Key Management Specification), a protocol for certificate management utilizing XML. The W3C is currently working on specifications for XKMS 2.0. The draft includes X-KRSS (XML Key Registration Service Specification), which requests certificate issuance or revocation of a certificate authority, and X-Bulk (XKMS Bulk Operation), which requests a collective issuance of a multiple number of certificates.

X-KISS has been created as a mechanism to verify a certificate used in XML Signature or XML Encryption (standardized as signature and encryption specifications for XML files). With XML Signature and XML Encryption, the key information used for encryption and signatures is specified by a structure termed <KeyInfo>; however, the only information specified here is the certificate name (Subject Name) and the value of the public key, and there are many cases where the certificate itself is not stored. In addition, since the digital certificate is prescribed in a computing language called ASN.1, if the XML client handles the certificate directly, it must be able to parse ASN.1 (separately from XML), which creates an added burden for the client. To avoid this, X-KISS is set up so that a method to acquire the certificate from <KeyInfo>, and a mechanism to verify the validity of a certificate specified by <KeyInfo> is implemented on the server-side, while communication with the client is done in XML.

Under X-KISS, three types of service levels are available: Tier0, Tier1 and Tier2.

For Tier0, the XKMS server is requested only to retrieve a certificate from the server specified by <RetrievalMethod> within <KeyInfo>.

For Tier1, the XKMS server returns (in XML format) a corresponding key name and public key for a designated <KeyInfo>.

For Tier2, in addition to the service in Tier1, the XKMS server also performs validity confirmation for a certificate, and includes the results in the response to the client.

3.5 GPKI Certificate Verification Server

Bridge models are used extensively with GPKI. While these bridge models offer flexibility, performing signature verification through the bridge CA for certificate path construction and verification becomes quite complicated. Because of this, the government has installed a certificate verification server for each agency.

In response to a request from a client, the certificate verification server verifies the certificate specified by the client-side (certificate path construction and verification), and returns the results to the client. The necessity of this type of certificate verification server is recognized by technical authorities worldwide, including the IETF. During the timeframe when actual implementations did not exist, the OCSP protocol was extended, establishing specifications for protocols to allow implementation.

3.5.1 Certificate Verification Server Functions

The following is a brief overview of functions included in the certificate verification server. (Table 3-2)

Table 3‑2 Certificate Verification Server Functions

Function Name	Explanation of Function
Verification path construction, verification	Performs verification path construction and verification conforming to GPKI Interoperability Specification. This allows verifier to know whether the certificate subject to verification has been issued by a trustworthy certificate authority.
Validity confirmation	Confirms validity of certificates within the verification path. Supports CRL and OCSP (RFC2560).
Key pair creation	The GPKI Certificate Verification Server response data is conducted through OCSP. This function creates a key pair to create the signing key.
Creation of Certificate Issuance Request Data	Creates the data required for certificate issuance in PKCS#10 format to issue a certificate from the government certificate authority to the GPKI Certificate Verification Server

Figure 3-4 shows the brief overview of GPKI certificate verification server.

Figure 3‑5 GPKI Certificate Verification Server Structure

Figure 3-5 is a conceptual framework of a GPKI certificate verification server structured with a simplified PKI model.

Figure 3‑6 GPKI Certificate Verification Server Usage

3.5.2 Structure of a Certification Verification Server within GPKI

Each government agency certificate authority has its own certificate verification server. This certificate verification server applies a signature to the response data, and issues a certificate from the government agency certificate authority for the public key that corresponds to the signing key.

One must note that a certificate verification server and applications that utilize a certificate verification server must exist on the same PKI domain. In other words, if a certain government agency's applications utilize a certificate verification server, the verification of the signed response from the certificate verification server must be performed by those applications. This signature must be the same for the trust anchor used by the applications and the trust anchor of the certificate verification server (trust point).

3.5.3 Signature Verification of Certificate Verification Server Response Message

A signature is given to a response from the certificate verification server. The verification of this signature must be conducted by the client of the certificate verification server. Additionally, the certificate verification corresponding to this signature must also be conducted by the client. In other words, the verification of certificate chain coming from the same trust anchor as the EE of the relying party must be done on the client-side.

Figure 3‑7 Certification Path using Certificate Verification Server

3.5.4 Certificate to the GPKI Certificate Verification Server

Access protocols to the GPKI certificate verification server utilize extensions of OCSP (RFC2560). Under RFC2560, there is a description of the certificate profile issued by the OCSP responder. The issuance of a certificate to the GPKI certificate verification server is conducted in a manner conforming with RFC2560. The GPKI Interoperability Specification includes rules such as those described below.

"An id-kp-OCSPSigning must be established in the extendedKeyUsage of the GPKI certificate verification server certificate. In addition, it is also advisable to specify the id-pkix-ocsp-nocheck extensions. In this case, we recommend setting the expiration date of the certificate to less than one year."

Rules related to the revocation check of this certificate itself include the following:

"The signature verification is conducted through the GPKI certificate verification server certificate attached to the response data; however, if the certificate does not contain id-pkix-ocsp-nocheck extensions, we recommend the performance of a certificate verification as well."

"For the certificate verification, in addition to other verification items for the certificate, a check must be made to determine whether id-kp-OCSPSigning has been set in extendedKeyUsage extensions. Further, the GPKI certificate verification server certificate may be revoked by the CRL issued by the government agency CA; therefore, the CRL must be acquired and a check for validity must be conducted."

3.6 GPKI Certificate Verification Server Protocols

Protocols for the GPKI certificate verification server are based on OCSP (RFC2560). Under OCSP, an arbitrary number of extensions are allowed for the request message and the response message (as with the X.509v3 certificate). These extensions are the same as those for the X.509v3 certificate, consisting of an OID (object identifier), which indicates the nature of the extensions, a flag determining whether the interpretation of the extensions is compulsory (critical, non-critical), and the associated value for the extension.

With OCSP, a multiple number of requests can be inserted into a single request message; however, the GPKI certificate verification server only accepts one request. In a similar manner, when several requests have been made, several responses may be included in a single response message, but the GPKI certificate verification server only returns once response.

OCSP extensions include extensions for individual requests (singleRequestExtensions) and extensions for overall requests (RequestExtensions). GPKI certificate verification server access protocols conducts extensions using singleRequestExtensions. NONCE, a standard extension under OCSP, is included in RequestExtensions.

In addition, extensions for the response include singleRequestExtensions and extensions for the overall response (RequestExtensions), but the GPKI certificate verification server access protocols is extended with singleRequestExtensions. As with requests referred to previously, NONCE is used.

Under OCSP a signature can be attached to a request message; however, GPKI certificate verification server protocols do not support a signed request or the associated verification.

The following OID is used as the base for extensions in GPKI certificate verification server access protocols.

OID:1.2.392.200010.10

This OID is the OID from the GPKI certificate verification server manufacturing and development company, Hitachi, Ltd.

3.6.1 Certificate Verification Request

(1) Request content

Figure 3‑8 Verification Requests to a Certificate Verification Server

(2) OCSP primary partition(OCSPRequest)

RFC2560 rules are followed; however, NONCE is required for requestExtensions.

(3) OCSP extended partition (singleRequestExtensions)

When the GPKI certificate verification server client specifies the following extensions, each extension is designated as Critical.

Table 3‑3 Certificate Verification Requests and OCSP Extended Partitions

Extended Partition Name	Explanation of Function	Option
Subscriber Certificate	Under OCSP the certificate information requested is set in the primary partition; however, with the GPKI Certificate Verification Server access protocols, the certificate subject to verification itself is sent. This is accomplished through OCSP extensions. As this is required for the GPKI Certificate Verification Server, the extension flag is set to "critical".	Required
Intermediate Certificate	Designates a certificate forming a portion of the verification path for the certificate (etc.) from the subscriber-side root certificate authority (trust anchor) to the subscriber's end entity. However, the GPKI Certificate Verification Server is only used to provide "hint" information for the intermediate certificate verification path construction, and does not necessarily mean that a path is always constructed that includes the designated certificate. This extension is an option, and more than one can be designated. Also, if multiple extensions are designated, those certificates closes to the trust anchor along the verification path are designated first, and then others in terms of proximity.	Option
CA (Trust Anchor) Identifier Information	CA certificate is sent as information needed to identify the root certificate authority (trust anchor) trusted by the relying party. This extension is an option. If it is not included, the root certificate authority (trust anchor) trusted by the party requesting verification (relying party) becomes the root certificate authority designated by the GPKI Certificate Verification Server. However, under GPKI, it must be designated as a self government root certificate authority, and will return an error (error code: 901) if designated as anything else. For GPKI/ LGPKI, the GPKI Certificate Verification Server and the relying party are assumed to be in the same domain, meaning that this extension should be omitted.	Option
Policy to be followed	When the relying party requires that a policy for the verification path be followed, the OID of that policy is designated. If such a policy is designated, the GPKI Certificate Verification Server examines whether the constructed path conforms to the designated policy. This extension is an option, and more than one may be designated. In the current GPKI/ LGPKI environment, it is probably best to designate one OID that is the same as the government certificate policies.	Option
Initial Value for require-explicit-policy	Designates the scope when the relying party requires a require-explicit-policy for the verification path. If require-explicit-policy is designated, the GPKI Certificate Verification Server investigates whether a policy exists for the certificate within the scope of require-explicit-policy scope. Under GPKI, if a policy that is required to be followed is designated, this extension is always set to "0" (zero).	Option
Initial Value for inhibit-policy-mapping	Designates the scope when the party relying on verification (relying party) requires inhibit-policy-mapping for the verification path. If inhibit-policy-mapping is designated, the GPKI Certificate Verification Server investigates whether policy mapping exists for the certificate within the scope of inhibit-policy-mapping. Under GPKI, policy mapping is required; therefore, this extension is never designated.	Option
Response Format	Designates the information level that should be returned as the certificate verification response with regard to the relying party. If omitted, only the verification results for the certificate are returned. The following are the available information levels: 0: Returns only the verification results for the certificate (default) 1: Returns the verification path and CRL/ARL in addition to the verification results for the certificate The client of the GPKI Certificate Verification Server inquires of the GPKI Certificate Verification Server about the validity of a certificate. When the source data for this inquiry must be preserved, the data set can be requested from the GPKI Verification Server.	Option

3.6.2 Certificate Verification Response

(1) Response content

Figure 3‑9 OCSP Responses

(2) OCSP primary partition (OCSPResponse)

Conforms to RFC2560 rules. However, NONCE is required for responseExtensions. Also, nextUpdate is not used.

Much of the information in the OCSP primary partition holds no meaning for the response from the GPKI certificate verification server.

(3) OCSP extended partition (singleExtensions)

The GPKI certificate verification server responds with Critical for "certificate verification result", and Non-Critical for other extensions.

Table3‑4 Certificate Verification Responses and OCSP Extended Partitions

Extended Partition名	Explanation of Function	Option
Certificate Verification Results	The OCSP responder returns the revocation check results in the OCSP primary partition. The GPKI Certificate Verification Server results are designated in the results code of the certificate verification (verification path construction and verification) using the OCSP extended partition. As this is a basic function of the GPKI Certificate Verification Server, this is always included as critical in the response message. The following are certificate verification results codes: 0:Verification path construction is successful, verification results are correct (good). 101:Verification path could not be constructed 202:Verification path included a certificate with an improper signature 203:Verification path included a revoked certificate 204:Verification path included a certificate not matching policy 205:Verification path included certificate violating constraints 206:Verification path included certificate responding with unknown CertStatus via OCSP 901:Rejected requests from GPKI Certificate Verification Server 902:Request timed out	Required
Verification Path	Sets all certificates in constructed verification path. Only in cases when "return" is required by the response format of the certificate verification request is the response message included.	Option
CRL/ARL	The certificate issuer (except for OCSP responder) sets the issued revocation list (CRL/ARL) related to the certificate of the constructed verification path. Only in cases when "return" is required by the response format of the certificate verification request is the response message included.	Option
Response from OCSP Responder	Sets the OCSP response information acquired from the certificate issuer (only for OCSP responder) related to the certificate of the constructed verification path. Only in cases when "return" is required by the response format of the certificate verification request is the response message included.	Option
Conforming Policy	Sets the certificate result as the valid policy related to the constructed verification path certificate. Only in cases when "return" is required by the response format of the certificate verification request is the response message included. More than one conforming policy may be returned based on the protocol. However, the current GPKI bridge certificate authority only conducts one class of policy mapping, and therefore more than one policy is never returned. In the future, there may be multiple policy mapping. In such a case, the certificate policy of the subscriber may be able to change the behavior of an application based on policies in a context where policy mapping is done in its own domain.	Option

4 4 Trends in Certificate Path Construction and Path Verification Test Criteria

4.1 Certificate Path Construction and Path Verification Test Criteria

When a certain certificate path is constructed and verified, any PKI application must be able to return the same verification results. However, as discussed in previous sections, certification path construction and path verification is a very complex matter, and different PKI applications could return different verification results.

Because of this, several interoperability tests have been conducted in many countries over the last few years to develop means by which any PKI application of choice returns the same verification results. Under these interoperability tests, test criteria is first established, after which various PKI applications are verified to determine whether they return results conforming with the pre-determined criteria. This type of testing helps insure PKI interoperability across different applications.

In this section, we will discuss interoperability tests conducted in various countries related to certificate path construction and path verification. The interoperability test suite of Section 7 and the GPKI test case in Section 8 were designed with the objective of using test criteria pertinent to GPKI, and with consideration given to the test criteria used overseas.

4.2 EEMA pkic

4.2.1 Activity Introduction

The PKI Challenge (pkic) is a project whose objective is PKI interoperability, and also promoted by the EEMA Initiative. EEMA itself is an industry organization comprised of 273 groups across 32 countries. A wide range of organizations participate in EEMA, including PKI vendors such as Entrust and Baltimore, certification providers such as Globalsign, users such as the UK Post, audit consultants such as KPMG, universities and others.

The pkic initiated a two-year project beginning during the first quarter of 2001. The goal of the project is to produce a "Secure Inter-Organizational Messaging Framework", as indicated in Figure 4-1, below.

Figure 4‑1 pkic Interoperability Testing for EEMA

Pkic has set the following three specific goals in connection with securing the development of this framework:

· Development of required (Mandatory), secure applications

· Analysis of problems when PKI references directories (X.500, LDAP):

A) Problems related to the specifications of the directory (X.500, LDAP) itself

B) Problems occurring during the utilization of PKI

· Establishment of PKI interoperability criteria

The tasks necessary to accomplish and verify these goals are classified in the two general categories below:

a) Draft test criteria and model testing

b) Perform demonstrations based on tests

4.2.2 Test Criteria Characteristics

(1) Test criteria (major points)

According to pkic, the following elements must be studied and understood in order to maintain PKI interoperability.

- Smart Cards

Ø Certificate issuance from the RA

Ø I/F with PKI applications

- Certificate issuance between CAs

Ø Manual cross-certification

Ø Online cross-certification

- EE certificate registration/ issuance procedures

Ø Online issuance (Web- or email-based)

Ø Key created by the CA

Ø Key created by the EE

- Online certificate verification I/F

Ø Certificate status provided by the CA to the VA

Ø Verification request from the PKI application to the VA

Ø Inter-VA proxy

- Meta-directory I/F

Ø Inter-directory correspondence

Ø Certificate/ CRL acquisition by the PKI application

- Secure applications

Ø Secure E-mail (S/MIME)

To solve the aforementioned problems, pkic has put forth the following interoperability conditions and standard specifications (which should be conformed to or referenced) for each category below.

(a) Profiles

Since S/MIME is the generally expected messaging application, pkic has defined a certificate profile referencing S/MIME and QualifiedCertificate.

The CRL profile is the basic profile referencing X.509v2 CRL and RFC2459.

For the directory schema, only a basic schema is used; however, in actual practice, the schema conforms to RFC2256 (LDAPv3 Schema).

(b) Applications

S/MIME and CMS are referenced as exchange mechanisms for electronic mail with digital signatures. One characteristic is the condition requiring at least three certification path levels, including verification and cross-certification utilizing delta-CRL.

Although smart card interoperability is not the main mission for pkic, tests will be conducted assuming PKCS #11.

(c) Certificate issuance

Pkic is investigating three types of issuance conditions for certificates (cross-certification certificate, subordinate CA certificate, EE certificate) that span organizations with differing policies.

PKCS #10, CRMF (Certificate Request Message Format), and PKCS #7, CMS (Cryptographic Message Syntax) are each currently being investigated by pkic for use as the message format when a certificate is issued.

In addition, CMC (Certificate Management Message over CMS) and CMP (Certificate Management Protocol) are being discussed for use as the message transmission protocol.

(d) Directory service

Pkic has gone no further than to identify directory interoperability as an issue that requires further study.

(e) Verification services

Pkic assumes that the OCSP responder will be used as the verification service (VA), with the revocation information distribution protocol incorporating LDAP (pull) and HTTP (push). In addition, pkic is considering proxy/forwarding as the best usage of a VA.

http://www.eema.org/pki-challenge/criteria.asp

(2) Test scenarios

Pkic is preparing test scenarios under the categories discussed below. One point to note is that test scenarios will use a clearly defined EE model and VA model, as well as a simple VA model and a proxy VA model, all of which should produce the same results for certificate path construction and path verification.

(a) Cross-certification with other CAs (TG1)

Pkic clearly identifies the CA to be referenced. By conducting cross-certification with this reference CA, interconnectivity for all other CAs subject to testing will be verified objectively.

The following tests will be performed during cross-certification with a reference CA:

- Manual off-line cross-certification

- Automatic online cross-certification

- CMP cross-certification using a MAC

- CMP cross-certification using a signature

(b) Certificate issuance to the EE (TG3)

Pkic conducts verification of the issuance patterns listed below in cases where either the EE creates the key itself, or where the CA creates the EE key:

- Online certificate issuance utilizing the client

- Manual certificate issuance

(c) Certificate issuance to a subordinate CA (TG2)

Interconnectivity for all the CAs subject to testing can be verified objectively by mutually issuing a subordinate CA certificate with this reference CA.

At that time, there are two foreseeable relationships between the test CA and the reference CA:

- Case A: The test CA issues a subordinate CA certificate to the reference CA.

- Case B: The reference CA issues a subordinate CA certificate to the test CA.

The test CA verifies the test categories listed below for each case:

- Manual certificate issuance

- Online (CMC) certificate issuance

- Online (CMP) certificate issuance

(d) Certificate verification (TG4, TG5)

Pkic has paid particular attention to the revocation verification portion of the certificate verification process, coming up with the two test scenarios below:

- EE model (required )

The EE itself performs revocation verification by acquiring the CRL needed for certificate revocation verification.

- VA model (optional )

The EE requests the certificate revocation status from the OCSP responder, which performs revocation verification and returns the results to the EE.

(i) Certificate path construction and path verification (TG4)

Under the present tests, the certificate verification listed below is conducted for the EE and VA models. Accordingly, the pkic criteria require that the same verification result is obtained whether the EE model or the VA model is used.

- Normal certificate

- Revoked certificate

- Expired certificate

- Certificate that does not match the policy

- Certificate for which path construction cannot be completed

(ii) Certificate verification using OCSP (TG5)

During the present testing, verification testing is conducted assuming a more specific situation, especially for the VA model. Accordingly, the pkic test criteria must result in returning the same verification outcome, whether the simple VA model or the proxy VA model is being tested.

- Simple VA model

The VA acquires a CRL from the directory to obtain revocation information.

- Proxy VA model

The VA makes an inquiry to another VA to obtain revocation information.

4.3 DoD BITS

4.3.1 Activity Introduction

(1) Background and purpose

The U.S. government has focused attention on the possibility of PKI interoperability between government and private sources by means of bridge CA models. Government and private vendors have cooperated in developing a PKI environment using a bridge CA model. The Federal Bridge CA-focused "Electronic Messaging Association (EMA) Challenge 2000", run by the NIST, and the DoD Bridge CA-focused "Bridge Certificate Authority (BCA) Technology Demonstration", as well as other projects have been conducted as activities to aid in verifying these possibilities. We will go into further detail here related to the DoD BCA Demonstration and its resulting test suite DoD BITS (BCA Interoperability Test Description). The reports of the results of the DoD BCA Demonstration have been published online at the following websites:

http://www.anassoc.com/BCA.html

http://bcatest.atl.getronicsgov.com/index.htm

The DoD BCA Demonstration was divided into a Phase I and a Phase II. Phase I was conducted from 1999 to 2000, and Phase II was conducted from 2000 to 2001.

The following are some of the conditions adhered to for Phase I:

• Establishing relationship of trust among through BCA for three PKI domains belonging to three different PKI vendors.

• Directory access between and among all three domains.

• Formation of a "border directory"

• Path construction through BCA

• Transmission of BCA interjected signature data

• Signature algorithm performed with md5withRSAEncryption only

• Related certificate policy processing not included

Phase II included the Phase I conditions plus the following points:

• Establishing relationship of trust among through BCA for five PKI domains belonging to different PKI vendors

• Directory access between and among all five domains

• Transmission of BCA interjected signature and encrypted data

• A mixture of signature algorithm

• Related certificate policy process was performed.

This BCA Demonstration was able to reach the following objectives and conditions:

• With minor improvements, current CA products were successfully used to create a BCA environment, including hierarchical and mesh PKI.

• A free reference library for certificate path construction was produced.

• Software was produced allowing certificate path construction and path verification under an electronic mail environment using S/MIME v3.

• The ability to use general market products (COTS) for BCA was demonstrated.

• Successful verification of proper processing of a digital signature under an electronic mail client within a BCA environment.

• Successful verification of proper processing of encryption under an electronic mail client within a BCA environment.

• Verification of a conforming encryption algorithm.

(2) Corporations and products participating in the Phase II demonstration

· Software development

Getronics Government Solutions:

X.500 certificate management library (CML).

S/MIME library (SFL).

Access control library (ACL).

Entrust CygnaCom:certificate path construction library (CPDL).

· PKI products

Baltimore Technologies: "UniCERTä"

Entrust Inc.: "Entrust/Authority 5.0.2."

SETECS: "OnePKIä"

SPYRUS: "S²CA" (DoD SDN conforming PKI product)

Motorola: "CAW" DoD SDN (Secure Data Network) conforming certificate authority workstation, used in Fortezza initialization, etc.

CygnaCom: Developed based on reference implementation of "Bridge CA" NIST MISPC (Minimum Interoperability Specification for PKI Components)

· Directory products

Entegrity:X.500 "Safepages directories" management tool, border directory and synchronization tool, Web-based demo tool

Critical Path: "LiveContent directory servers"

· User applications

Baltimore Technologies: "MailSecure security enhancements for MS Outlook"

Entrust Inc.: "Entrust/Express security enhancements for Microsoft Outlook"

CygnaCom: "Qualcomm Eudora" plug-in (developed based on SFL, CML, CPDL, ACL)

(3) Phase II demonstration models

As shown in the next figure, cross-certification was conducted between a Bridge CA located within the DoD and four PKI domains within the DoD (Armed Forces (military), DISA (Defense Information Systems Agency), DFAS (Defense Finance and Accounting Service), and DLA (Defense Logistics Agency)), and also between the aforementioned Bridge CA and an external CA at the Department of Justice, which is a PKI domain outside the DoD. Within the Armed Forces, subordinate CAs are located with the Army, Air Force and Navy. DISA and DFAS both have multi-stage CA hierarchies, while the DLA has two CAs with differing policies. The CAs at the Department of Justice include those at the FBI and the Coast Guard configured in a mesh-shaped cross-certification. The number of CAs with PKI domains and the associated policies are illustrated in Table 4-1 "PKI domains and certificate policies". In addition, Figure 4-3 "certificate policy mapping" shows the policy mapping status related to cross-certification. As can be seen in this figure, no mapping has been conducted for policies at the Coast Guard. Therefore, certificates only containing Coast Guard policies should be rejected by other domains.

Each PKI domain is structured with products from different PKI vendors.

Inter-directory server synchronization was conducted under a concept called "border directory", discriminating what content can be accessed externally or internally. By synchronizing the DoD's external and internal directory servers, all of the information necessary for verification was able to be unified by the BCA directory server.

Within this environment, PKI domain users conducted transmission and verification of digital signatures and/or encrypted data over an electronic mail client incorporating S/MIME.

Figure 4‑3 PhaseⅡDemonstration PKI model

Table 4‑1 PKI Domain and Certificate Policies

Domain	Vendor	Type	CA No.	Certificate Policy
Defense Logistics Agency (DLA)	Baltimore Technologies	Hierachical	2	Logistics High Logistics Medium
Law Enforcement: Justice, Coast Guard, FBI	Entrust	Mesh	3	Law Enforcement High Lawn Enforcement Medium Coast Guard High
Armed Forces (Army, Navy, Air Force)	SPYRUS	Hierarchical	6	DoD Class 3 DoD Class 4
Defense Information System Agency (DISA)	Motorola	Hierarchical	2	DISA Policy
Defense Finance & Accounting (DFAS)	SETECS	Hierarchical	4	Finance Policy
BCA	CygnaCom	BCA	1	BCA High BCA Medium

Figure 4‑4 Certificate Policy Mapping

(4) "BITS" test suite

Based on the Phase II demonstration results, a test suite was developed placing emphasis on the following points from among all of the functions defined in RFC 2459. This test suite was publicly released as "BITS" (Bridge Certification Authority Interoperability Test).

· naming constraints (both permissions and exceptions)

· certificate policy

· certificate policy mapping

· CRL-based revocation verification

· cross-certification

· CRL-DP processing

· multiple intermixed signature algorithms in the certificate path

We have prepared data based on a PKI domain assuming the same PKI environment constructed for the Phase II BCA demonstration (excluding DFAS). The data can be obtained at the following website:

http://bcatest.atl.getronicsgov.com/bits.htm

In addition, online path construction is also available. The directory server below is currently operating:

Host name:bcatest.atl.getronicsgov.com

Port:389

The distributed data includes the following for each directory:

· certpairs:cross-certificate pair

· certs :CA, BCA, EE certificates

· crls :CRL (next scheduled update is in October 2003)

· pkcs12:Private keys for all certificates are distributed. (password=password)

· smime:S/MIME mail message created during the test

(5) BITS test procedures

S/MIME processing is tested assuming S/MIME mail messages are sent to/received from different PKI domains. The following categories are used in testing:

Signature processing: 39 test cases

Verification processing: 48 test cases

Encryption: 26 test cases

Decryption: 6 test cases

Signature and encryption: 5 test cases

Except for signature processing, the initial verification parameters below are set, after which path construction and path verification are both conducted.

· Set trust point certificate

· Set acceptance policy

· Set Initial-explicit-policy

· Set Initial-policy-mapping-inhibit

· Set Initial-inhibit-policy

The following table shows the object IDs used in the distributed certificates.

Table 4‑2 Certificate Policy Object ID

Object ID	Registered Name	Indentifier
2.5.29.32.0	any-policy	any-policy
2.16.840.1.101.2.1.12.1.1	Infosec test-certificate-policy-1	DISA
2.16.840.1.101.3.2.1.48.1	NIST test-policy-1	DoD Class 3
2.16.840.1.101.3.2.1.48.2	NIST test-policy-2	DoD Class 4
2.16.840.1.101.3.2.1.48.3	NIST test-policy-3	Law Enforcement Medium
2.16.840.1.101.3.2.1.48.4	NIST test-policy-4	Law Enforcement High
2.16.840.1.101.3.2.1.48.5	NIST test-policy-5	Coast Guard High
2.16.840.1.101.3.2.1.48.6	NIST test-policy-6	Bridge CA Medium
2.16.840.1.101.3.2.1.48.7	NIST test-policy-7	Bridge CA High
2.16.840.1.101.3.2.1.48.8	NIST test-policy-8	Finance
2.16.840.1.101.3.2.1.48.9	NIST test-policy-9	Defense Logistics Medium
2.16.840.1.101.3.2.1.48.10	NIST test-policy-10	Defense Logistics High

(6) The Public Key Interoperability Test Suite (PKITS)

In February 2003, PKITS, the successor to BITS, was publicly released. BITS has been replaced by PKITS at the same URL.

http://bcatest.atl.getronicsgov.com/index.htm

Under PKITS, the test suite is divided into path construction and path verification, having 16 and 210 test cases, respectively. A large number of test cases are related to path verification.

5 An Explanation of Java-based Implementations of Certificate Path Construction and Path Verification

5.1　 Overview of Path Construction and Path Verification for Java JDK 1.4

Java was originally created assuming that it would be used with PKI technology. As such, certificate handling and verification functions are built into the platform.

The certificate-related framework implementation of JAVA JDK 1.4 (hereinafter called JDK 1.4), which is the lasted version of the JDK, includes an implementation of RFC3280-based path construction and verification algorithms, and handles certificate contents seamlessly in either a single-domain PKI or multi-domain PKI environment. However, JDK 1.4 lacks somewhat in relation to certificate revocation verification, sharing the same inability as GPKI to handle CRL-related processes such as IssuerDistributionPoint. Originally, under RFC3280, the handling of IssuerDistributionPoint within the CRL is not clearly documented (as reported in last year's JNSA Challenge PKI 2001). One could even say that the inability to conduct verification in this context runs true to the nature of the RFC3280 implementation.

Under a single-domain PKI, processing can be conducted even with a lack of clarity related to the CRL distribution. However, certificate verification cannot be performed under multi-domain PKI with an unclear CRL distribution.

In addition, SUN implementations are deficient in several areas related to certificate handling. The best that can be said for a SUN implementation is that it conforms to the bare minimum RFC3280 standard.

These path construction and verification functions come as extensions of the X.509 certificate, with java.security.cert being implemented as follows.

Framework of path construction and verification is assumed to be under the following three portions:

a) CertStore

Performs storage, search, and acquisition (if necessary) for a certificate. Under JDK 1.4, certificate acquisition is conducted through an acquisition request to CertStore. CertStore searches and acquires the certificate in response to the request.

b) PathBuilder

Performs certificate path construction.

c) PathValidator
Performs certificate verification.

The combination of these interfaces is what performs certificate path construction and verification.

The following are the minimum codes needed for RFC3280-based path verification.

import java.io.IOException ;

import java.security.InvalidAlgorithmParameterException;

import java.security.NoSuchAlgorithmException;

import java.security.cert.CertPath;

import java.security.cert.CertPathValidator;

import java.security.cert.CertPathValidatorResult;

import java.security.cert.CertPathValidatorException;

import java.security.cert.PKIXBuilderParameters;

import java.security.cert.PKIXCertPathValidatorResult;

import java.util.Set;

import java.util.HashSet;

static public final String DEFAULT_IMPLEMENTATION_NAME = "PKIX";

public CertPathValidatorResult validate(

String implementationName,

Set trustAnchor,

CertPath path,

boolean anyPolicyInhibit,

boolean policyMappingInhibit,

boolean explicitPolicy,

Set initialPolicy)

throws CertPathValidatorException {

PKIXBuilderParameters params = null;

CertPathValidator validator = null;

try { // Prepares parameters

params = new PKIXBuilderParameters(trustAnchor, null);

params.setAnyPolicyInhibited(anyPolicyInhibit);

params.setExplicitPolicyRequired(explicitPolicy);

params.setPolicyMappingInhibited(policyMappingInhibit);

params.setInitialPolicies(initialPolicy);

// Please set appropriate repository

} catch(InvalidAlgorithmParameterException iape) {

throw new CertPathValidatorException(iape);

}

try { // runs validator, receives results

validator = CertPathValidator.getInstance(implementationName);

return validator.validate(path, params);

} catch(NoSuchAlgorithmException nsae) {

throw new CertPathValidatorException(nsae);

} catch(InvalidAlgorithmParameterException iape) {

throw new CertPathValidatorException(iape);

}

Figure 5‑1 Simplified Path Verification Code based on Java RFC3280

Less than 20 lines of code are needed to perform a valid path construction/ path verification for a certificate. A somewhat more complex path verification is shown in the sample code below:

import java.io.IOException ;

import java.security.InvalidAlgorithmParameterException;

import java.security.NoSuchAlgorithmException;

import java.security.cert.CertPath;

import java.security.cert.CertPathValidator;

import java.security.cert.CertPathValidatorResult;

import java.security.cert.CertPathValidatorException;

import java.security.cert.PKIXBuilderParameters;

import java.security.cert.PKIXCertPathValidatorResult;

import java.util.Set;

import java.util.HashSet;

// Creates path creation object

CertPathBuilder builder = CertPathBuilder.getInstance("GPKI");

CertPathValidator validator = CertPathValidator.getInstance("GPKI");

// Acquires certificate subject to investigation

X509Certificate targetCertificate = getCertificate(certificateStore, argv[1]);

// Acquires certificate to be used as trust anchor

X509Certificate trustCertificate = getCertificate(certificateStore, argv[2]);

// Creates construction parameters

CertPathParameters buildParameter = getCertPathParameters(

argv[0], validator, trustCertificate, targetCertificate, certificateStore

);

try {

CertPathBuilderResult buildedPathResult = builder.build(buildParameter);

certificatetionPath = buildedPathResult.getCertPath();

printCertPath(certificatetionPath);

if(buildedPathResult instanceof PKIXCertPathBuilderResult) ｛

PKIXCertPathBuilderResult result = (PKIXCertPathBuilderResult)buildedPathResult;

PolicyNode policy = result.getPolicyTree();

if(policy != null) {

printPolicy(policy);

}

} catch(Exception e) {

e.printStackTrace();

}

try {

CertPathValidatorResult result =

validator.validate(certificatetionPath, buildParameter);

printCertPath(certificatetionPath);

if(result instanceof PKIXCertPathValidatorResult) {

PKIXCertPathValidatorResult r = (PKIXCertPathValidatorResult)result;

PolicyNode policy = r.getPolicyTree();

if(policy != null) {

printPolicy(policy);

}

} catch(Exception e) {

e.printStackTrace();

}

Figure 5‑2 More Complex Path Verification Code based on Java

Anyone with a minimum level of knowledge regarding path construction and path verification can use either of the sample codes to create a path construction/ path verification function under JDK 1.4.

However, a JDK 1.4 implementation (or framework) using a SUN system presents several inconveniences:

First, and this may be a limitation in the JAVA certificate management library, there are number of operational limitations related to information included in the certificate (especially X.509v3 extensions).

For example, when attempting to acquire information for extensions such as CRLDistributionPoint, the only way the process can be performed is through Java.security.cert.X509Extension .getExtensionValue(oid).

5.2 Explanation of Sample Implementation

5.2.1 API Specification

As related to the API specification, implementation was done "given the same interface as the SUN implementation provider". Given that the provider is the one acting under this implementation, this points to the direct and indirect use of the classes listed below, under the objective of maintaining compatibility.

(1) java.security.cert.CertStore

(2) java.security.cert.PKIXBuilderParameters

(3) java.security.cert.PKIXCertPathBuilderResult

(4) java.security.cert.PKIXCertPathChecker

(5) java.security.cert.PKIXCertPathValidatorResult

However, for standards not falling within the scope supported by SUN implementations, if there are not enough classes for the intended purpose, the classes listed above can be inherited, and new classes may be used.

(1) java.security.cert.CertStore

This class is an abstract class representing the certificate repository used during JAVA path creation. All certificates and CRLs are acquired through this class. Under the SUN standard implementation, an implementation using LDAP and an implementation storing an instance of a java.security.cert.X509certificate/java.security.cert.X509CRL within the JAVA VM are available.

Furthermore, under the SUN standard implementation, the CRLDistributionPoint within the certificate cannot be processed. When using this implementation, the following extensions can be used to perform CRLDistributionPoint processing.

To the implementation of the CRL (CRL defined by the URLObject) acquisition method, we have added an implementation for acquisition by HTTP protocols in consideration of HTTP acquisition assumed by CRLDistributionPoint, as well as an implementation for a provider to handle CRLDP.

(2) java.security.cert.PKIXBuilderParameters

This class expresses the parameters given during path creation/ path verification. For further details related to these parameters, please refer to the SUN documentation.

Under this implementation, it is possible to use an instance of this class; however, parameters cannot be given for OCSP. Because of this, the GPKIBuilderParameters is used.

(3) java.security.cert.PKIXCertPathBuilderResult

This class is an object representing the execution result returned by the path creation provider. Please refer to the SUN documentation regarding the data involved. This implementation is done without any further modification.

(4) java.security.cert.PKIXCertPathChecker

This class is a certificate check object base class that can be used during path creation and path verification. The use method related to the SUN implementation exists for implementation of a user-defined certificate checker, almost exclusively using a provider-integrated checker for path creation and verification.

A PKIXCertPathChecker instance can be used with this implementation; however, a GPKICertPathChecker inheriting this class is required. The reason for this is that with just the PKIXCertPathChecker interface alone, only a small amount of data is given during execution; therefore, an extension must be provided so enough data is passed over.

(5) java.security.cert.PKIXCertPathValidatorResult

This class is an object representing the execution result returned by the path verification provider. Please refer to SUN documentation regarding the data involved. This implementation is done without any further modification.

5.2.2 Path Creation Provider Implementation

(1) Algorithms used for path creation

In this implementation, the path creation provider creates a path in a direction from the verification target to the TA (trust anchor). This is performed through an algorithm that searches through a group of signers' certificates using the signer name for the certificate under investigation.

When acquiring a issuer's certificate, there are cases where multiple certificates are existed. Acquiring multiple certificates means that multiple certificate paths exist. So, creating a mesh or tree structure with the certificate subject to verification at the root.

There are basically two ways to solve the problem of searching the desired route from this type of data structure.

The certification path creation problem is the problem of traversing the link between the certificates (i.e. a route from the certificate subject to verification to the certificate arriving at the trust anchor). Basically, this problem can be replaced with the problem of performing a route search for a directed graph.

Research into solutions for these problems has been carried on for ages, resulting in generally the two types of algorithms below:

(a) depth-first search

(b) width-first search

(a) Depth-first search

A search algorithm starting at an arbitrary point on a graph, and moving from that point to adjacent points.

Under this algorithm, there is one point worthy of particular attention. When it has been determined that an incorrect point has been moved to, the operation must be run again. In general, this type of operation is called "backtracking".

Figure 5‑1 Depth-first search

An advantage of this algorithm is simplicity and the ease of tracking context during operation. However, a large number of occurrences of backtracking can happen depending on the relationship between the problem space and the expected solution, increasing calculation time by an enormous amount. The forecasted calculation volume is (see http://aibm4.main.eng.hokudai.ac.jp/~kurihara/classes/AI/uninformed.ppt):

O(b^m)

provided that

b: average number of arcs in each point, and

m: greatest distance within the graph.

(b) Width-first search

A search algorithm starting at an arbitrary point on a graph, and then performing a simultaneous search through a route of all adjacent points formed into a set.

Figure 5‑2 Width-first search

In contrast to the depth-first algorithm, this algorithm does not create a backtracking problem, and the calculation volume is only what is necessary to reach the depth containing the solution. The forecasted calculation volume is:

O(b^d)

provided that

d: solution depth.

If one were to compare the calculation volume between a depth-first search and a width-first search by starting a search for the same problem space, b would be the constant, and therefore, the exponent d and m would determine the calculation volume.

In the relationship between d and m, it follows that d≦m, which means that in theory, a width-first search has a lower calculation cost than a depth-first search.

(c) Algorithm used in the sample implementation

This implementation uses a width-first search. The reasons behind this decision are as follows:

a) A certain level of performance can be expected, regardless of the location of the solution.

b) Potential solutions can be discovered simultaneously. Therefore, it is easy to perform extensions for estimating solutions.

Unfortunately, a simple application of a width-first search requires a large amount of memory. This is especially true if a certificate viewed as a node, and an arc is created for all certificates potentially combining in a node. In such a case the amount of memory needed is exponentially proportionate to the depth of the average number of branches.

To resolve this issue, the entity was viewed as a node, and the issued (dynamically discovered) certificate was viewed as an arc. By doing this, the volume of memory used was inversely proportionate to the number of certificates in the branches related to the aforementioned method.

It is also possible to partition the problem space in entity units, which also serves to minimize loss of execution speed related to large problem spaces.

5.2.3 Implementation of Path Verification Provider

The path verification provider function in this implementation conforms to RFC3280. The provider consists of a "general verification block" making a vertical partition of the RFC3280 verification algorithm and performing sequential verification, and a "policy processing block", creating a valid_policy_tree that makes the output requested by RFC3280.

The "general verification block" is constructed by the partitioning and organization of the algorithm defined by RFC3280. For each field, the PKIXCertPathChecker is expressed as the lowest base class instance, meeting standards by gathering multiple checkers.

In addition, the verification items that the user of the provider wishes to independently define are simultaneously processed by this portion.

The default (included) checkers are as follows:

□KeyUsageChecker
This checker verifies the validity related to KeyUsage extension within the certificate path.

□BasicConstraintChecker
This checker verifies the validity related to BasicConstraints within the certificate path.

□CRLRevocationChecker
Refers to CRL and verifies whether the certificate has been revoked or not. At this time, the verification of the CRL itself is also conducted.

□SignatureChecker
Confirms the validity of the signature and issuer name within the path.

□OCSPChecker
Refers to OCSP and verifies whether the certificate has been revoked or not. This operation is performed to the extent possible; if the information necessary to access the OCSP cannot be obtained, verification is not performed.

□NameConstraintsChecker
Verifies the validity related to naming constraints.

□DateChecker
Verifies the validity related to the certificate's expiration date.

The "policy processing block" creates the data output by the algorithm defined by the RFC, and it is in charge of the following extensions:

□Policy

□Policy mapping

□Policy constraints

□ANY POLICY INHIBIT

The processing results are output in the java.security.cert.PolicyNode requested by java.security.cert.PKIXCertPathValidatorResult.

5.3 Observations

5.3.1 Handling cases where no CRL is issued, and revocation information is only available through OCSP (commercial registration certificate authorities, etc.)

For certificate authorities that only provide revocation information through OCSP (commercial registration certificate authorities in Japan, etc.), if a CRL is requested by CRLDP, no CRLs will be able to be retrieved.

If a system warning is available, normal processing can be accomplished by sending a warning; however, for frameworks wherein a warning cannot be issued, it may be safer to return an error.

However, in cases where OCSP use is anticipated, errors are not permissible, so the CRL revocation function must anticipate OCSP.

5.3.2 For self-signed certificates with EE path creation (commercial registration certificate authorities)

For the path creation function, it is common to ensure that a node that has been passed once is not passed again.

In this case, even though a search is performed for a candidate issuer, the certificate is signed itself, suppressing further expansion beyond that point. In this state, the cross-certificate (even should it exist) cannot arrive at the trust anchor, resulting in a failure in path creation.

In actual operation, there is always the choice to ignore such an entity; however, we have decided to pursue the direction of path creation to the extent possible.

Although several methodologies are conceivable, the current focus is narrowed to cases where the first stage intermediate CA is searched, and a re-pass through a node that has already been passed is permitted.

In this manner a "self-signed certificate" ⇒ "cross-certificate" path is created, giving rise to the possibility for arriving at the trust anchor.

6 6 An Explanation of a Certificate Path Construction and Path Verification Implementation through CryptoAPI

The security platform for Microsoft Windows uses CryptoAPI. When developers use CryptoAPI in their programs, then encryption primitive and certificates can be used.

For this project, a "digital signature program" and a "digital signature and certificate verification program" were developed. Both of these programs utilize CryptoAPI.

The "digital signature and certificate verification program" consists of a user-interface program (the file subject to verification is the input) and a program that performs certificate path/ path verification functions.

6.1 Overview of CryptoAPI

6.1.1 API Classifications

The following figure shows the CryptoAPI structure. On the left side of the figure are functions related to the certificate, and on the left side are functions related to encrypted messages, namely CMS (PKCS#7). The lower portion of the figure shows functions providing encryption primitive.

Figure 6‑1 CryptoAPI Structure

Under CryptoAPI, CMS (Cryptographic Message Syntax) is a successor specification having upward compatibility with PKCS#7. CryptoAPI conducts processing assuming CMS. Therefore, for purposes of this section we will refer to CMS, rather than PKCS#7.

These functions are further classified as shown below:

Table 6‑1 CryptoAPI Function Categories

Base Cryptography Functions	Function for using encryption algorithm
Certificate and Certificate Store Functions	Function to access certificate store
Certificate Verification Functions	Function to acquire, verify certificate path
Message Functions	Function to create, analyze CMS
Auxiliary Functions	Auxiliary functions to handle related data
CSP Functions	Function for CryptoServiceProvider and I/F
Certificate Services Backup and Restore Functions	Functions related to certificate store backup
Callback Functions	Callback functions related to certificate store

6.1.2 Certificate Store and Elements

In the Windows system, a public key certificate handled under PKI is called a "certificate store". The certificate store is saved in a repository using local disk and registry memory, and is accessed through CryptoAPI. The standard certificate stores in the system are divided into one for "current user" and one for "local computer". Each has a certificate store for the types of certificates listed below:

"personal":certificate for private key and pair

"other people":certificate for other EE

"intermediate certificate authority":certificate for an intermediate CA

"trusted root certificate authority":certificate for a root CA making up the trust point

The following elements are among those used when the related major functions of PKI are handled by CryptoAPI.

Table 6‑2 Representative CryptoAPI Elements

Elements	Role
CERT_INFO	Contains information for each analyzed certificate field
CERT_CONTEXT	Contains certificate context, certificate binary data and CERT_INFO
CRL_INFO	Contains information for each analyzed CRL field
CRL_CONTEXT	Contains CRL context, CRL binary data and CRL_INFO
CTL_INFO	Contains information for each analyzed CTL field
CTL_CONTEXT	Contains CTL context, CTL binary data and CTL_INFO

The following shows the flow for using CryptoAPI to acquire a certificate from the certificate store at the intermediate CA.

HCERTSTORE hCertStore; /*certificate store bundle*/

PCCERT_CONTEXT pCertContext=NULL; /*certificate context*/

hCertStore = CertOpenSystemStore(NULL, "CA");

while (pCertContext = CertEnumCertificatesInStore(hCertStore, pCertContext))

{

char szNameString[256];

CertGetNameString(pCertContext, CERT_NAME_RDN_TYPE,0,

NULL, szNameString, 256);

printf("subject : %s\n", szNameString);

}

CertFreeCertificateContext(pCertContext);

CertCloseStore(hCertStore, CERT_CLOSE_STORE_CHECK_FLAG);

6.1.3 Certificate Trust List (CTL)

The certificate trust list ("CTL") is a distribution format for trustworthy certificates under CryptoAPI. This is a data format unique to CryptoAPI, used to notify a user of a certificate and the certificate's intended purpose. An administrator's digital signature can be attached to this certificate trust list, allowing for the safe distribution of the certificate. CTL was used for passing the trust point certificate between modules in the implementation introduced here.

6.1.4 Functions for Certificate Path Verification

(1) Certificate Path Verification Functions

Normally, functions noted in "Certificate Verification Functions" are used for acquiring a certificate path using CryptoAPI, and for path revocation verification. These functions were also used for development related to the project discussed herein. Section 6.2.3 provides more details.

(2) Acquiring certificate status via CertVerifyRevocation

Classified among "Auxiliary Functions", CertVerifyRevocation can be used to confirm the status of a certificate. This function differs from the "Certificate Verification Functions" covered earlier, which are functions used to perform some operation on a certificate path. The purpose of this function is to take each certificate context as inputs, and acquire the status of a particular single certificate. One notable point about this function is that developing a arbitrary revocation verification routine, and then registering it in the system as a Revocation Provider, results in calling the registered revocation verification routine within the function. A Revocation Provider is expressed as CertDllVerifyRevocation function exported as a DLL file. In other words, the CertVerifyRevocation dynamically loads a DLL internally, passing parameters directly to the CertDllVerifyRevocation, and receiving the results also as parameters.

The following registry key is used for registering within the system:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 1\CertDllVerifyRevocation\DEFAULT\Dll

More than one Revocation Provider can be registered, and the call order can be designated based on the DLL implementation. Cryptnet.dll, mscrlrev.dll and several others come standard in the operating system. Revocation Providers enabling path construction and path verification were developed for the project discussed herein. Section 6.2.3 provides more information about this topic.

(a) About existing applications

Some applications using a general CryptoAPI perform revocation verification using CertVerifyRevocation. In such case, there are times when settings through the applications are necessary. The following discusses these settings in more detail.

l Outlook Express settings

From the menu, select "Tools" and then "Options". Click on the "Security" tab, and then open the "Advanced Security Settings". Here, select the option that says, "check for revoked digital IDs", and mark "only when online".

l Internet Explorer settings

Under the Internet Options menu, select "Advanced Settings", and then mark "check for server certificate revocation".

l PKI settings for IPsec/ISAKMP

Special settings are needed to acquire the CRL through CRLDP and perform revocation verification when a public key certificate is used in IPsec/ISAKMP negotiations. The following key must be added to the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\Oakley

Adding "StrongCrlCheck" as the DWORD value.

Ø StrongCrlCheck = 0. Do not perform CRL verification.

Ø StrongCrlCheck = 1. Perform CRL verification.

Ø StrongCrlCheck = 2. Perform CRL verification, and if an appropriate CRL cannot be acquired, treat the certificate as invalid.

After the values are added or changed, type

>net stop policyagent

>net start policyagent

from the command prompt to effect the change in settings.

(b) CRL cache

The standard cryptnet.dll caches an acquired CRL. The Internet Explorer's Temporary Internet Files directory, for example, is where the CRL is cached.

6.1.5 References

Please see the following regarding Revocation Providers: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/rpcrypto.asp

The following URL contains more information related to CryptoAPI certificate verification.

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/prodtech/dbsql/tshtcrl.asp

6.2 Explanation of the Sample Implementation

We developed a sample implementation to process digital signatures and perform signature verification appropriately in a PKI environment consisting of a bridge CA model using CryptoAPI.

6.2.1 Development Environment

The program described herein was developed using the following environment:

Compiler: Microsoft Visual C++ V6.0 SP5

CryptoAPI Library: Microsoft Platform Software Development Kit (SDK)

6.2.2 Test Program

We developed the following two test programs for a sample implementation using CryptoAPI:

l digital signature program pkiicsig.exe

l digital signature and related certificate verification program pkiicsver.exe

We will explain further about these two implementations below.

(1) Digital signature program pkiicsig.exe

This program attaches a digital signature to the credential file received by the command line as the signer. The following figure illustrates the signature process flow.

Figure 6‑2 Signature Processing Flow

(2) Digital signature and related certificate verification program pkiicsver.exe

For a file subject to verification with CMS signedData, a verification of the digital signature is performed first. When a signer's certificate is attached to a CMS signedData file, or when the file subject to verification is a X.509 DER-encoded certificate file, certificate path construction and path verification are performed. A more detailed discussion related to path construction and path verification mechanisms are available elsewhere in this report. Here, we will discuss aspects related to pre-processing.

The Windows systems comes with a standard certificate store, trust point root certificate store, intermediate CA certificate store, EE certificate store (for other persons), and certificate store (for itself) that has private keys in a pair. CRL and CTL are contained in the CA certificate store. In the project discussed herein, the number of certificates used in certificate path construction was limited by necessity. As a result, a temporary certificate store was created (separate from the aforementioned standard certificate stores), and referenced within the program. The major role played by the path construction and path verification pre-processing is in the creation of this temporary certificate store. Pre-processing includes the following procedures:

① Create temporary certificate store for trust point

② Create CTL from trust point certificate

③ Add trust point certificate to temporary certificate

④ Add CTL to temporary certificate

⑤ Create temporary certificate store for intermediate CA

⑥ Add intermediate CA certificate to temporary certificate

⑦ Add intermediate CA-issued CRL and ARL to the temporary certificate

In addition, parameters related to policy-constraints are saved in a settings file (pkiic.dat) in a key similar to that below. These settings are used by "Original path construction and path verification routines" related to "Path construction and path verification mechanisms" (to be addressed later).

[common] section

InitialPolicyMappingInhibit = false

InitialExplicitPolicy =false

InitialAnyPolicyInhibit = false

InitialPolicy0= 0.2.392.200117.1.9.2002.2.1.2.392.100595.8.5.1.1.10

6.2.3 Path Construction and Path Verification Mechanisms

We developed the following two implementations for path construction and path verification used for certificate verification by the digital signature and certificate verification program. One of these two may be selected in the settings file of the test program.

l Implementation using the CryptoAPI "Certificate Verification Functions"

l Implementation of "Original path construction and path verification routines" with CryptoAPI Revocation Provider.

Following is a discussion related to these two implementations.

(1) Implementation using the CryptoAPI "Certificate Verification Functions"

Performs verification using functions classified as "Certificate Chain Verification Functions" (from among "Certificate Verification Functions"). A "certificate path engine" is created to verify the certificate in question. Following is a further explanation.

(a) Certificate path engine

For path construction and path verification, a "certificate path engine" is created, and then a revocation verification is conducted on the certificate that is obtained from the certificate store over the certificate path based on the designated "certificate path engine".

For the "certificate path engine", a temporary certificate store is created as a subset of the root certificate store in the system, making it possible to define limits for the trust point certificate. In addition, a temporary certificate store (separate from the intermediate CA certificate store) is created, and added or referenced in a limited manner during the path construction process, made possible by storing the certificate and the CRL. Also, the verification method may also be designated (extended key usage, CTL usage, etc.).

(b) Verification processing

Parameters available for use during verification include verifying the existence of an EE certificate revocation verification, the existence of a certificate revocation verification on the path, cache usage, and verification performed at a certain date and time.

For revocation verification, the function CertverifyRevocation is called internally, which engages the registered RevocationProvider.

Under this method, initial parameters related to policy constraints cannot be referenced.

In addition to the certificate path, certificate trust information, in the form of error status and reference information (including those shown below), are also received as a result of the process.

Table 6‑3 CryptoAPI Path Verification Diagnostic Values

#	Defined Names for Error Codes
	Meaning
Errors related to certificate subject to verification, or certificate path
1	CERT_TRUST_NO_ERROR
	No problems with certificate or path.
2	CERT_TRUST_IS_NOT_TIME_VALID
	Unacceptable expiration date for certificate(s) subject to verification or certificate(s) within path.
3	CERT_TRUST_IS_NOT_TIME_NESTED
	Related expiration date for certificate within path is not appropriate.
4	CERT_TRUST_IS_REVOKED
	Revoked trust point certificate(s) or certificate(s) within path.
5	CERT_TRUST_IS_NOT_SIGNATURE_VALID
	Invalid signature for certificate(s) subject to verification or certificate(s) within path.
6	CERT_TRUST_IS_NOT_VALID_FOR_USAGE
	Certificate(s) subject to investigation or certificate(s) within path does not match designated key usage.
7	CERT_TRUST_IS_UNTRUSTED_ROOT
	Certificate path is based on an untrustworthy root certificate authority
8	CERT_TRUST_REVOCATION_STATUS_UNKNOWN
	Revocation status is uncertain for certificate(s) subject to verification or certificate(s) within path.
9	CERT_TRUST_IS_CYCLIC
	Certificate path is circular.
10	CERT_TRUST_INVALID_EXTENSION
	Invalid extension in use.
11	CERT_TRUST_INVALID_POLICY_CONSTRAINTS
	Certificate(s) subject to verification or certificate(s) within path contains policy constraint extension(s), but policy mapping is prohibited or certificate(s) exists for which a policy is required but not attached.
12	CERT_TRUST_INVALID_BASIC_CONSTRAINTS
	Certificate(s) subject to verification or certificate(s) within path contains primary constraint extensions, but violates CA constraints or path length constraints.
13	CERT_TRUST_INVALID_NAME_CONSTRAINTS
	Certificate(s) subject to verification or certificate(s) within path contains invalid name constraint extension.
14	CERT_TRUST_HAS_NOT_SUPPORTED_NAME_CONSTRAINT
	Certificate(s) subject to verification or certificate(s) within path contains a name constraint extension for a field not supported. Minimum and maximum field is not supported. Accordingly, the minimum value is always 0, and no maximum value can exist. MicrosoftUPN(1.3.6.1.4.1.311.20.2.3) is supported as otherName. X400Address, ediPartyName, registeredID are not supported.
15	CERT_TRUST_HAS_NOT_DEFINED_NAME_CONSTRAINT
	Certificate(s) subject to verification or certificate(s) within path contain name constraint extension; however, there is no constraint related to field(s) used for certificate name.
16	CERT_TRUST_HAS_NOT_PERMITTED_NAME_CONSTRAINT
	Certificate(s) subject to verification or certificate(s) within path contain name constraint extension and permitted Subtrees field; however, one or more certificates contains an unpermitted name.
17	CERT_TRUST_HAS_EXCLUDED_NAME_CONSTRAINT
	Certificate(s) subject to verification or certificate(s) within path contains name constraint extension and excludedSubtrees field; however, one or more certificates contains a name that cannot be accepted.
18	CERT_TRUST_IS_OFFLINE_REVOCATION
	Revocation information related to certificate(s) subject to verification or certificate(s) within path is either offline or outdated.
19	CERT_TRUST_NO_ISSUANCE_CHAIN_POLICY
	Policy for policy constraint extension is requested; however, one or more certificates do not meet required policies.
Errors Related to Certificate Path
20	CERT_TRUST_IS_PARTIAL_CHAIN
	Certificate path is not complete.
21	CERT_TRUST_CTL_IS_NOT_TIME_VALID
	CTL used to construct this certificate path is outdated.
22	CERT_TRUST_CTL_IS_NOT_SIGNATURE_VALID
	CTL used to construct this certificate path does not have a valid signature.
23	CERT_TRUST_CTL_IS_NOT_VALID_FOR_USAGE
	Usage of CTL used to construct this certificate path is not appropriate.
Reference Information (not errors)
24	CERT_TRUST_HAS_EXACT_MATCH_ISSUER
	Certificate is from an appropriate issuer source.
25	CERT_TRUST_HAS_KEY_MATCH_ISSUER
	Certificate is from an issuer source having an appropriate key.
26	CERT_TRUST_HAS_NAME_MATCH_ISSUER
	Certificate is from an issuer source having an appropriate name.
27	CERT_TRUST_IS_SELF_SIGNED
	Self-signed certificate exists.
28	CERT_TRUST_IS_COMPLEX_CHAIN
	Multiple certificate paths exist.
29	CERT_TRUST_HAS_PREFERRED_ISSUER
	Appropriate issuer source.
30	CERT_TRUST_HAS_ISSUANCE_CHAIN_POLICY
	Policy exists.
31	CERT_TRUST_HAS_VALID_NAME_CONSTRAINTS
	Valid name constraint exists.

(c) Process flow

The following figure illustrates the flow when using the CryptoAPI "Certificate Verification Functions".

Figure 6‑3 Implementation Flow Using CryptoAPI

"Certificate Verification Functions#"

(2) Implementation of "Original path construction and path verification routines" as a CryptoAPI Revocation Provider

(a) Overview

The development related to path construction and path verification for the project described herein improved the open-source library CML (Certificate Management Library). This library is a part of the product coming out of the "DoD Bridge CA Technology Demonstration" project related to FPKI in the U.S.

The following illustrates the relationship to the CML module.

Figure 6‑4 CML Module Relationship Diagram

Next, we will show the modules developed during this project. The major CML modifications include those below:

l Alteration of CML itself

OCSP implementation

HTTP-based CRL acquisition

l Creation of a callback function capable of designating a CML

Reference a temporary certificate store, without using a CML database.

Added advanced search features beyond standard LDAP search function.

Figure 6‑5 Path Construction, Path Verification Routine Module

(b) Process Flow

The process flow of the implementation of "Original path construction and path verification routines" as a CryptoAPI Revocation Provider is shown below.

Figure 6‑6 CryptoAPI Revocation Provider Process Flow

(c) Regarding the path construction and path verification processing algorithm:

1.Path Construction Verification Operations (Initiating Certificate)

while verification success or until retry limit

if first path construction

constructed path ← path construction (initiating certificate) ……[2]

else

constructed path ← next path construction (initiating certificate) ……[3]

if path construction success?

path verification (constructed path) ……[6]

if verification success?

return constructed path

return path construction failure

2.Path Construction (constructing certificate), 3. Next Path Construction

if constructing certificate is trust point

return path containing one constructing certificate1

certificate list ← searches for certificate (constructing certificate Issuer name) ……[4]

Sort by priority order (certificate list) ……[5]

foreach certificate in certificate list

path ← path construction (certificate)

if path construction success

return [ path, certificate ] …… add certificate to end of path

If the path returned here fails verification, begin next foreach loop

return path construction failure

4. Search for Certificate (Issuer Name)

In offline mode

Return list of certificates with matching temporary store issuer name and subject name

In online mode (default)

List certificates with matching issuer name and subject name in the DB

If repository, retrieve and list certificates where DN=issuer name

Merge and return certificates retrieved from DB and repository

5. Sort by Priority Order

Priority order is total of next points

1. SKI and AKI matches +8

2. SKI and AKI do not match –6

3. SKI or AKI are missing +2

4. Certificate is trust point +4

5. Certificate is CA certificate +3

6. Certificate is EE certificate +2

7. Certificate is cross-certificate +1

(Look at other V2 UniqueID, prioritize cache, etc.)

6. Path Verification (list of certificates within path)

Initialize valid policy from trust point certificate

while certificate in list certificates within path

validity verification (certificate) …… [7]

certificate policy map calculation

valid policy update

return verification success

7. Validity Verification (certificate)

Verify the following points

1. Verify whether certificate signature algorithm matches issuer's signature algorithm

2. Verify signature

3. Verify valid date

4. Verify whether issuer and subject DN matches

5. Revocation verification (certificate) ……[8]

6. BasicConstraint verification (if CA, confirm CA flag)

7. KeyUsage verification (if CA, confirm certSign)

8. If KeyUsage is critical, verify whether unknown KeyUsage exists

9. Verify name constraints, path length constraints

10. If subjectAltName is critical, verify whether unknown format exists

11. Verify subjectAltName name constraints

12. Verify policy constraints

13. Verify whether unknown critical extension exists

8. Revocation Verification (certificate)

if OCSP verification mode is "URL Designation" and URL is not empty string

OCSP verification(designated URL) ……[10]

if valid

return valid

if revoked

return revoked

if AIA exists, and OCSP verification mode is "follow AIA" (default)

foreach AIA1 in AIA

if AIA1 OID is OCSP

OCSP verification(AIA1 URL) ……[10]

if valid

return valid

if revoked

return revoked

if CRLDP exists

foreach name in CRLDP

CRL verification (name) …… [9]

else

CRL verification (Issuer name) …….[9]

9. CRL Verification (URL or DN)

Retrieve CRL from temporary certificate store

if CRL exists, and next issue date has not passed

return search CRL and return revocation results

if not remote retrieval mode for CRL

return latest CRL unavailable or CRL cannot be retrieved

if URL designated

retrieve CRL from URL

else

Retrieve CRL from directory server with designated DN

if retrieval failure

return CRL cannot be retrieved

if CRL's next issue date is passed

return no new CRL

return search CRL and return revocation results

10.OCSP-based Verification (server URL)

OCSP response ← inquiry to server URL over HTTP

Response signature verification

Path construction verification operations (response certificate) ......[1]

However, limited to offline (temporary certificate store) path construction, CRL reference

If id-pkix-ocsp-nocheck is in response, revocation verification[8] is not performed

(d) Regarding repository search methods

The following shows the usage method of LDAP API when retrieving certificates and CRLs from a directory server:

Performed an anonymous bind with ldap_init, and set the following using ldap_set_option:

LDAP_OPT_PROTOCOL_VERSION : LDAP_VERSION3

LDAP_OPT_REFERRALS : LDAP_OPT_ON

LDAP_OPT_DEREF : LDAP_DEREF_ALWAYS

The arguments for ldap_search_st include the following:

Certificate Search
Base DN	Issuer DN
Scope	LDAP_SCOPE_BASE
filter	objectclass=*
attrs	Designate following attributes: cACertificate crossCertificatePair cACertificate;binary crossCertificatePair;binary
attrsonly	FALSE
CRL Search
Base DN	Issuer DN
Scope	LDAP_SCOPE_BASE
Filter	objectclass=*
attrs	Designate following attributes: certificateRevocationList authorityRevocationList certificateRevocationList;binary authorityRevocationList;binary
attrsonly	FALSE

6.3 Observations

6.3.1 CertVerifyRevocation: Ostensibly for Revocation Confirmation

The logic-derived return value for CertVerifyRevocation is FALSE if a revocation has occurred, or TRUE if revocation has not occurred, including reasons for revocation as arguments in defined output. However, the purpose of the present implementation extends beyond simply confirming revocation. Another purpose is confirming the validity of the certificate resulting from path construction and path verification, therefore, the return value for which is TRUE if the path verification result is valid, and FALSE if invalid.

6.3.2 Initial Policy Parameters

No particular consideration has been given to initial parameters related to policy constraints for CryptoAPI.

6.3.3 OS-related CryptoAPI Differences

Supported functions differ between Windows 9x/Me and NT4/2000/XP, with some functions not available under the 9x/Me series. Also, some differences within the NT4/2000/XP series exist (between XP and 4/2000), such as the following:

(1) Path verification routine CertGetCertificateChain

CertGetCertificateChain is a function that performs the appropriate revocation verification on a certificate path obtained from a certificate store, verifying the legitimacy of the path (the present project also uses this function, which will be discussed later). The certificate store contains a cross-certified CA certificate and the CA's self-signed certificate. In cases where verification of the CA-issued certificate is performed, the certificate path is processed correctly under Windows XP; however, under Windows 2000, the certificate path ends with the CA's self-signed certificate, and does not reach the trust point.

(2) Certificate properties dialog display CryptUIDlgViewContext

Under Windows XP, the context of selected certificates, CRLs and CTLs (as arguments) can be passed to this function exported in cryptoui.dll, and display a dialog referencing standard certificates, CRLs and CTLs properties used in Windows. However, cryptoui.dll contained in the operating systems preceding Windows 2000 does not have this function.

7 7 Test Suite

In this section, we will briefly cover the PKI Interoperability Test Suite ("Test Suite"), supported test cases, and test performance procedures. Also, we will touch on the usage method for the certificate verification program used in the Test Suite.

7.1 Test Suite Overview

The Test Suite is comprised of the following two elements (Figure 7-1).

(1) A database storing information necessary for performing the tests ("DB"). As necessary, the DB can also store test results.

(2) Data sets based on the DB content used for running tests (certificates, CRL, OCSP/GCVS response data, etc.), and script programs need to create files (scripts, etc.) to run tests.

We will not address the specifications for various script programs here, since they are available in their respective specification sheets.

Testing was performed either in "online mode" or "offline mode". In online mode, path verification was performed after the necessary certificates, CRLs and ARLs were registered in an LDAP server (repository). Accordingly, the testing program acquired the certificates, CRLs and ARLs necessary for path verification from the repository.

In contrast, the offline mode certificates, CRLs and ARLs were not registered in an LDAP server. The test program acquired these items from a local file. The following section explains differences in testing procedures based on whether tests were conducted online or offline.

Figure 7‑1 Test Suite Overview Diagram

7.2 Test Categories

The DB design sheet contains the full details related to the DB. In this section, we will cover test cases supporting the Test Suite.

As shown in Table 7-1, the DB contains three categories of test cases. In this table, when the "Online (Offline)" column indicates "Y", then tests could be performed in either online or offline modes.

Table 7‑1 Test Case Categories

Category Number	Category	Online	Offline	Test Case using OCSP	Test Case using GCVS
1	NIST Test Case	No	Yes	No	No
2	GPKI Test Case	Yes	Yes	Yes	Yes
3	Original Test Case	Yes	Yes	Yes	No

When the columns headed "Test Case using OCSP" or "Test Case using GCVS" indicate "Y", some of the test cases included used OCSP or GCVS (GPKI Certificate Verification Server).

When test cases using OCSP or GCVS were run in offline mode, inquires could not reach the OCSP responder simulator or GCVS server simulator, creating unexpected test results in some instances.

Following are descriptions of each category:

(1) NIST test case

The NIST test case was created based on the X.509 Path Validation Test Suite (http://csrc.nist.gov/pki/testing/x509paths.html) of the U.S. National Institute of Standards and Technology. A test level (degree of test difficulty) was set for each NIST test. Please refer to chapter three of the GPKI Test Case Design Sheet, "NIST Path Verification and Equivalent Test Cases" for more detailed information.

(2) GPKI test case

The GPKI test cases were created with a mind toward the various path verification situations encountered in Japan's Government Public Key Infrastructure (http://www.gpki.go.jp/). Some test cases used OCSP, while others used GCVS. Please see chapter two of the GPKI Test Case Design Sheet, "GPKI Simulation Test Cases" for more detailed information.

(3) Original test case

Original test cases were created to perform high-level path verification, including NameRollover and KeyUpdate operations. Test cases included some using OCSP. Please see chapter four of the GPKI Test Case Design Sheet, "Original Test Cases" for more detailed information.

7.3 Test Flow

The complete Test Suite flow is described in detail in the "Test Environment Design Sheet". This section briefly describes testing steps and commands used from the point of the tester ("user").

7.3.1 Testing Steps

Users performed testing using the following three procedures.

(1) Users first ran the "Test Environment Creation Script" on a machine running the DB ("server"). The "Test Environment Creation Script" enacts all of the scripts and programs in order for the Test Suite. This creates all of the data for the designated test program and testing scripts ("data and scripts") within the test data area (Figure 7-1). Accordingly, users need only use the Test Environment Creation Script when creating the test data area, or in other words, the user need not directly run any other type of script.

(2) Next, the user begins testing using the data and scripts created in the test data area. The testing machine is called the "client". If the server and client are on different machines, the user must copy the existing test data area in advance using an ftp command etc.

(3) Testing on the client is performed using the "Testing Script". The Testing Script runs a prepared test case testing script in order for each test case, and then saves the test results. Accordingly, users need only run the Testing Script during testing procedures.

During testing procedures, the user need only run the two test suite programs: the Test Environment Creation Script and the Testing Script. Following is an overview explanation of how these scripts operate.

7.3.2 Test Environment Creation Script

Once the user runs the Test Environment Creation Script, all of the necessary data and scripts are created. Table 7-2 shows the representative options available when running the script.

Table 7‑2 Representative Test Environment Creation Script Options

Format	Explanation
-c Test Category ID	If multiple designated, separate by spaces, all if not designated
-l Test Level	If multiple designated, separate by spaces, all if not designated
-m Access Mode (on\|off)	Select whether test uses LDAP, default is 'on'

Options "-c", "-i", and "-l" are used to designate the test case under which data and scripts are created. If no option is selected, all test cases are included.

Figure 7‑2 Test Environment Creation Script Flow

Figure 7-2 shows the operation flow of the Test Environment Creation Script. From the Test Environment Creation Script, the Test Data Creation Script, Test Script Creation Script, General Certificate Creation Program and General CRL Creation Program are run (as external commands), resulting in the creation of data and scripts for the relevant test case.

A more detailed explanation of the Test Environment Creation Script is available in the Test Environment Creation Script Specification Sheet.

7.3.3 Testing Script

Once the user runs the Testing Script, testing commences based on the data and scripts created by the Test Environment Creation Script.

Table 7-3 shows the most commonly used options available when running the Testing Script.

Table 7‑3 Representative Test Environment Creation Script Options

Format	Explanation
-lh LDAP host name	Designate LDAP host name when running test online
-s DB server name	Designate to store test results in DB

Testing Scripts run the tests by running each Test Case Run Script, which is prepared for each test case, in order. If necessary, test results can be saved in the database.

The Test Case Run Script is a script automatically created by the Test Environment Creation Script. The Test Case Run Script differs depending on the mode being used (online/ offline). The operation flow of the Test Case Run Script created for online mode, and the Test Case Run Script created for offline mode are shown in Figures 7-3 and 7-4, respectively.

In online mode (Figure 7-3), the Test Case Run Script will launch a server-side test environment creation program immediately prior to running the test program and performing path verification. The test environment creation program prepares the information required for the OCSP responder simulator, and by running the LDAP registration script, the certificate, the CRL and ARL are registered in the LDAP server.

Next, the Test Case Run Script launches the program to be tested. This program sends an inquiry to the LDAP server to acquire a certificate, CRL and ARL. Depending on the test case, the program may also send an inquiry to the OCSP responder simulator.

Lastly, a test results loader is run (if necessary) to save the results of the tested program in the DB.

Figure 7‑3 Test Case Script Flow (online)

In offline mode (Figure 7-4), rather than running the test environment creation script as in online mode, the program to be tested is launched by the Test Case Run Script. The program subject to testing acquires the certificate, CRL and ARL from a local file, rather than making an inquiry to the LDAP server.

Once the test program has been launched, operation is the same as that of the online mode, with test program results saved to the DB by running the test results loader, as necessary.

Figure 7‑4 Test Case Script Flow (offline)

7.3.4 Program subject to Testing

The program subject to testing is a program that acquires certificates, CRLs and ARLs from a local file (offline) or repository (online), and then verifies the certificate's validity, using an OCSP responder, if necessary.

Here, we will discuss the usage of the program subject to testing. The user never directly launches the program to be tested in any of the test steps included for the Test Suite. For detailed specifications related to programs subject to testing, please refer to "Program Subject to Testing: External Specification Sheet". Table 7-4 shows an overview of programs subject to testing.

Table 7‑4 Overview of Programs to be Tested

Format

gpkverify [option] ipcy1 ipcy2 … ipcy<n>

Function

Use designated certificate and/or policy, conduct signature verification, certificate verification for subject data

End Status

0 Normal finish.

>0 Verification error occurred.

<0 Internal error (system error) occurred.

Under the program to be tested, initial-policy-set can be set to certain selected values using the arguments below:

gpkverify init-policy1 init-policy2 …… init-policy<n>

If policy values are to be set in this manner, each argument is separated by a space (spacebar). Policies can be omitted, indicated by NULL. The following values are available for use.

"ANY" :When accepting all policies (any-policy).

"NULL" :No set policies (NULL).

However, if the –ie option is valid, arguments must be set to something other than NULL.

Table 7-5 shows the available options related to the program subject to testing.

Table 7‑5 List of Options for Programs to be Tested

Option	Option Arguments	Explanation
-v	None	Displays specification version upon which test program is based. Required implementation.
-d	File Name	Designates data file subject to signature verification.
-f	Path Name	Designates folder/ directory storing data file subject to signature verification, certificate verification. If data designated by –f option, all files under path-designated folders/ directories are subject to verification.
-c	File Name	Designates certificate file subject to verification (der format). If –c option is designated, signature verification is not performed, and only certificate verification (certificate path construction, verification) is conducted.
-t	File Name	Designates self-signed certificate file of the signer, certificate verification trust anchor (der format).
-P	[File Name]	Designates intermediate Ca certificate file. If no intermediate certificate file exists, "-P" only is given. If multiple files are designated, separate by a colon (":"). If this option is designated, operation is conducted in offline mode, and no inquiry is made to repository or OCSP. ※
-ip	None	Designates whether initial-policy-mapping-inhibit flag is valid/ invalid. Valid, if –ip option exists.
-ie	None	Designates whether initial-explicit-policy flag is valid/ invalid. Valid, if –ie option exists. In such case, command arguments (designating initial-policy-set) must be other than NULL.
-ia	None	Designates whether initial-any-policy-inhibit flag is valid/ invalid. Valid, if –ia option exists.
-l	Host Name	Designates LDAP server host and port number in "IP address: Port number" format or "FQDN: Port Number" format.

※ For the CRL/ARL issued by each CA, the file name extension of each CA certificate (trust anchor, intermedaite CA certificate) is read as .crl or .arl . All of these files are under the path designated with a –f.

The following illustrates examples of signature verificaiton and certificate verification used for the program subject to testing.

<Example 1> Signature verification

Use cn=test,o=gpki,c=jp as signer, tanchor.cer as verification-side trust anchor certificate, and ldap.gpki.go.jp as certificate repository. Validate the initial-explicit-policy flag, and perform signature verification for file test.p7m.

gpkverify -d test.p7m -t tanchor.cer -ie -l ldap.gpki.go.jp ANY

Signature verification: ng[cert expire] - signer certificate is expired.

<Example 2> Certificate verification in online mode

target.1.1.1crt (under /project/date) is the certificate file subject to verification. Trust.1.1.1.crt serves as the trust anchor certificate file, and certificate verification only is conducted in online mode. Signature verification is not performed.

gpkverify -f /project/data -c target.1.1.1.crt -t trust.1.1.1.crt -l ldap.gpki.go.jp:389

<Example 3> Certificate verification in offline mode

target.1.1.1crt (under /project/date) is the certificate file subject to verification. Certificate verification only is conducted with trust.1.1.1crt as the trust anchor certificate file in offline mode.

Intermediate.1.1.1.crt and intermediate.1.1.2.crt are the intermediate CA certificate files. The various files for the trust anchor and intermediate CA CRL/ ARL having the .crl or .arl extensions are referenced.

gpkverify -f /project/data -c target.1.1.1.crt -t trust.1.1.1.crt -P intermediate.1.1.1.crt:intermediate.1.1.2.crt

7.3.5 Test using GPKI Certificate Verification Server

To run tests for the test suite using the GPKI certificate verification server simulator ("GCVS simulator") different steps than the ones described above are necessary. The only test cases capable of being used with the GCVS simulator are the nine test cases shown in Table 7-6. Details related to each test case can be found in the "GPKI Test Case Design Sheet".

Table 7‑6 List of Test Cases using GPKI Certificate Verification Server

Test Case Number	Trust Anchor	Verification Subject	Status of Certificate (EE) Subject to Verification
2000700	MPHPT	METI	Normal
2001000	MPHPT	Asign2	Normal
2001200	MPHPT	MOJ	Normal
2003400	MPHPT	METI	Revoked
2003700	MPHPT	Asign2	Revoked
2003900	MPHPT	MOJ	Revoked
2006100	MPHPT	METI	Expired
2006400	MPHPT	Asign2	Expired
2006600	MPHPT	MOJ	Expired

In order to run tests utilizing the GCVS simulator, the GPKI certificate verification server simulator set-up script must first be run to prepare for the test. This script contains a function that prepares data necessary to respond to an inquiry from a GCVS client in advance. In other words, it plays a role similar to the Test Environment Creation Script for the Test Suite. A more detailed explanation related to the GPKI certificate verification server simulator set-up script can be found in the "GPKI Certificate Verification Server Simulator Set-Up Script Specification Sheet".

After the user runs the GPKI certificate verification server simulator set-up script, testing can be performed by launching the GCVS client. A detailed explanation of the GCVS client can be found in the "GPKI Certificate Verification Client Specification Sheet".

7.4 Observations Taken from Test Results

7.4.1 GPKI Simulation Test Case Results and Observations

(1) Sample program test results

Here, we will show the original test results for the CryptoAPI sample program, the Java sample program, and JDK 1.4. Table 7-7 indicates whether a test ran according to expectations (○), or ran counter to expectations (×).

Table 7‑7 GPKI Simulation Test Results

Test Case	Expected Value	CAPI sample	Java sample	Sun JDK 1.4	Java Sample Implementation Notes
2000100	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2000200	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2000300	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2000400	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2000500	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2000600	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2000700	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2000800	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2000900	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2001000	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2001100	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2001200	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2001300	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2001400	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2001500	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2001600	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2001700	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2001800	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2001900	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2002000	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2002100	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2002200	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2002300	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2002400	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2002500	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2002600	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2002700	Pass	○	○	×	CRL include IDP, But provider can not process like this.
2002800	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2002900	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2003000	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2003100	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2003200	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2003300	Fail	×	×	○	CRL include IDP, But provider can not process like this.
2003400	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2003500	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2003600	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2003700	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2003800	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2003900	Fail	×	×	○	CRL include IDP, But provider can not process like this.
2004000	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2004100	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2004200	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2004300	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2004400	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2004500	Fail	×	×	○	CRL include IDP, But provider can not process like this.
2004600	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2004700	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2004800	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2004900	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2005000	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2005100	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2005200	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2005300	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2005400	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2005500	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2005600	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2005700	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2005800	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2005900	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2006000	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2006100	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2006200	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2006300	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2006400	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2006500	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2006600	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2006700	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2006800	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2006900	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2007000	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2007100	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2007200	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2007300	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2007400	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2007500	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2007600	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2007700	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2007800	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2007900	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2008000	Fail	○	○	○	CRL include IDP, But provider can not process like this.
2008100	Fail	○	○	○	CRL include IDP, But provider can not process like this.

7.4.2 NIST Test Case Results and Observations

(1) Sample program test results

The following shows the original test results for the CryptoAPI sample program, Windows 2000 standard CryptoAPI, Windows XP standard CryptoAPI, Java sample program, and JDK 1.4. (Table 7-8)

Table 7‑8 NIST Test Case Results

Test Case	Expected Value	CAPI sample	Win 2000	Win XP	Java sample	Sun JDK 1.4	Java Sample Implementation Notes
1000100	Pass	○	○	○	○	○
1000200	Fail	○	○	○	○	○
1000300	Fail	○	○	○	○	○
1000400	Pass	○	○	○	○	○
1000500	Fail	○	○	○	○	○
1000600	Fail	○	○	○	○	○
1000700	Pass	○	○	○	○	○
1000800	Fail	○	○	○	○	○
1000900	Fail	○	○	○	○	○
1001000	Fail	○	○	○	○	○
1001100	Fail	○	○	○	○	○
1001200	Pass	○	○	○	○	○
1001300	Fail	○	x	○	○	○
1001400	Fail	○	x	○	○	○
1001500	Pass	○	○	○	○	○
1001600	Pass	○	○	x	○	○
1001700	Pass	○	○	x	○	○
1001800	Pass	○	○	x	○	○
1001900	Fail	○	○	○	○	○
1002000	Fail	○	x	x	○	○
1002100	Fail	○	○	○	○	○
1002200	Fail	○	x	○	○	○
1002300	Fail	○	x	○	○	○
1002400	Pass	○	○	○	○	○
1002500	Fail	○	x	○	○	○
1002600	Pass	○	○	○	○	○
1002700	Pass	○	○	○	○	○
1002800	Fail	○	x	○	○	○
1002900	Fail	○	x	○	○	○
1003000	Pass	○	○	○	○	○
1003100	Fail	x	x	x	○	○
1003200	Fail	x	x	x	○	○
1003300	Pass	○	○	○	○	○
1003400	Pass	○	○	○	○	○
1003401	Pass	○	○	○	○	○
1003402	Pass	○	○	○	○	○
1003403	Pass	○	○	○	○	○
1003404	Fail	○	x	x	○	○
1003405	Pass	○	○	○	○	○
1003500	Pass	○	○	○	○	○
1003501	Fail	○	x	x	○	○
1003600	Pass	○	○	○	○	○
1003601	Fail	○	x	x	○	○
1003700	Pass	○	○	○	○	○
1003701	Fail	○	x	x	○	○
1003800	Pass	○	○	○	○	○
1003801	Fail	○	x	x	○	○
1003900	Pass	○	○	○	○	○
1003901	Pass	○	○	○	○	○
1003902	Pass	○	○	○	○	○
1003903	Pass	○	○	○	○	○
1003904	Fail	○	x	x	○	○
1003905	Pass	○	○	○	○	○
1004000	Pass	○	○	○	○	○
1004001	Fail	○	x	x	○	○
1004100	Pass	○	○	○	○	○
1004101	Fail	○	x		○	○
1004200	Pass	○	○	○	○	○
1004201	Fail	○	x	x	○	○
1004300	Pass	○	○	○	○	○
1004301	Fail	○	x	x	○	○
1004400	Pass	○	○	○	○	○
1004401	Fail	○	x	x	○	○
1004500	Fail	x	x	x	○	○
1004501	Fail	○	x	x	○	○
1004600	Pass	○	○	○	○	○
1004601	Pass	○	○	○	○	○
1004602	Pass	○	○	○	○	○
1004603	Pass	○	○	○	○	○
1004604	Fail	○	x	○	○	○
1004605	Fail	○	x	○	○	○
1004700	Fail	○	x	○	○	○
1004701	Fail	○	x	○	○	○
1004800	Pass	○	○	○	○	○
1004801	Pass	○	○	○	○	○
1004802	Pass	○	○	○	○	○
1004803	Pass	○	○	○	○	○
1004804	Pass	○	○	○	○	○
1004805	Fail	○	x	x	○	○
1004900	Pass	○	○	○	○	○
1004901	Pass	○	○	○	○	○
1004902	Pass	○	○	○	○	○
1004903	Fail	○	x	x	○	○
1004904	Pass	○	○	○	○	○
1004905	Pass	○	○	○	○	○
1005000	Pass	○	○	○	○	○
1005001	Pass	x	○	○	○	○
1005002	Pass	○	○	○	○	○
1005003	Pass	x	○	○	○	○
1005004	Pass	○	○	○	○	○
1005005	Pass	x	○	○	○	○
1005100	Pass	○	○	○	○	○
1005101	Fail	○	x	x	○	○
1005200	Pass	○	○	○	○	○
1005201	Fail	○	x	x	○	○
1005202	Pass	○	○	○	○	○
1005203	Fail	○	x	x	○	○
1005204	Pass	○	○	○	○	○
1005205	Pass	○	○	○	○	○
1005300	Pass	○	○	○	○	○
1005301	Pass	○	○	○	○	○
1005302	Pass	○	○	○	○	○
1005303	Pass	○	○	○	○	○
1005304	Pass	○	○	○	○	○
1005305	Fail	○	x	x	○	○
1005306	Pass	○	○	○	○	○
1005307	Pass	○	○	○	○	○
1005400	Fail	○	x	○	○	○
1005500	Fail	○	x	○	○	○
1005600	Pass	○	○	○	○	○
1005700	Pass	○	○	○	○	○
1005800	Fail	○	x	○	○	○
1005900	Fail	○	x	○	○	○
1006000	Fail	○	x	○	○	○
1006100	Fail	○	x	○	○	○
1006200	Pass	○	○	○	○	○
1006300	Pass	○	○	○	○	○
1006400	Fail	○	○	○	○	○
1006500	Fail	○	○	○	○	○
1006600	Fail	○	○	○	○	○
1006700	Pass	○	○	○	○	○
1006800	Fail	○	x	x	○	○
1006900	Fail	○	○	○	○	○
1007000	Fail	○	x	x	○	○
1007100	Fail	○	○	○	○	○
1007200	Fail	○	○	○	○	○
1007300	Fail	○	○	○	○	○
1007400	Pass	○	○	○	○	○
1007500	Fail	○	○	○	○	○	Delta CRL does not exist
1007600	Fail	○	○	○	○	○

(2) Observations related to independent path construction and verification routine as a CAPI revocation provider (CAPI sample column)

(a) Relationship with crlSign

For the library used in this implementation, when the signing key of the original issuer of the certificate subject to verification is the same signing key used to sign the CRL, the original issuer certificate is still valid even when crlSign is not attached to the keyUsage. This applies to the following two items (tc1003100, tc1003200).

(b) Relationship with requiredExplictPolicy

If the init-explicit-policy for the policy verification initial parameters is FALSE, the policy will not be requested, and therefore the certificate located in the path will be valid, regardless of the content of requiredExplictPolicy. Applies to tc1004500.

(c) Relationship with anyPolicy

If the init-explicit-policy is TRUE for the policy verification initial parameters, the verification process will produce an exception, and the certificate located in the path will be invalid if anyPolicy is attached to the certificate. Applies to the following three items (tc1005001, tc1005003, tc1005005).

(3) Implementations using CryptoAPI "certificate verification functions"

In relation to path construction under the current implementation, there is no function to dynamically extract certificates within a network-based repository, so this implementation does not perform the GPKI simulation test case or original test case which assumes that the intermediate CA certificate is extracted from a repository on a network. The following are test result observations for the NIST test case.

(a) Windows 2000 (Win2000 column)

Under Windows 2000, a path performing cross-certification cannot be constructed. Therefore, tests assuming cross-certification did not produce the expected value under the NIST category. In addition, policy-related processing was not performed properly.

(b) Windows XP (WinXP column)

Under Windows XP, a path performing cross-certification can be constructed. Therefore, one sees more items conforming to expected values when compared with Windows 2000 verification result values. However, even under Windows XP, the policy verification initial parameters cannot be set, so there are still some differences from expected verification result values.

7.4.3 Original Test Case Results and Observations

(1) Sample program test results

The following shows the original test results for the CryptoAPI sample program, the Java sample program and JDK 1.4.

Test Case	Expected Value	CAPI sample	Java sample	Sun JDK 1.4	Java Sample Implementation Notes
3000101	Pass	○	○	○
3000102	Pass	*1	○	×	Can not process KEY-UPDATE
3000103	Pass	○	○	×	Can not process KEY-UPDATE
3000104	Pass	○	○	○
3000201	Pass	○	○	○
3000202	Pass	○	○	○
3000203	Pass	×	○	○	*2
3000204	Pass	×	○	○	*2
3000301	Pass	○	○	○
3000302	Pass	*1	○	×	UNKNOWN
3000303	Pass	○	○	×	UNKNOWN
3000304	Pass	○	○	○
3000401	Pass	○	○	○
3000402	Pass	○	○	○
3000501	Fail	○	○	○
3000502	Fail	×	×	○
3000503	Fail	×	×	○
3000601	Pass	○	○	○
3000602	Fail	○	○	○
3000701	Pass	○	○	○
3000702	Fail	○	○	○
3000801	Fail	○	○	○
3000901	Fail	x	○	○
3001001	Fail	○	○	○
3001101	Fail	○	○	○
3001201	Fail	*1	×	○
3001202	Pass	*1	○	×	UNKNOWN
3001301	Fail	*1	×	○
3001302	Pass	*1	○	×	UNKNOWN
3001401	Pass	*1	○	×	UNKNOWN
3001402	Pass	*1	○	×	UNKNOWN
3001501	Pass	○	○	○
3001502	Pass	○	○	○
3001503	Pass	○	○	○
3001504	Pass	○	○	○
3001601	Pass	○	○	○
3001602	Pass	○	○	○
3001701	Fail	*1	○	○	1st CA certificate has a certificate policy "0.2.392.200117.1.9.2002.3.103999.1.10" and policyConstraints.required=0. 2nd CA is name rollover certificate. Certificate has no policy extension. So it is failed to build a policy tree(For GPKI) .Can not verify CRL signature, Because NOT care KEYUPDATE schema(For JDK)
3001702	Fail	*1	×	○	1st CA certificate has a certificate policy "0.2.392.200117.1.9.2002.3.103999.1.10" and no policy-constraints extension. Look like permitted to failing that ca not build policy tree.(For GPKI) Can not verify CRL signature, Because NOT care KEYUPDATE schema(For JDK)
3001703	Pass	*1	○	×	1st CA certificate has a certificate policy "0.2.392.200117.1.9.2002.3.103999.1.10" and policyConstraints.required=2. 2nd CA is name rollover certificate. Certificate has no policy extension. So it is failed to build a policy tree.(For GPKI) Can not verify CRL signature, Because NOT care KEYUPDATE schema(For JDK)
3001801	Fail	*1	○	○
3001802	Fail	*1	○	○
3001803	Pass	*1	○	×	UNKNOWN
3001901	Fail	○	○	○
3001902	Fail	○	○	○

*1 Undetermined due to inability to construct a path for the CRL issued by a key updated CA.

*2 Directory String matching & name rollover issues.

(2) Problems with printable-UTF8 Name Rollover

Test cases 3000203 and 3000204 were tests to determine whether NameRollover was possible for UTF8 and PrintableString. In every sample implementation, verification was successful, producing expected values.

Under RFC3280, different encoding is handled as different text strings, and binary comparison is also recognized in the description in addition to PrintableString. On the other hand, rules conforming to X.500 series are also recognized and allowed.

Under X.520, if text-string comparison is possible, comparisons based on conforming rules similar to PrintableString are allowed, even if encoding is different. In other words, multiple implementations are allowed within RFC3280. In the present test case, the superceding X.520 specification is the one adhered to, using expected values based on the RFC3280-successor conforming rules, including those related to visual impact.

Because of this, a DN given the same character text string with different encoding can be viewed as the same, similar to NameRollover under the present test case. However, as far as the RFC3280 predecessor (binary comparison) is adhered to, these will be viewed as different character text strings, which requires caution on the part of the developer, as well as feedback to the IETF/PKIX WG.

(3) Observations related to independent path construction and verification route as a CAPI revocation provider

In cases such as the following, path verification for a CRL issued by a CA having undergone a key update cannot be completed:

When the trust point CA has undergone a key update, and when a certificate of a signing key different from the key that signed the CRL is passed as a trust point and the parameter is given.

When a key update has been performed on an intermediate CA, and when a key different from the key for the certificate issued by the superceding CA is used to sign the CRL.

8 8 GPKI Test Case

In this section, we will discuss the GPKI test case prepared as a sample for use with the aforementioned interoperability test suite.

The GPKI test case is divided into the following three test categories, based on the major test criteria explained in Section 4.

- GPKI simulation test case

- NIST test case

- Original test case

8.1 GPKI Simulation Test Case

Under the GPKI simulation test case, the following certification path construction and path verification are the requirements for electronic applications from the private sector (B2G), official documents issued from government agencies (G2B), and inter-agency communications (G2G), which are within the framework provided by GPKI.

Figure 8‑1 G2B Verification Path

Figure 8‑2 B2G Verification Path

Figure 8‑3 G2G Verification Path

Under the present test case, the status of the signer's certificate is verified in the following cases for each of these certification paths.

- Valid signer's certificate

- Revoked signer's certificate

- Expired signer's certificate

Simulated data is used for each of the following certificate authorities (already running under GPKI) under each of these certification paths.

- Government certificate authorities

Ø Ministry of Economy, Trade and Industry certificate authority (and subordinate certificate authorities)

Ø Ministry of Land, Infrastructure and Transport certificate authority

Ø Ministry of Public Management, Home Affairs, Posts and Telecommunications certificate authority

- Bridge certificate authorities

Ø GPKI bridge certificate authority

- Private certificate authorities

Ø Japan Certification Services, Inc.'s A-Sign2 certificate authority

Ø SECOM Trust.net Co., Ltd.'s SECOM Passport for G-ID certificate authority

Ø Commercial registration certificate authority

Under the GPKI simulation test case, the above three types of certification paths, and three types of signer's certificate status

The above data (three types of certification paths, three types of signer's certificate status, seven certificate authorities,

8.2 NIST Test Case

The NIST test case re-performs the test case used during the U.S. NIST's DoD BCA interoperability testing ("X.509 Path Validation Test Suite, Version 1.07").

The NIST test case broadly classifies certificate verification and revocation status.

The testing level is set for each test case, defined as follows:

Level 0: Testing not necessary.

Level 1: Minimum level of testing for interoperability

Level 2: Testing at higher guarantee levels. Should perform verification as long as budget allows.

Level 3: Debug testing. Test as necessary when the testing up to Level 2 results in failure.

Each test case is designed with its own unique point of view, but in reality several of the tests are redundant. For these test cases, only the requirements for each category are defined, and for the actual test case, only one certain category is defined.

8.2.1 Certificate Verification

(1) Certificate processing tests (CP)

Defines testing for test cases confirming the basic verification details for each certificate required for X.509 and RFC3280.

² Certificate signature verification (CP.01)

² Certificate expiration verification (CP.02, CP.03)

² Certificate DN comparison (CP.04)

² Certificate revocation verification (CP.05, CP.06)

(2) Intermediate certificate processing tests (IC)

Test cases providing a higher level of confirmation for intermediate certificates:

² cA flag verification (IC.01, IC.02)

² Path length constraint verification (IC.03 → defined at PL.01)

² keyUsage (keyCertSign) verification (IC.04, IC.05)

² keyUsage (cRLSign) verification (IC.06)

(3) Policy processing tests (PP)

Test case definitions following the two types of constraint methods, the X.509 authority-constrained-policy-set and the user-constrained-policy-set. Testing requirements are also defined for test results display methods.

² authority-constrained-policy-set verification (PP.01)

² user-constrained-policy-set verification (PP.08)

² Policy modifier verification (PP.02: undefined)

² Verification when policy mapping is not prohibited (PP.03: undefined)

² Verification when policy mapping is prohibited (PP.04: undefined)

² requireExplicitPolicy verification (PP.06)

² Verification related to application verification results display (PP.05, PP.07, PP.09→defined at PP.06, PP.10)

(4) Path length testing (PL)

Ø Path length verification (PL.01)

8.2.2 Revocation Status Verification

(1) fullCRL-related tests

Definitions for CRL standard verifications for CRL-based verification, and for when issuingDistributionPoint and deltaCRL are used during verification.

Ø CRL-based revocation verification (RL.01)

Ø CRL signature verification (RL.02)

Ø CRL and certificate issuer comparison (RL.03)

Ø Verification when CRL indicates revocation (RL.04)

Ø Unknown critical crlEntryExtension handling (RL.05)

Ø Unknown critical crlExtension handling (RL.06)

Ø nextUpdate verification (RL.07)

Ø deltaCRL verification (RL.08)

Ø issuingDP verification (RL.09)

8.3 Original Test Cases

Included in the results of the "Challenge PKI 2001", a project testing interconnectivity in connection with the "PKI-Related Interoperability Investigation", were problems related to certification path verification within applications.

In this section, we will introduce the original test cases addressing problems such as these that have not been included in "GPKI simulation test case" and "NIST path verification and equivalent test cases", above.

8.3.1 CA Key Updates

When a CA with a self-signed certificate undergoes a key update, a self-issued certificate must also be issued in order to relate the new key with the old key. This testing verifies whether certification path construction and path verification can be conducted correctly with these self-issued certificates.

- Cases using OldWithOld

- Cases using NewWithOld

- Cases using OldWithNew

- Cases using NewWithNew

8.3.2. Mixing PrintableString and UTF8String

Under X.509, a variety of encoding methods are currently allowed for a certificate DN, including PrintableString. However, for certificates issued after December 31, 2003, some specifications will require UTF8String encoding.

In this testing, under the circumstances (which are expected before and after December 31, 2003) where certificates encoded under PrintableString and certificates encoded under UTF8String are likely to coexist, we tested whether an EE could perform appropriate certification path construction and verification, as well as correctly verify signature data.

- Cases where PrintableString CA and UTF8String CA perform cross-certification

- Cases where the PrintableString CA performs a key update to a UTF8String

8.3.3 Mixing UTCTime and GeneralizedTime

Under X.509, both UTCTime and GeneralizedTime (two types of encoding methods) are allowed currently for a certificate's effective dates. However, when issuing certificates which are valid after 2050, GeneralizedTime must be used as the encoding method.

In this testing, under the expected circumstances where certificates encoded under UTCTime for effective date and certificates encoded under GeneralizedTime for effective date are likely to coexist, we tested whether an EE could perform appropriate certification path construction and verification, as well as correctly verify signature data.

- Cases where UTCTime CA-X and GeneralizedTime CA-Y perform cross-certification

8.3.4 Mixing OCSP and CRL

Under PKI the two basic methods of providing revocation information are by releasing a revocation list from a repository and by providing certificate revocation information individually through an OCSP responder. Under GPKI, a government certificate authority releases a CRL/ARL from an integrated repository. On the other hand, a commercial registration certificate authority provides revocation information on an individual basis through an OCSP responder.

Accordingly, during the testing referenced herein, procedures were conducted to confirm whether an EE performed appropriate certification path construction and verification, and correctly verified signature data in a GPKI environment consisting of both OCSP models and CRL models.

- Cases in which a commercial registration OCSP responder exists in the certification path

- Cases in which a general OCSP responder exists in the certification path

- Cases in which an OCSP response cannot be verified

8.3.5 Policy Constraints

Under GPKI, when each government/ private certificate authority performs cross-certification with a bridge certificate authority, each certificate authority determines a certificate policy showing use of GPKI, maintaining an appropriate security level through mapping these policies.

In this testing, testing was conducted to confirm whether an EE could perform certification path construction (including certificate policy and policy mapping) and verification, and whether it could correctly verify signature data.

- Cases in which a requested certificate policy is contained in a certification path

- Cases in which a requested certificate policy is not contained in a certification path

- Cases in which a certificate policy in a certification path is correctly mapped

- Cases in which a certificate policy in a certification path is not correctly mapped

8.3.6 Various Constraints

To maintain a security level between each certificate authority owned by different operational entities, GPKI requires the verification of the certification path used by the certificate policy produced by policy constraints. In addition, to prevent B2B through bridge certificate authorities, a name constraint must be included in the cross-certification certificate issued by the private certificate authority to the bridge certificate authority.

Although not necessarily required by GPKI, path length constraints are defined under X.509 to limit the length of a certification path.

Testing conducted here confirmed whether an EE could perform certification path construction and verification for paths including these constraints, and whether it could correctly verify signature data.

- Cases in which certification path length was constrained

- Cases in which a certificate policy in a certification path was constrained

- Cases in which policy mapping in a certification path was constrained

- Cases in which a name space in a certification path was constrained

8.3.7 Test Cases related to DN Encoding

After December 31, 2003, DN encoding will be in UTF8. Because of this, there may be instances in which verification processes related to certification path verification may not work properly. The test cases performed verification testing in connection with the following two general areas:

(1) Evaluation of various constraints

With the change in DN encoding, there is a possibility that a self-signed certificate will not be correctly recognized as such. There are several cases where processing changes during certification path verification depending on whether it is recognized as a self-signed certificate or not.

- BasicConstraints

- NameConstraints

- PolicyConstraints

(2) Revocation information acquisition and verification

Normally, revocation information is searched by signer name (DN) and serial number. If the DN encoding is changed, there is a possibility that a signer name won't match any more.

Testing conducted here confirmed whether an EE could construct and verify a certification path including revocation information acquisition and verification, and whether it could correctly verify signature data.

- CRL and certificate

- OCSP response and certificate

9 9 Conclusion

One major theme for Challenge PKI 2002 was to solve problems of interoperability from the perspective of the relying party (verifier) in PKI/GPKI.

Although there are certainly many other problems related to interoperability, looking from the standpoint of standard PKI technology, the interoperability from the perspective of the relying party (verifier), in other words interoperability related to certification path verification, is the most difficult. This is an indispensable function from the perspective of the relying party (verifier), and necessary for implementation of digital government applications.

Certification path verification has been implemented for current PKI applications in a format conforming to a subset of X.509 and RFC3280 standards. However, as a subset, such implementation may not work in all situations.

Certification path verification is difficult when working with a wide PKI domain such as digital government, and especially so for performing certification based on the purpose of the certificate.

Digital government in every country demands the ability to perform certification over a scope heretofore unparalleled. New demands will require more from the current standards, or the use of heretofore unused capabilities. Accordingly, implementations conforming to standards do not mean simplistic implementations.

Meanwhile, there are problems with standardization itself. The IETF maintains that under RFC3365 (security requirements for IETF standard protocols), IETF standard protocols must use an appropriately strong security mechanism. Most Internet protocols thrived due to their simplicity, but for security issues, "simple" will no longer be accepted. In the midst of these circumstances, simply repeating prototype development using simple standards and simple implementations makes it ultimately more difficult to engage in new protocol development.

Given the circumstances above, one of the major themes for the Challenge PKI 2002 was to start the process of finding clues to solving PKI/GPKI interoperability problems in the future. Because of this, we now see more basic work related to what is needed to achieve interoperability, rather than the many tests performed related to interoperability between already marketed products. And new goals include creating appropriate testing environments and test criteria, building sample implementations, and producing written reports, such as this one, covering subjects from standards to implementations.

Test cases were designed for two actual sample implementations that were implemented on the framework of the interoperability test suite. After running the implementations, we feel that in order to draft complex standards such as RFC3280, there is first a need to establish a system to verify the standards themselves.

For example, should not test cases be designed at the same time that standards are being drafted? Should not test cases be shared broadly among those who could provide intelligent feedback? Integrating these steps would provide feedback related to vagueness in standards, and make it easier to identify and reduce a lack of clarity in standards during the drafting stage.

Further, at the stage when standards are ready to be implemented, potential implementers who design test cases are faced with a great burden, and the inundation of unique test cases can work to reduce adequate coverage of standards testing. If test cases were shared across organizations, development would surely move forward more rapidly.

These ideas should also be proposed to standardization groups such as the IETF. Joint development and sharing of test cases across the world would be a great help in solving world-level interoperability issues.

The same things can be said in relation to drafting of specifications for Japanese digital government. When looking to draft interoperability specifications allowing GPKI, LGPKI, Japanese PKI, and cross-certification overseas, the same fundamental approach is required as that for developing RFC3280 and other standards. After completing initial designs, it may be very important to use the interoperability test suite to perform simulations.

In order to create a successful digital government, it is vital to not only develop and formalize domestic standards, but also actively participate in the drafting of global standards as well.

If the Challenge PKI 2002 Project is able to aid in the promotion of PKI/GPKI application development domestically, and in the promotion of standards on a global level, then it will have fulfilled a large measure of its purpose.

10 10 Appendix

10.1 X.509 4^th Edition Certificate Profile

The Certificate Profile is discussed in Chapters Seven and Eight of the "X.509 4^th Edition" (X509.4). This has been compiled in tables below. (Table 10-1 and Table 10-2)

10.1.1 Primary Partitions

Table 10‑1 Certificate Primary Partitions Provided in X.509 4^th

Item		Explanation
Version		X.509 certificate version. V3 if extended partition exists.
serialNumber		Assigned by CA issuing certificate; unique number for each certificate.
signature		Algorithm Identifier for algorithm used when CA signs certificate.
Validity		Expiration date of this certificate.
	notBefore	Certificate becomes valid after this date.
	notAfter	Certificate expires after this date.
Issuer		Identifier of the CA issuing/ signing this certificate.
Subject		Identifier of subject related to the public key for this public key field.
subjectPublicKeyInfo		Public key value and algorithm name.
issuerUniqueID		Identifier used to uniquely identify issuer when issuer name is re-used.
subjectUniqueID		Identifier used to uniquely identify subject when subject name is re-used.

10.1.2 Extended Partitions

Table 10‑2 Certificate Extended Partitions Provided in X.509 4^th

Item							Explanation	Critical Flag
authorityKeyIdentifier							Identifier showing the public key used in certificate verification for this certificate.	Non-critical
	keyIdentifier						Private key identifier.	-
	authorityCertIssuer						Name of authority issuing certificate.	-
	authorityCertSerialNumber						Serial number for authority certificate.	-
subjectKeyIdentifier							Identifier for subject's key.	Non-critical
keyUsage							Purpose for usage of key.	Either
		digitalSignature					Digital signature verification.	-
		nonRepudiation					Verification of digital signature used to prevent repudiation.	-
		keyEncipherment					Encryption of private information for private key, etc.	-
		dataEncipherment					Encryption for user data other than key, private information.	-
		keyAgreement					Public key for shared key usage.	-
		keyCertSign					Verification of CA signature on the certificate.	-
		cRLSign					Verification of authority signature on CRL.	-
		encipherOnly					When keyAgreement bit is set, only encrypted data for shared public key is used.	-
		decipherOnly					When keyAgreement bit is set, only decrypted data for shared public key is used.	-
extKeyUsage							Purpose for public key usage. Added to or replaces data to prevent contradictions in keyUsage field.	Either
privateKeyUsagePeriod							Usage limitation for private key corresponding to public key included in certificate. Applies only to signing key. Not recommended according to "RFC3280" Section 4.2.1.2.	Non-critical
			notBefore				Key is valid after this date.	-
			notAfter				Key is expired after this date.	-
certificatePolicies							Certificate policy is set based on certificate purpose approved by issuer.	Either
			PolicyInformation				Consists of policy identifier and policy modifier. When "critical", usage according to rules is mandatory.	"anyPolicy" added with 4^th Edition
						CertPolicyId	Policy identifier.	-
						PolicyQualifierInfo	Policy modifier	-
						SupportedPolicyQualifiers	Acceptance policy limiter.	-
						anyPolicy	Set when all policies are accepted.	Added with 4^th Edition.
policyMappings							Defines when two values set in field for the issuerDomainPolicy and subjectDomainPolicy pair are equivalent.	Either
				issuerDomainPolicy			Policy for certificate issuer.	-
				subjectDomainPolicy			Policy for subject.	-
subjectAltName							Multiple name format to identifiy certificate owner, separate from "subject" in primary partition.	Either
				otherName			Format name defined by OTHER-NAME information object class.	-
				rfc822Name			Internet electronic mail address defined by RFC822.	-
				dNSName			Internet domain name defined by RFC1035.	-
				x400Address			O/R address defined by ITU-T Tec.X.411\|ISO/IEC 10021-4	-
				directoryName			Directory name defined by ITU-T Tec.X.501\|ISO/IEC9495-2	-
				ediPartyName			Name of format agreed to between EDI partners.	-
				uniformResourceIdentifier			Unique resource identifier defined by RFC1630.	-
				iPAddress			IP address defined by RFC791 and expressed as a binary number.	-
				registeredID			Identifier for registered object, assigned according to CCITT Rec.X.660 \| ISO/IEC 9834-1.	-
issuerAltName							Sets issuer name separately, or in an additional format, from the issuer in the primary partition.	Either
subjectDirectoryAttributes							Stores directory attributes necessary for certificate owner. RFC2459 section 4.2.1.9 recommends against using this; however, such recommendation is not included in "RFC3280" section 4.2.1.9.	Non-critical
basicConstraints							Certificate owner sets to determine whether CA is CA holding public key used for certificate signature verification.	Either
					cA		Indicates whether certificate signature verification is used by public key for this certificate.	-
					pathLenConstraint		If cA is set to "True", sets the maximum value for the CA certification path (related to this path) performing cross-certification with this certificate.	-
nameConstraints							An extension used only by the CA certificate, limits the name of the certificate issued by the issuer.	Either
					permittedSubtrees		Permitted sub tree	-
					excludedSubtrees		Excluded sub tree	-
policyConstraints							Used with CA certificate; limits relationship of policies within the certification path.	Either
					requireExplicitPolicy		Identifier for acceptable policies.	-
					inhibitPolicyMapping		Prohibits policy mapping.	Added to 4^th Edition
inhibitAnyPolicy							Prohibits use of any-policy, acting as policy identifier.	Either
cRLDistributionPoints							Designates distribution point of revocation list related to CA certificate, EE certificate, and attribute certificate.	Either
freshestCRL							Designates information for acquiring most recent revocation list related to CA certificate and EE certificate.	Either Added with 4^th Edition.

10.2 X.509 4^th Edition CRL Profile

The CRL profile is discussed in Chapter Eight of the "X.509 4th Edition" (X509.4). This has been compiled in tables below. (Table 10-3, Table 10-4, and Table 10-5)

10.2.1 Primary Partitions

Table 10‑3 CRL Primary Partitions Provided in X.509 4^th

Item			Explanation
Version			Revocation List version (v1 or v2)
Signature			Revocation List signature algorithm
Issuer			Revocation List issuer name
thisUpdate			Revocation List issue date
nextUpdate			Revocation List next issuance
revokedCertificate			List of revoked certificates
	userCertificate		Serial number of revoked certificates
		revocationDate	Time/ date of CA revocation
		crlEntryExtensions	Additional information related to revoked certificate

10.2.2 Entry Extended Partitions

Table 10‑4 CRL Entry Extended Partitions Provided in X.509 4^th

Item			Explanation	Critical Flag
reasonCode		Revocation reason	Designates reason certificate was revoked.	Non-critical
	Unspecified	Undefined	Reason for revocation not defined. * In this case, reasonCode should be omitted.
	keyCompromise	Key not secure	Problems with EE's private key trustworthiness.
	cACompromise	CA not secure	Problems with CA's private key trustworthiness.
	affiliationChanged	Content change	Key content changed for reasons other than key trustworthiness being compromised.
	Superseded	Change	Certificate has been replaced for reasons other than key trustworthiness being compromised.
	cessationOfOperation	Operationsstopped	Certificate is no longer needed for use under original purpose (unrelated to doubts as to key trustworthiness compromise).
	certificateHold	Certificate is held over	Indicates that certificate is being held.
	removeFromCRL	Restoration	Only used with differential revocation list. Certificate revocation information has been removed from revocation list.
	priviledgeWithdrawn	Privileges are withdrawn	Privileges contained in certificate have been withdrawn; therefore, certificate has been revoked.
	aACompromise	Attributes compromised	Information within attribute certificate has been compromised.
holdInstractionCode		Hold instruction code	Designates action for certificate with a hold in reasonCode (certificateHold)	Non-critical
invalidityDate		Invalid date	Day certificate actually becomes invalid (or possible invalid date).	Non-critical
certificateIssuer		Name of certificate issuer in revocation list	Only used when revocation list issuer and certificate issuer are different.	Critical

10.2.3 Extended Partitions

Table 10‑5 CRL Extended Partitions Provided in X.509 4^th

Item	Explanation	Critical Flag
authorityKeyIdentifier	Identifier showing public key used for signature verification for this certificate.	Non-critical
issuerAltName	Set issuer, separate, or in addition to, issuer in primary partition.	Either
cRLNumber	Sequence number assigned by CRL issuer.	Non-critical
crlScope	Information related to scope of certificate management by CRL.	Critical Added with 4^th Edition.
statusReferrals	Guarantees appropriate revocation information is used.	Critical Added with 4^th Edition.
cRLStreamIdentifier	Distinguishes ordered relationship between unique CRL numbers.	Non-critical Added with 4^th Edition.
orderedList	Sorted by revoked certificate serial number.	Non-critical Added with 4^th Edition.
deltaInfo	Shows availability for use with this CRL delta revocation list.	Critical Added with 4^th Edition.
issuingDistributionPoint	Distribution point for this CRL.	Critical
deltaCRLIndicator	Shows the base revocation list being referenced is a delta revocation list.	Critical
baseUpdateTime	Time/ date delta revocation information provided.	Non-critical Added with 4^th Edition.

10.3 RFC3280 Certificate Profile

We will address only the differences between the certificate profile discussed in Chapter Seven and Eight of the "X.509 4th Edition" (X509.4) and the certificate profile discussed in Chapter Four of the RFC3280.

Only the following two extensions are different from those in the "X.509 4^th Edition".

Table 10‑6 Differences Between X.509 4^th and RFC3280 Extended Partitions

Item	Explanation	Critical Flag
AuthorityInformationAccess	CA information and service access method for certificate issuer included in this extension.	Non-critical
SubjectInformationAccess	Information and service access method for certificate subject included in this extension.	Non-critical

10-4 RFC3280 CRL Profile

We will cover only the differences between the CRL/ARL profile discussed in Chapter Eight of the "X.509 4^th Edition" (X509.4) and the CRL profile discussed in Chapter Five of the RFC3280.

The following extensions are only contained in the "X.509 4th Edition", and not found in the RFC 3280.

※RFC3280 was created in parallel with the "X.509 4^thEdition" draft, and therefore does not reflect all of the extensions contained in the completed "X.509 4^thEdition".

Table 10‑7 Differences Between X.509 4^th and RFC3280 CRLs

Item	Explanation	Critical Flag
crlScope	Information related to scope of certificate managed by CRL.	Critical
statusReferrals	Status referral.	Critical
cRLStreamIdentifier	The CRL stream identifier field is used to identify the context within which the CRL number is unique.	Non-critical
orderedList	Certificate order sorted by serial number.	Non-critical
deltaInfo	Delta revocation list acquisition information.	Critical
baseUpdateTime	Time/ date delta revocation information provided.	Non-critical

10.5 Compilation of CRL types found in the "X.509 4^th Edition"

From the perspective of the certificate user, CRLs can be classified into the following seven categories, partially shown in Table 10-8. Figure 10-1 includes a brief description of differences in information contained by Full and complete CRL, Full and complete EPRL, Full and complete CARL, Delta CRL, EPRL, and CARL.

Table 10‑8 CRL Categories

Name	Explanation
Full and complete CRL	List of all revoked end entities and CA certificates issued by certificate authority.
Full and complete EPRL	List of revoked end entities and certificates issued by certificate authority. ※EPRL is also called "end entity CRL".
Full and complete CARL	List of revoked CA certificates issued by certificate authority. ※CARL is acronym for Certification Authority Revocation List.
Distribution Point CRL、 EPRL、CARL	Encompasses portion or all of certificate issued by certificate authority.
Indirect CRL、 EPRL、 CARL	CRL included in list of revoked certificates. However, list may include certificates not issued by certificate authority that signed and issued the CRL.
Delta CRL、 EPRL、 CARL	CRL including only differences (delta CRL). By referencing the CRL indicated in this delta CRL, the given scope is completed for the first time. The delta CRL forms the entire image of the certificate revocation status, so it is used together with a combined CRL (complete CRL having same scope).
Indirect dCRL、 EPRL、 CARL	CRL including at least one CRL change. However, list may include certificate not issued by certificate authority that signed and issued the CRL. Indirect dCRL, EPRL and CARL are complete with respect to the given scope. ※dCRL is an abbreviation for Delta CRL

Figure 10‑1 CRL Categories

The certificate user retrieves these CRLs from the location shown by the CRL DP (CRL distribution point) and certificate issuer's directory entry. These entries can be read with certain attributes, including the following:

· Certificate Revocation List;

· Authority Revocation List;

· Delta Revocation List;

If the certificate user determines the certificate parameters to judge what CRL is required, and if an appropriate CRL is acquired, the certificate user can then conduct CRL processing and revocation verification.