JPH10322326A - Public key certificate management method and its recording medium - Google Patents

Abstract

PROBLEM TO BE SOLVED: To attain adequate processing without duplicate registration. SOLUTION: Tree structure management is applied to a name (DN) written in applications where high-degree layers are adopted for a wide address area and a lowest layer is adopted for a general name, and the method is provided with a management table 15 for each layer other than the lowest layer and the layers higher by one ranking than the lowest layer where an entry name and each table name are registered, and each leaf higher by ranking from the lowest layer is provided with a certificate table 21 whose entry is the general name to register its certificate. A DN in an application is divided into each layer to check in which part of the table 15 each layer is in existence. When the checking is successful and the type of the application is 'generation', a public key certificate is generated when the general name in matching with the lowermost part of the DN is not in existence in the table 21, and the general name and the certificate name are registered in the table 21. When the type is 'addition' and the general name in matching with the lowermost part of the DN is in existence in the table 21, the certificate registered already is used to authenticate the signature of the application. When the checking is successful, the certificate is newly generated and the certificate is additionally registered. When the type is 'delete' and the general name in matching with the lowermost part of the DN is in existence in the table 21, the certificate registered already is used to authenticate the signature of the application and when the checking is successful, the corresponding general name and certificate are deleted.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an authentication system used for the purpose of confidentiality of transmitted data and prevention of tampering when realizing EDI (electronic data exchange) or EC (electronic commerce) on a computer network. (Certi
The present invention relates to a method for configuring a public authority (hereinafter referred to as CA), and more particularly to a management method in an organization that issues / manages a public key certificate based on a public key cryptosystem and a recording medium on which a program of the method is recorded.

[0002]

2. Description of the Related Art EDI on a computer network
When implementing (electronic data exchange) and EC (electronic commerce), threats such as eavesdropping / spoofing / falsification / transmission denial are assumed, and cryptographic communication and digital signature communication are used to protect against such threats. It is common. There is a public key cryptosystem as an effective method for performing the cryptographic communication and the digital signature communication. This method is described in the reference "Diffie, W. and Helman, M .: Ne.
w Direction in Cryptography
hy, IEEE Trans. Inf. Theory,
IT-22, 6pp. 644-654, 1976 "and is widely known in the world. This public key cryptosystem requires a third party to certify the owner of the key, which is a CA (Certif).
This is what is referred to as an “authorization authority”. CA has a function to issue a public key certificate to certify the owner of an encryption key in the world of digital communications, as well as to issue a seal certificate certifying the owner of a seal in the real world of Japan. It can be said that it is a system with.

[0003] The functions of CA generally known are as follows.・ Public key registration function: For the public key applied by the user,
Create / register / issue a public key certificate.・ Certificate reference function ... A public key certificate managed by CA can be referred to by the user.・ Public key revocation function: The public key certificate is revoked and posted on the revocation list. -Revocation list reference function: Enables a user to refer to a list of revoked public key certificates.

[0004] These functions can be constructed using general means provided by a computer system or a cryptographic algorithm.
Perform digital signature communication between CA and user,
It is recognized that the basic configuration method, such as managing a public key certificate and a revocation list in a directory or a database, is a general method. Well, CA
When constructing a directory, the concept of a directory (X.500, I
SO / IEC / DIS 9594-1) is widely used. Therefore, it is assumed that the public key certificate managed by the CA also adopts a format conforming thereto. The “name” described in the public key certificate is also X. It is widely used in the format specified in Recommendation 500. The “name” is not specified by one character string, but has a format in which several hierarchical (hereinafter referred to as “entry”) names are arranged, and the name is a so-called DN (Distinished Name).
Becomes These DNs are in the CA at X. Tree structure of recommendation 500, so-called DIT (Directory Information)
In general, the information is managed in a motion tree. Here, the DN and DIT will be described with an example. In FIG. 1, "Japan" is the top of the tree structure, and branches below it. This is called a DIT structure. Also, D
The IT is composed of hierarchies such as each entry, “Kanagawa”, “Yokohama”, etc., and the lowermost end is indicated by a general name of an individual. If “Suzuki” is denoted by DN in this DIT structure, C = Japan, L
= Kanagawa, ST = Yokohama, CN = Suzuki. Here, C is a country name, L is a local name, ST is a local name, and CN is a general name. However, this DIT has no definition of the structure, and at present there is only a standard for assigning attributes of entries such as C and L. In the concept of a normal directory, when there is a request for creating, adding, or deleting an entry, the processing is performed. It is necessary to provide a mechanism for confirming whether or not to perform processing for a DN that is not permitted. These X.
Building a system compliant with 500 can be considered as a general one as an application range of a computer system. However, since a technical mechanism is needed for an efficient realization method, various methods are being considered. The present invention also proposes one of the realization methods, and shows a management method that focuses on checking an unauthorized DN.

[0005] In a general CA, when a public key certificate is created, a user describes his / her own DN in an application form, and the CA that accepts this describes the public key based on the DN specified by the applicant. Create a certificate. Also, once a user who has registered a public key certificate requests a certificate for another public key, that is, when adding a public key to be registered, the Create. Further, in the deletion process, the public key certificate corresponding to the designated DN or the like is deleted. The key to performing these processes is DN
It is. In such a configuration, the D
Confirmation has been made regarding the N-entry assignment standard and the format such as delimited by = (equal).

[0006]

As described above, in a general CA, only the format of the DN is checked, and the contents and relations of each entry are not referred to, but the certificate is certified according to the DN specified by the user. In order to create a certificate, if an unauthorized DN or a DN due to a user's input error etc. is described in the application form and a registration application is made, the number of entries with various names will increase unnecessarily, There is a possibility that the number of public key certificates having a meaningless DN may increase. Therefore, DN entry names and attributes permitted by CA,
It is an object of the present invention to manage all the relationships and to check with less information and at the same time to easily manage public key certificates.

[0007]

SUMMARY OF THE INVENTION The present invention provides a D
All entry names from the lowest end of N up to one level higher are D
It is registered and managed in the IT management table, and is used as a confirmation target when an application is made. The lowest entry of the DN is managed in an individual public key certificate table separately from the management table, and stores the public key certificate for the common name using the common name (CN name) as a key. Otherwise, the DN management table for each level manages the entry name of that level and the designation of the lower level management table.

According to the management method of the present invention, the functions for performing the above-mentioned operations include a means for searching the DIT management table, a means for creating a public key certificate, a means for adding a public key certificate, and a means for deleting a public key certificate. Is configured by a process for invoking the function. As a prerequisite for executing this management method, the management table and the public key certificate table are created in advance by the DIT management table creation means and the entry name registration means.

From the creation of these tables, the execution of the method of the present invention is processed using these means, for example, as shown in FIG. (1) In the system initial generation process, a database table is generated using the DIT management table generation means for the entry names (layers) of the DNs to be permitted. (2) In the entry name registration process, the entry name of the middle hierarchy permitted by the CA is registered using the entry registration means. (3) In the DN check step, the DN information included in the application form information from the user is taken out, divided for each layer, and one layer higher than the lowermost layer from the lowermost layer using the search means for the DIT management table. It is checked whether the DNs up to are allowed. (4) In the service allocation step, according to the “process type” information included in the application form from the user, the service is allocated to a public key certificate creation step, a public key certificate addition step, or a public key certificate deletion step. . (5) In the public key certificate creation step, after confirming that the lowest end (generic name) of the applied DN does not exist in the corresponding public key certificate table, an entry (its common name) is entered in this table. Create Then, a public key certificate is created from the application form information, and the public key certificate is registered in a corresponding entry of the corresponding public key certificate management table. If the generic name has already been registered here, this application will be rejected. (6) In the public key certificate adding step, confirm that the lowest end (generic name) of the applied DN exists in the corresponding public key certificate table, and the public key certificate registered in the corresponding entry. By verifying the electronic signature given to the application using the certificate, it is confirmed that the user is the same as the user corresponding to the entry. Thereafter, a public key certificate is created from the application form information, and the created public key certificate is added to the common name of the corresponding DN in the corresponding public key certificate management table. (7) In the public key certificate deletion step, confirm that the lowest end (generic name) of the applied DN exists in the corresponding public key certificate table, and the public key certificate registered in the corresponding entry. By verifying the electronic signature given to the application using the certificate, it is confirmed that the user is the same as the user corresponding to the entry. After that, the corresponding public key certificate is deleted. In addition, when all the certificates possessed by the common name are deleted, the common name (entry) is also deleted.

In FIG. 2, for example, in the system initial generation step, there are various initialization steps other than the creation of the DIT management table. Means that. According to the method of the present invention, it is possible to check the validity of the DN information included in the application information from the user, and to manage the public key certificate without duplicating registration of the permitted entries at the same time. Can be built.

[0011]

Embodiments of the present invention will be described below. According to the present invention, the names (DN) in the application are managed in a tree structure, and a D is assigned to each hierarchy except for the lowest hierarchy of the tree structure.
An N management table is created, and a public key certificate table is created for each leaf one level higher from the lowest hierarchy. These specific examples are shown in FIG. FIG. 3 shows an example of the tree structure of the DN shown in FIG.

First, the uppermost "Japan" is fixed, and the DIT management table 15 with the table name "Japan.tbl" is referred to in order to search for an entry under Japan. Each DIT management table 15 has a column 14 for the table name, a column 16 for recording the entry name, a column 17 for recording the attribute, a column 18 for recording an attribute that can be located below the table, A column 19 is provided in which the lower attribute, that is, the name of the DN management table having the lower hierarchy as an entry, is recorded. Since "Tokyo" and "Kanagawa" are registered in the entry name column 16 in the management table of "Japan.tbl", only "Tokyo" and "Kanagawa" can be specified under "Japan". . The attribute of “Kanagawa” is “L”, and the entry (hierarchical) attribute that can be located under the attribute is “ST”. Similarly, the DN management table with the table name “Kanagawa.tbl”, that is, the entry name registered under “Kanagawa” is “Yokohama” and the attribute is “ST”.

A "public key certificate table" 21 provided separately from the DIT management table 15 manages the general name of the user and the public key certificate itself, which are the lowest hierarchy.
That is, individual public key certificate tables 21 exist under each region (tree structure leaf). Public key certificate table 2
1 includes a table name column 22, a column 23 for recording a common name to be entered, and a column 24 for recording data such as a public key certificate. Providing such a public key certificate table 21 indicates that the search range is narrowed when the number of registrants increases, and that registration is possible even if the region has a different name with the same name. Also, the reason why the management of the lowermost layer and the management of the other layers are divided is that the layers are divided into layers that can be added / deleted by the user and layers that cannot be added / deleted. Explaining with reference to the DIT of FIG. 1, the hierarchy in which the CA compares and confirms the DN described in the application with the DN management table 15 managed in the CA is as follows: C = Japan, L = Kanagawa, ST = Yokohama, C = Japan , L = Tokyo, ST = Minato-ku, etc., and the lowest common names such as “Suzuki” and “Takahashi” are managed by the corresponding public key certificate table 21. If the common name does not exist in the corresponding public key certificate table and it is a new registration of the public key certificate from the user, the entry is naturally stored in the “public key certificate table” 21. Add. Conversely, if the common name exists in the corresponding public key certificate table 21, rejection of acceptance of new registration of the public key certificate from the user and additional registration of the public key certificate by the same user Only this application is accepted and a public key certificate is additionally registered in the corresponding entry. As a result, it is possible to prevent duplication of DNs such as different users having the same DN. Here, as a method of confirming whether or not the user is the same user, the user is requested to add an electronic signature verifiable with a registered public key to an application form for additional registration. Is verified by using the public key certificate already registered in the corresponding entry of the public key certificate table 21 to confirm that the electronic signature has been normally completed. Confirm that it is an additional registration application by the same user as the user who has the entry of This makes use of the fact that only a registered user can give a verifiable digital signature using the registered public key. The confirmation as to whether the user is the same user is also performed in the process of deleting the public key certificate. This is the same D
This is to prevent a different user who claims to be N from deleting the public key certificate registered in the corresponding entry without permission.

As described above, the entry name at the bottom end can be added as an entry only when it does not exist in the corresponding public key certificate table 21.
With regard to entries in the hierarchy higher than the lowest end, by access control of the database, inquiries from the user are made “read only” and “writable” so that intermediate entries cannot be added without permission. .
Therefore, in the application form from the user, for example, in the situation shown in FIG. 1, if the application is made with a DN such as C = Japan, L = Kanagawa, ST = Yokosuka, CN =..., The name is “Kanagawa.t”.
Since “Yokosuka” is not registered in the DN management table 15 of “bl”, the request for the application is rejected,
Processing will be terminated.

As described above, by managing the DN using the DN management table 15 and the public key certificate table 21, it becomes possible to confirm malicious access and a mistake in specifying the DN of the user at the same time. This makes it possible to add a new user entry, prevent duplicate registration of a new user entry, and the like. Next, a concrete embodiment of the present invention in which the DN management table 15 and the public key certificate table 21 shown in FIG. 3 are provided to manage the public key certificate will be described with reference to FIGS.

First, a description will be given of a procedure for creating each table on which the method of the present invention is performed. (1) System Initial Generation Step In the CA initial generation process, various initial generation processes are performed, and the DIT management table creating means 8 is called as a part of the process. A group of DIT management tables 15 of the database is generated for the number of DIT layers permitted by CA. (2) Entry Name Registration Step The entry name permitted by the CA is registered in the DIT management table 15 of the corresponding hierarchy using the entry registration means 9. However, regarding this, a function such as registration of data in a database generally provided in a computer system may be used, and the present invention is not particularly new. The entry names to be registered are only those in the middle layer of the DIT, and are not registered in the public key certificate table 21.

Normally, this entry name registration is performed once at the time of initial generation, and the entry registration processing need not be performed unless the DIT structure is changed next. (3) DN Check Step In the DN check step, the DIT management table search means 10 is called, the DN information included in the information in the application sent from the user is extracted, and the DN information is decomposed for each entry. The search is repeatedly performed to determine whether or not this entry name exists in each DIT management table 15 up to the entry name one level higher. The entry name at the bottom end is not subject to confirmation. Assuming that the DN of application information is C = Japan, L = Kanagawa, ST = Yokohama, CN = Ishida, C = Japan, L = Kanagawa, ST = Yokohama is D
The IT management table 15 is searched to confirm that it is permitted, and CN = Ishida is not a confirmation target. (4) Service allocation step The service allocation step is D in the DN check step.
After the validity of N is confirmed, the service (processing) type information, which is a part of the application information, that is, the type of inquiry from the user is determined, and a public key certificate creating step and a public key certificate adding step are performed. This is a process of allocating to any of the public key certificate deletion steps. (5) Public Key Certificate Creation Step In the public key certificate creation step, the public key certificate creation means 11 is called. Here, after confirming that the lowest end (common name) of the DN applied by the user does not exist in the corresponding public key certificate table 21, an entry is created in this table. Then, a public key certificate is created based on the application form information, and newly registered in a corresponding entry in the corresponding public key certificate table 21. If the DN of the user at the time of requesting the creation of the public key certificate is described as C = Japan, L = Kanagawa, ST = Yokohama, CN = Ishida, the entry name of “Ishida” and the public key in the public key certificate table 21 A certificate will be added.
Referring to FIG. 3, an entry of “Ishida” is created in the corresponding public key certificate table 21 and certificate 1 is registered. However, if the entry of “Ishida” already exists under ST = Yokohama, this application is rejected. (6) Public key certificate adding step In the public key certificate adding step, it is confirmed that the lowest end (generic name) of the applied DN exists in the corresponding public key certificate table 21 and the corresponding entry is provided. By verifying the electronic signature attached to the application using the public key certificate registered in the above, it is confirmed that the user is the same as the user corresponding to the entry. Thereafter, a public key certificate is created from the application information, and the public key certificate is added to the entry of the corresponding DN in the corresponding public key certificate management table 21. Similar to the creation step, the additional step is described as follows: C = Japan, L = Kanagawa, ST = Yokohama, CN = Ishida. If “Ishida” of CN already exists in the public key certificate table 21 and its entry is In the case where the certificate 1 exists, if the user requests additional creation of a different public key certificate (for example, registration of a public key used in a different encryption algorithm), the certificate already exists. After confirming that they are the same user using Certificate 1,
Subsequent to the registered certificate 1, a certificate 2 is added. This allows the user to have a plurality of public key certificates. Referring to FIG. 3, since the entry of “Ishida” already exists in the public key certificate table 21, the certificate 2 is added. In the additional application, if the lowest end (generic name) of the applied DN does not exist in the corresponding public key certificate table 21, the application is rejected. (7) Public Key Certificate Deletion Step In the public key certificate deletion step, it is confirmed that the lowest end (generic name) of the applied DN exists in the corresponding public key certificate table 21 and the corresponding entry is checked. By verifying the electronic signature attached to the application using the public key certificate registered in the above, it is confirmed that the user is the same as the user corresponding to the entry. After that, the public key certificate corresponding to the applied “serial number” is deleted. Here, if all the certificates owned by the common name are deleted,
The entry with that common name will also be deleted. Referring to FIG. 3, the certificate 1 or certificate 2 of the corresponding entry of the corresponding public key certificate table 21 is deleted. Here, if both certificates 1 and 2 are deleted, the entry of “Ishida” itself is also deleted.

In the above description, if one of the entry names in the DIT management table 15 of all the hierarchies is obtained in the DN check step 3, the process proceeds to the distribution step, but before proceeding to the distribution step, the DN of the DN is checked. It is checked whether or not an entry having a common name matching the bottom end exists in the corresponding public key certificate table 21. Thereafter, a distribution step is executed. Omitted to check. Also, in the deletion step, depending on the contents of the application form, even if multiple certificates are registered for the common name,
You may delete all the certificates and common names, that is, delete the entry. Further, the DN tree structure DIT is not limited to the example shown in FIG. 1 and may be configured using, for example, the hierarchical relationship of organizations. In other words, the DN used in the application
What is necessary is just to create the tree structure according to.

[0019]

As is apparent from the above description, according to the method and the recording medium of the present invention, a new creation / addition / deletion service of a public key certificate is realized at the same time as the DN check processing, and this service is realized. It is possible to construct a system that realizes this.

[Brief description of the drawings]

FIG. 1 is a diagram showing an example of a DIT structure.

FIG. 2 is a diagram showing a processing flow of the present invention.

FIG. 3 is a diagram showing a table construction example of a database used in the present invention.

FIG. 4 is a diagram showing an example of a processing procedure of the method of the present invention.

FIG. 5 is a view showing the result of FIG. 4;

 ──────────────────────────────────────────────────続 き Continued from the front page (72) Inventor Takashi Ogawa 223-1 Yamashita-cho, Naka-ku, Yokohama-shi, Kanagawa Prefecture NTT Software Corporation

Claims (9)

[Claims] [Claim 1] A name described in a public key certificate is managed in a tree structure with its common name at the lowest level, and a public key certificate is created, added, deleted, In a method of performing management such as confirmation, a DIT management table is provided for each hierarchy except for the lowest hierarchy of the tree structure and the next higher hierarchy (leaf), and each DIT management table has its entry name, A management table name having the lower hierarchy as an entry is provided. A public key certificate table is provided for each leaf one level higher from the lowest hierarchy of the tree structure, and a column for each common name is provided in each public key certificate table. And a public key certificate column. 2. The public key certificate management method according to claim 1, wherein each of the DIT management tables is readable only, and each of the public key certificate tables is readable, writable, and erasable. . 3. The name under application is decomposed for each level of the tree structure, and each part of the decomposed name corresponds to the D
D to check if it exists in the entry name of IT management table
N check step, and if all the checks pass the above DN check step, CN check for checking whether the lowest end of the application name exists in the common name of the above public key certificate table corresponding thereto. If the common name does not exist in the CN check step and the processing type under application is created, a public key certificate is created, and the entry name one level higher than the lowest end of the application under application is created. 3. The public key according to claim 2, further comprising a creating step of newly writing the common name of the name being applied and the created public key certificate to the corresponding public key certificate table. Certificate management method. 4. If the common name exists in the CN check step and the processing type under application is deleted, the public key certificate corresponding to the entry name one level higher than the lowest end of the application under application is deleted. The public key certificate managing method according to claim 3, further comprising a deleting step of deleting a certificate for the corresponding common name in the certificate table. 5. If the common name exists in the CN check step and the processing type under application is deleted, the public key certificate corresponding to the entry name one level higher than the lowest end of the application under application 4. The public key certificate management method according to claim 3, further comprising a deleting step of deleting the corresponding common name and its certificate from the table. 6. If a common name exists in the CN check step and the processing type under application is added, a public key certificate is newly created, and a one-step higher rank from the lowest end of the name under application is created. 5. The newly created public key certificate is added to a common name in the public key certificate table corresponding to an entry name that matches the lowest end of the name under application. Public key certificate management method. 7. If a common name exists in the CN check step, the electronic signature attached to the application is verified using a registered public key certificate corresponding to the common name, and the verification is performed. 7. The public key certificate management method according to claim 4, wherein the process proceeds to a subsequent process if the test passes. 8. The name described in the public key certificate is managed in a tree structure with its common name as the lowest hierarchy. For each hierarchy except the lowest hierarchy and the next higher hierarchy of the tree structure,
A DIT management table having each entry name and each management table name corresponding to the entry in the lower hierarchy is provided. For each leaf one level higher from the lowest hierarchy, the column of the common name and the public key certificate A public key certificate table with columns is provided, and public key certificates can be created, added,
A recording medium on which a program for performing management such as deletion and confirmation by a computer is recorded, wherein only the DIT management table can be read, and the public key certificate table is read.
A DN check step of enabling writing and deletion, decomposing the application name for each tree structure hierarchy, and examining whether each part of the decomposed name exists in the corresponding entry name of the DN management table. If all the checks pass in the above-mentioned DN check step, a distribution step for determining whether the processing type under application is created, deleted, or added; Check whether the lowest end of the name is in the common name of the public key certificate table corresponding to the entry name of the next higher level, and if not, create a public key certificate, and in the public key certificate table, If it is determined that the common name at the lower end, the public key certificate created above and the distribution step are to be deleted, the lower end of the name under application is Checks whether the entry is in the common name of the above-mentioned public key certificate table corresponding to the entry name one level higher, and if there is, deletes at least the public key certificate corresponding to the common name in the above-mentioned public key certificate table. And if it is determined that the name is to be added in the distribution step, it is determined whether or not the lowermost end of the application name is in the common name of the public key certificate table corresponding to the entry name of the next higher level. An additional step of creating a new public key certificate, if any, and adding the newly created public key certificate to the certificate column of the lowest common name in the public key certificate table. A computer-readable recording medium included in the program. 9. The deleting step and the adding step verify the electronic signature attached to the application using the registered public key certificate corresponding to the common name if the common name exists. 9. The recording medium according to claim 8, further comprising a step of, if the verification is passed, proceeding to subsequent processing.