KR20090027554A - Method for issuing certificate of electric filing document, and system for storing certificate of electric filing document therefor, and the recording media storing the program performing the said method - Google Patents

Abstract

A method for issuing the certificate of an electronic filing document, an electronic document safekeeping system and a recording medium in which a program for realizing the method is stored are provided to implement a clean and efficient issuing service by defining a standardized certificate request and the profile of a certificate. An electronic document safekeeping system(100) deals an electronic filing document and a certificate for the document. A user terminal(110) is connected with a user who requests the registration of an electronic filing document. A requester terminal(115) is connected with a person who requests a certificate. An electronic document storage server(130) generates and transmits a certificate response message including a certificate request message and a certificate based on a searched traces. A public certification authority server(150) performs the public authentication between the user terminal or requester terminal and the electronic document storage server.

Description

Method for issuing certificate of electric filing document, and system for storing certificate of electric filing document therefor, and the recording media storing the program performing the said method}

The present invention relates to a method for issuing an electronic document certificate, an electronic document storage system, and a recording medium storing a program for implementing the method. More specifically, a method for issuing an electronic document certificate relating to a technology for issuing or verifying various certificates (specifically, a registration certificate, an issuance certificate, a transfer certificate, a revocation certificate, an original certificate, and a verification certificate) for an electronic document, and a method for the same An electronic document storage system and a recording medium storing a program for implementing the method.

In general, an electronic filing document is an electronic form by an apparatus having an information processing capability such as a computer, and refers to information that can be stored and transmitted using a signal. Such electronic documents are protected under today's legislation, for example, according to Article 5 of the Telecommunications Business Law, "E-Documents are not valid as documents because they are in electronic form, unless otherwise provided by other laws. It is not denied. "

However, in the related art, a certificate for estimating the authenticity of such an electronic document has not been properly prepared. For this reason, in the case of forging or tampering with an electronic document through hacking or the like, proper coping is not achieved, causing a user to doubt the electronic document itself.

On the other hand, the prior invention on the electronic document certificate is Korea Patent Publication No. 2006-110955 (name of the invention: the method of updating the content certificate of the electronic document content identification system and the method of verifying the updated content certificate). However, the general contents described in this invention are intended to extend the validity of the electronic document, and there is no mention of the role of the certificate for determining the authenticity of the electronic document. In addition, the present invention also includes a verification method, which considers a DVCS (Data Validation and Certification Server) service (see the contents of claim 4 of the patent claim). It is limited to verification. Therefore, it is difficult to say that the verification was sufficiently performed only by this verification method.

The present invention has been made to solve the above problems, an electronic document certificate issuance method and an electronic document storage system for the same, and a program for implementing the method related to the technology for issuing or verifying the authenticity of the electronic document. It is an object to provide this stored recording medium.

The present invention also provides a method for issuing an electronic document certificate relating to a technology for issuing or verifying a certificate (specifically, a registration certificate, an issuance certificate, a transfer certificate, a revocation certificate, an original certificate, and a verification certificate) for various uses of an electronic document. It is an object of the present invention to provide an electronic document storage system and a recording medium storing a program for implementing the method.

The present invention also provides a method for issuing an electronic document certificate related to a technology for validating a certificate issued through a certificate validation procedure and a certificate content verification process, an electronic document storage system, and a recording medium storing a program for implementing the method. For the purpose.

In order to achieve the above object, the present invention provides a method for issuing a certificate for authenticating an electronic document, the method comprising: (a) generating a certificate request message requesting issuance of the certificate, and transmitting the certificate request message; step; (b) retrieving an evidence to be proved in the certificate request message; (c) attempting to issue the certificate based on the certificate request message and the retrieved evidence; And (d) generating a certificate response message including the certificate and transmitting the certificate response message if the certificate issuance is successful, and generating an error message including a cause if the certificate issuance fails and generating the error message. It provides an electronic document certificate issuing method comprising the step of transmitting.

Preferably, the certificate is a registration certificate to prove the registration of the electronic document, an issuance certificate to prove the issuance of the electronic document, a transfer certificate to prove the transfer of the electronic document, a revocation certificate to prove the disposal of the electronic document, issued electronic And at least one of an original certificate certifying that the document is the same original as the archived electronic document, and a time verification certificate certifying that the schedule data existed at a specific time.

Preferably, in step (c), the stored certificate policy is used.

More preferably, when the certificate is the registration certificate, the certificate response message containing the registration certificate is generated and transmitted for the first time without receiving the certificate request message.

More preferably, when the certificate is the original certificate, in the step (b), in addition to the original electronic document, it is characterized in that the original certificate for the converted version having the same configuration as the original.

More preferably, when the certificate is the original certificate, the certificate response message generated in the step (d) is characterized in that it is in the form included in DIP (Dissemination Information Packages).

More preferably, when the certificate is the time-confirmation certificate, the certificate request message in step (a) includes a data hash value.

More preferably, if the certificate is at least one of the time verification certificate, the issue certificate, the transfer certificate, and the revocation certificate, in the middle of the steps (a) and (b), the integrity of the certificate request message It is characterized by verifying.

More preferably, when the certificate is one or more of the issuance certificate, the transfer certificate and the revocation certificate, in step (b), it is characterized in that whether the existing evidence based on the certificate request message.

Preferably, the certificate response message in the step (d) is characterized in that it comprises the issued electronic document.

In addition, the present invention provides an electronic document storage system for handling an electronic document and a certificate for the electronic document, comprising: a user terminal to which a person requesting registration of an electronic document is connected; A requestor terminal to which the requestor of the certificate is connected; An electronic document storage server for searching for a certificate to be proved in a certificate request message indicating the request, and generating and transmitting a certificate response message including the certificate based on the certificate request message and the retrieved certificate; And an accredited certification authority server configured to perform an accredited authentication between the user terminal or the requestor terminal and the electronic document storage server.

Preferably, the electronic document storage system further includes a commissioner terminal to which the person accepting the electronic document or the certificate is connected, wherein the receiver terminal is a third party terminal to which the user terminal, the requestor terminal, and a third party connect. It is characterized in that any one of.

Preferably, the electronic document archive server generates and transmits an error message including a cause when the certificate response message generation fails.

Preferably, the certificate generated by the electronic document storage server is a registration certificate to prove the registration of the electronic document, issuance certificate to prove the issuance of the electronic document, a transfer certificate to prove the transfer of the electronic document, proof of discarding the electronic document At least one of a revocation certificate, an original certificate for proving that the issued electronic document is the same as the archived electronic document, and a time-confirmation certificate for proving that the schedule data existed at a specific time.

Preferably, the electronic document storage server is characterized by including the electronic document issued in the certificate response message.

Preferably, the electronic document storage system is operated by the electronic document storage server, and further comprises an electronic document storage database for storing one or more of the electronic document, the certificate and the evidence, wherein the electronic document storage database And a write once read many (WORM) function.

More preferably, the electronic document storage server includes a communication unit for receiving the certificate request message, and transmits the certificate response message or the error message; A registration manager for registering the electronic document, generating a mark for registering the electronic document, and generating the registration certificate; A message generator for generating the certificate response message or the error message; An issue management unit for issuing the electronic document, generating an evidence of the electronic document issuing fact, and generating the original certificate; An integrity verification unit that verifies the integrity of the certificate request message; A point-of-view management unit generating the point-of-view certificate based on the data hash value included in the certificate request message; An evidence retrieval unit for retrieving whether there is an existing evidence based on the certificate request message; Another management unit generating at least one of the issued certificate, the transfer certificate, and the revocation certificate based on the evidence retrieved by the evidence retrieval unit; And interlocking the electronic document storage database and controlling the overall operations of the communication unit, the registration manager, the message generator, the issue manager, the integrity verifier, the point of time manager, the trace retrieval unit, and the other manager. It characterized in that it comprises a central processing unit.

Preferably, the certificate request message processed by the electronic document archive server and the certificate response message generated by the electronic document archive server are Abstract Syntax Notation One (ASN.1), Basic Encoding Rules (BER), and DER (Distinguished). An IETF RFC 3852 Cryptographic Message Syntax (CMS) structure for encoding in any one of Encoding Rules) is formed.

The present invention also provides a recording medium in which a program for implementing the above-described method is stored in a computer-readable recording medium.

The present invention produces the following effects in accordance with the above objects and configurations. First, by defining a standardized certificate request and certificate profile, it is possible to provide transparent and efficient issuance services in issuing certificates by the electronic document repository, and to expand the certification service and to provide reliability of services by ensuring compatibility of certificates. do. Second, by defining standardized verification methods of certificates, the use of certificates is activated, and furthermore, it is possible to realize the construction of a reliable system through convenient and improved verification power.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. First of all, in adding reference numerals to the components of each drawing, it should be noted that the same reference numerals are used as much as possible even if displayed on different drawings. In addition, in describing the present invention, when it is determined that the detailed description of the related known configuration or function may obscure the gist of the present invention, the detailed description thereof will be omitted. In addition, the following will describe a preferred embodiment of the present invention, but the technical idea of the present invention is not limited thereto and may be variously modified and modified by those skilled in the art.

1 is a conceptual diagram schematically showing the overall configuration of an electronic document storage system according to a preferred embodiment of the present invention. As shown in FIG. 1, the electronic document storage system 100 according to a preferred embodiment of the present invention includes a user terminal 110 connected to a user and a certificate requester terminal connected to a certificate requester. 115, a certificate holder terminal 120 to which the certificate holder (nominee) is connected, the electronic document storage server 130, the electronic document storage database 135 and a public certification authority (network connection with the terminals 110 to 120) ( And a Certificate Authority (CA) server 150.

In the above description, the user terminal 110, the certificate requester terminal 115, the certificate holder terminal 120, etc. are classified according to the subject requesting a specific task for convenience, but the user or certificate requester may be the certificate holder at the same time. Of course, it can be implemented as a single user terminal unified. In other words, it will be understood that each of a user, a certificate requester, and a certificate holder can request and receive a job from the electronic document storage server 130 in one user terminal.

The user terminal 110 is a terminal to which the user is connected, and serves as a subject that uses a task such as electronic document storage in the electronic document storage server 130. Specifically, the user terminal 110 will use the work of the general storage server 130, such as registration, disposal, transfer, issuance of electronic documents. On the other hand, the user terminal 110 may also be transferred to the certificate requestor terminal 115 and the certificate holder terminal 120 according to the type and action of the requested task. In the above description, an electronic filing document is information created in an electronic form by an information processing system, which can be transmitted and received as a signal, and is stored in the electronic document storage database 135 by the electronic document storage server 130. .

The certificate requestor terminal 115 is a terminal to which a certificate requester connects, and serves as a subject for requesting a certificate. Specifically, the certificate requester terminal 115 prepares a certificate request form, submits it to the storage server 130, and performs a function of receiving a certificate.

The certificate holder terminal 120 is a terminal to which a certificate holder is connected, and serves as a subject for receiving and using a certificate. Specifically, the certificate holder terminal 120 performs the function of verifying the issued certificate or using the delegated authority. Therefore, the certificate holder terminal 120 may be any one of the two terminals (110, 115) described above in the embodiment of the present invention. Of course, the certificate holder terminal 120 may be a third party terminal that is connected to a third party.

As described above, the above-described user terminal 110, certificate requestor terminal 115 and certificate holder terminal 120 may be implemented as a mobile phone, PDA, computer, etc. having a terminal function in the embodiment of the present invention. However, the present invention is not necessarily limited thereto, and any device having a predetermined shape including a key input unit generating an input signal and a display unit displaying an output signal will be sufficient.

The electronic document storage server 130 is a subject that performs an electronic document verification task. The main function of the present invention is to issue a certificate. The electronic document storage server 130 issues a certificate for the certificate request by the requester terminal 115, and the request for the certificate uses a protocol of request and response. Specific functions that the electronic document archive server 130 performs in the embodiment of the present invention, including certificate issuance, are as follows.

First, the repository server 130 performs a request task for registration, disposal, transfer, issuance, etc. of the electronic document, and performs a function of generating a record for this in the form of a trace. Records are kept secure to ensure integrity and, in the case of registration functions, additional registration certificates will be issued.

Second, the storage server 130 performs a function of issuing a registration certificate, issuance certificate, transfer certificate, revocation certificate, original certificate, time verification certificate and the like. Each certificate described above is defined as follows. The registration certificate is defined as a certificate issued for the evidence for the electronic document registration function performed by the storage server 130 in the embodiment of the present invention. The issuance certificate is defined as a certificate for issuing a certificate for the electronic document issuing function performed by the storage server 130 in the embodiment of the present invention. The escalation certificate is defined as a certificate issued for the evidence for the electronic document transfer function performed by the storage server 130 in the embodiment of the present invention. The revocation certificate is defined as a certificate issued for the evidence for the electronic document revocation function performed by the repository server 130 in the embodiment of the present invention. The original certificate is defined as a certificate certifying that the contents of the electronic document issued by the repository server 130 are the same as the contents of the original electronic document held by the repository in the embodiment of the present invention. The viewpoint confirmation certificate is defined as a certificate in the embodiment of the present invention, which proves that specific data existed at a specific time.

Meanwhile, the procedure for issuing the above-mentioned certificates by the storage server 130 will be described later with reference to FIGS. 2 to 6.

Third, the storage server 130 performs a function of providing the information necessary to verify the various certificates described above. Certificate verification is performed by a certificate verifier terminal (not shown) to which a certificate verifier is connected. The certificate verifier terminal may be the requestor terminal 115 or the delegate terminal 120 in the embodiment of the present invention. . Meanwhile, the verifier terminal may further request specific data from the storage server 130 as needed. In this case, the storage server 130 preferably provides specific data only when it is determined that the verifier terminal has authority. The certificate verification method is described later.

The electronic document storage database 135 functions to store and store various records (including electronic documents) generated by the electronic document storage server 130 in the form of a trace in an embodiment of the present invention. To this end, it is preferable that the storage medium implementing the database 135 has a write once read many (WORM) function. Then, during the set retention period, deletion, forgery, tampering, or the like becomes impossible and reliability can be improved.

The public certification authority server 150 is networked with the electronic document storage server 130 in the embodiment of the present invention. The public certification authority server 150 performs a function of issuing a certificate of the storage server 130 users. In addition, the public certification authority server 150 provides a directory or online certificate status protocol (OCSP) function for certificate validation. These functions implemented by the certification authority server 150 are described in, for example, "X500; ITU-T Recommendation X.500 | ISO / IEC 9594-1: 1998, Information technology-Open Systems Interconnection-The Directory: Overview Of Concepts, Models. and Services "," X501; ITU-T Recommendation X.501 | ISO / IEC 9594-2: 1995, Information technology-Open Systems Interconnection-The Directory: Part 2: Models "," X509; ITU-T Recommendation X.509 ISO / IEC 9594-8: 1998, Information technology-Open Systems Interconnection-The Directory: Authentication Framework ".

Next, the electronic document storage server 130 constituting the electronic document storage system 100 will be described. 2 is a block diagram schematically illustrating an internal configuration of an electronic document storage server in an electronic document storage system according to a preferred embodiment of the present invention. 2, the electronic document storage server 130 according to a preferred embodiment of the present invention communication unit 200, registration management unit 205, message generating unit 215, issuance management unit 220, integrity verification unit ( 225, a view point management unit 230, a trace retrieval unit 235, other management unit 240, and a central processing unit 210. In addition, of course, the electronic document storage server 130 further includes a power supply unit (not shown) for supplying power so that the electronic document storage server 130 can be driven at all times. In addition, the electronic document storage server 130 may further include an input unit and an output unit to input a specific signal or display a processed result.

The electronic document storage server 130 may be implemented as a conventional computer that may act as a server although the name server is used. Therefore, the server used in the present invention should be understood as a device concept having an information processing capability including a server, a computer and the like. This is the same also in the case of the public certification authority server 150. Meanwhile, the functions of the components 200 to 240 constituting the electronic document storage server 130 will be described together with the method according to FIGS. 3 to 6, which will not be described in detail.

Next, as described above, the procedure for issuing various certificates by the storage server 130 will be described. 3 to 6 are flowcharts for explaining a certificate issuing procedure of the electronic document storage server in the electronic document storage system according to the preferred embodiment of the present invention. A description with reference to FIGS. 3 to 6 is as follows.

① Issuance of Registration Certificate

Referring to FIG. 3, in a first step, the user terminal 110 requests electronic document registration. This request is received by the communication unit 200 of the storage server 130 (S300). In the second step, the registration management unit 205 of the storage server 130 registers the electronic document at the request of the user terminal 110 (S305). Thereafter, the registration manager 205 generates a trail for registering the electronic document (S310).

In a third step, the central processing unit 210 of the storage server 130 stores and stores the electronic document and the evidence in the storage database 135 (S315). In a fourth step, the registration management unit 205 is linked to the repository database 135 under the control of the central processing unit 210 (S320). Thereafter, the registration management unit 205 generates a registration certificate by using the certificate policy and the evidence stored in the repository database 135 (S325).

In a fifth step, the message generating unit 215 generates a reply message to the electronic document registration request by including the registration certificate (S330). In a sixth step, the central processing unit 210 provides the generated reply message to the user terminal 110 through the communication unit 200 (S335).

On the other hand, if the registration management unit 205 fails to generate a registration certificate in step S325, the message generating unit 215 generates an error message including the cause (S340). Thereafter, the central processing unit 210 transmits an error message to the user terminal 110 through the communication unit 200 (S345).

On the other hand, in the embodiment of the present invention, if the registration certificate is the first time, it is preferable to automatically issue even without a separate request of the user terminal 110.

② Issuance of Original Certificate

Referring to FIG. 4, in a first step, the user terminal 110 requests issuance of an electronic document. This request is received by the communication unit 200 (S400). In the second step, the issuance management unit 220 of the storage server 130 issues an electronic document original in response to a request of the user terminal 110 (S405). Thereafter, the issuance management unit 220 generates a trace for the original issue of the electronic document (S410).

In a third step, the central processing unit 210 stores and stores the evidence in the storage database 135 (S415). In a fourth step, the issuing manager 220 is linked to the repository database 135 under the control of the central processing unit 210 (S420). Thereafter, the issuing management unit 220 generates an original certificate using the stored certificate policy and the issued electronic document original (S425). On the other hand, if there is a translation (for example, a copy) having the same configuration as the original electronic document, the issuance management unit 220 may further issue the original certificate for this translation, if necessary.

In a fifth step, the message generating unit 215 attaches the original electronic document (or even the electronic document converted) and the original certificate requested to be issued to the DIP (S430). Here, the DIP is a distribution information package, and refers to a structure used by the electronic document storage server 130 when providing the electronic document to the user terminal 110. In a sixth step, the central processing unit 210 provides the DIP to the user terminal 110 through the communication unit 200 (S435).

On the other hand, if the issuance management unit 220 fails to generate the original certificate in step S425, steps S440 and S445 are the same as step S340 and step S345.

On the other hand, in the embodiment of the present invention, the original certificate is attached to the DIP with the electronic document at the time of issuing various electronic documents, it is preferable to be automatically issued to the user terminal 110 without a separate certificate request.

③ Issuance of Certificate of Time Confirmation

Referring to FIG. 5, in the first step, the requester terminal 115 generates a proof request including a data hash value (S500). Thereafter, the requester terminal 115 transmits the proof request to the storage server 130. Then, the communication unit 200 receives this (S505). In a second step, the integrity verification unit 225 of the storage server 130 verifies the integrity of the certificate request (S510). If the integrity verification unit 225 does not check the integrity of the certificate request, the message generator 215 generates a message that denies the integrity of the certificate request (S515). Thereafter, the central processing unit 210 transmits this message to the requester terminal 110 through the communication unit 200 (S520). Of course, the electronic archive server 130 may not take any action on the integrity denial of the certificate request.

In the third step (assuming that the integrity of the certificate request is positive after this step), the point-of-view management unit 230 of the repository server 130 uses the data hash values described in the certificate request and the certificate request. In step S525, a certificate of time verification is generated. In a fourth step, the central processing unit 210 provides the generated time verification certificate to the requester terminal 115 (S530).

On the other hand, if the point of view management unit 230 fails to generate the point of time verification certificate in step S525, the subsequent steps S535 and S540 are the same as the steps S340 and S345.

④ Issuance of other certificates (issuance certificate, transfer certificate, revocation certificate, etc.)

Referring to FIG. 6, in the first step, the requester terminal 115 generates a proof request (S600). Thereafter, the requester terminal 115 transmits the proof request to the storage server 130. Then, the communication unit 200 receives this (S605). In a second step, the integrity verification unit 225 verifies the integrity of the certificate request (S610). If the integrity verification unit 225 does not check the integrity of the certificate request, the subsequent steps S615 and S620 are the same as the case of FIG.

In the third step (which is also the same as that of FIG. 5), the evidence retrieval unit 235 of the storage server 130 is linked to the storage database 135 under the control of the central processing unit 210 (S625). Subsequently, the evidence searching unit 235 searches for evidences based on the certificate request document (S630). In a fourth step, the other management unit 240 of the storage server 130 generates other certificates using the stored certificate policy, the retrieved evidence and the certificate request (S635).

In a fifth step, the central processing unit 210 provides the generated other certificate to the requester terminal 115 (S640).

On the other hand, if the other management unit 240 fails to generate the other certificate in step S635, steps S645 and S650 subsequent to that is the same as steps S340 and S345.

Meanwhile, in the above description with reference to FIGS. 3 to 6, three messages are transmitted and received between the two terminals 110 and 115 and the electronic document storage server 130. The certificate request message, the certificate response message, and the error message are the certificate request message. The certificate request message refers to a series of information (eg, a certificate request) generated or requested by the two terminals 110 and 115 to issue a certificate. The certificate response message refers to a series of information (eg, reply message or DIP) generated by the electronic document storage server 130 as a result of the processing of the certificate request message. Finally, the error message refers to information generated including the cause when the generation of the certificate response message fails. Hereinafter, these messages will be described in more detail. First, the certificate request message will be described.

The certificate request message uses signedData represented by a ContentInfo structure presented by IETF RFC 3852 Cryptographic Message Syntax (CMS). signedData is a commonly used structure, and has a function to give various additional information and functions. CMS basically conforms to Abstract Syntax Notation One (ASN.1) Basic Encoding Rules (BER), and may require DER (Distinguished Encoding Rules) for some information. have.

As described above, a method for implementing the above-described certificate request message is described in, for example, "X680; ITU-T Recommendation X.680 | ISO / IEC 8824-1: Information Technology Abstract Syntax Notation One (ASN.1): Specification of basic notation", "X690; ITU-T Recommendation X.690 | ISO / IEC 8825-1: Information Technology ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", See, eg, "CMP; Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP) (RFC 4210), IETF, 2005", "CMS; Cryptographic Message Syntax (RFC 3852), IETF, 2004". The same is true for certificate response messages and error messages.

The signedData structure of CMS consists of signature object, signing certificate, and signature information. Accordingly, the content of the message, the digital signature of the certificate requestor that generated the message, and the certificate requestor's certificate are included in the encapContentInfo field, the signerInfos field, and the certificates field, respectively. The encapContentInfo field contains the ARCCertRequest structure that forms the actual data in the message and is digitally signed to provide integrity. To distinguish message contents, identifier uses id-kiec-arcCertRequest. The certificates field is a set of certificates that can include the certificate authority's certificate and the top-level CA certificate, as well as the certificate used by the certificate requester to sign the message. The format of the certificate refers to an X.509 version 3 certificate issued by a public certification system. Although the certificates field is optional, the present invention includes a certificate requestor's certificate to generate a message. The signerInfos field is a set of signerInfos and indicates a information about a signer. The certificate requester includes the certificate requester's digital signature in signerInfo for the integrity of the message. signerInfo includes digital signature, digital signature algorithm and attributes, and certificate requester can additionally use the attributes mentioned in CMS standard.

On the other hand, it has already been mentioned that the certificate request message has a structure of signedData including an ARCCertRequest. The basic and extended fields of this structure message are described below.

The basic fields of the message are the parts except for the extension fields of the message, and indicate essential information necessary for generating the message such as version, requestor, request time, policy, trace, and random number. The basic field is information that must be included in the message. For this purpose, ARCCertRequest follows DER encoding.

Next, look at each piece of information that makes up the basic field. First, the version field indicates the version of the message. If targetHash is used in the target field, version 2 should be used. Otherwise, version 1 should be used.

The requester field indicates a subject that has requested to issue a certificate. The certificate requestor is based on using the otherName field of the GeneralName structure to encode the certificate requester's real name into UTF8String and hash the certificate requestor's identification number twice. If the certificate requester is a business operator, use the business name as the real name and the business number as the identification number. If the certificate requester is an individual, the social security number is used as an identification number. In this case, a secure random number is generated to be used in conjunction with the social security number to prevent theft of the social security number. The requester field has a structure similar to the subjectAltName of an accredited certificate that uses the IdentifyData structure defined in the Korea Information Security Agency's "[KCAC.TS.CERTPROF] Digital Signature Certificate Profile Technical Specification". The HashedIDNInfo structure applied to the present invention is used without using the VID structure defined in "[KCAC.TS.SIVID] Identification Technical Specification using Identification Number". Meanwhile, the archive server 130 must verify the IdentifyData of the requester field in the process of receiving and verifying the certificate request.

The requestTime field means certificate request time. The certificate request time means the time when the certificate requester generated the message, so it has a later time than when the repository performs its work. If the certificate request time value of the message is incorrect or different from the time of the archive server 130, the archive server 130 should treat the certificate issue as unsuccessful and send an error message to the certificate requester. The certificate request time uses the GeneralizedTime format.

The policy field represents a certificate policy. The certificate requester can request a certificate by selecting a certificate policy to be issued. This field must be reviewed by the repository server 130 and the repository server 130 must know the policy. PolicyQualifiers are not used during the defined structure.

The target field is a field including a target that a certificate requestor wants to prove through a certificate. The target field may be configured as identification information of the evidence or hash information of the data according to the type of certificate requested.

The targetRecord field is a record of the function provided by the repository server 130 and includes an identifier of the evidence to be authenticated by the certificate requester through the certificate. In the case of a message for issuing one or more of a registration certificate, issuance certificate, transfer certificate, and revocation certificate, a target field must be set using a targetRecord field.

The serialNo field is an identification number of a record recording a function provided by the storage server 130 and should be the same value as the serialNo field, which is a subfield of an OperationRecord structure included in a target field of a certificate to be issued. The storage server 130 should be able to generate up to 20 bytes using a positive integer that increases sequentially when generating serialNo of the deposit, and the user software should be able to process the serialNo of up to 20 bytes in length.

The opType field means a type of function provided by the storage server 130, that is, a job type, and should be the same value as the opType field, which is a subfield of an OperationRecord structure included in a target field of a certificate to be issued. The meaning of each function is as follows.

□ register: Electronic document registration, issue: Electronic document issuance, transfer: Electronic document transfer, delete: Electronic document disposal

The targetHash field is used to prove that data existed at a specific time. It is expressed in the form of a HashedDataInfo structure. In the case of a message for issuing a time verification certificate, the target field must be set using the targetHash field.

The hashedData field is a hash value of the data to be verified once using hashAlg, which is a hash algorithm.

The nonce field indicates a temporary value generated by the certificate requestor. The nonce field is basically used to prevent reuse attacks and guessing attacks.

Next, look at the extension fields. The extended field has the following structure.

Extensions :: = SEQUENCE SIZE (1..MAX) OF Extension

Extension :: = SEQUENCE {

extnID OBJECT IDENTIFIER,

critical BOOLEAN DEFAULT FALSE,

extnValue OCTET STRING}

The extension consists of extnID, which indicates the type of the extension field, critical, which indicates the importance, and extnValue, which contains the value of the extension field. If critical of the extended field is set to TRUE, the repository server 130 must be able to understand and process the extended field.

Hereinafter, each field constituting the extension field will be described. The Qualifications extension field is about entitlement and indicates information about the subject and the role to be delegated. This field can be used to specify the person responsible for the certificate when the subject to which the certificate is to be received must be limited. You can use this field to generate a certificate that is valid only for a specific person, and to grant access to a document to that person. If you use this field to grant a person access to a document, you must request a certificate of registration. The Qualifications extension field has a structure in which a plurality of qualification fields consisting of nomineeInfo, which is the certificate holder's information, and nomineeRole, which is a role or authority to be delegated, can be listed in a plurality. Certificate holder information consists of the certificate holder nominee and the certificate holder's certificate information nomineeCert. One of the two fields must exist. If the certificate holder is an individual, only nomineeCert should be used. In the case of a licensee, both the nominee field or the nomineeCert field may be used. The nominee field is created in the same way as the requester field using the real name and identification number of the person responsible. The nomineeCert field is constructed using information extracted from the certificate of the recipient.

NomineeRole :: = BIT STRING {

onlyForNominee (0),

readDocument (1),

downloadDocument (2)}

The nomineeRole field indicates the role or authority of the person in charge. The meaning of each bit value is as follows.

□ onlyForNominee: Indicates that the certificate is a valid recipient.

ReadDocument: Indicates that the document can be read from the storage server 130.

DownloadDocument: indicates that the document can be downloaded from the storage server 130.

Note that for the onlyForNominee value, all qualifications must be turned on or off at the same time. When setting the value of readDocument or downloadDocument in the nomineeRole field, the value of the opType field, which is a subfield of the targetRecord field, must be set to register. Conversely, if the value of the opType field, which is a subfield of the targetRecord field, is not register, the readDocument or downloadDocument value should not be set in the nomineeRole field. When creating this field, critical value should be set as TRUE.

The UsageType extension field is for certificate usage and indicates the classification method according to the usage environment or usage of the certificate. The certificate requester can use the UsageType field to define the usage environment or use of the certificate. If you can semantically coexist, you can set multiple UsageTypes for the same certificate.

id-kiec-usageType OBJECT IDENTIFIER :: = {iso (1) member-body (2) korea (410) kiec (200032) certificate (2) aRCCertificateExtensions (3) 2}

UsageType :: = BIT STRING {

online (0),

mobile (1),

paperEnable (2)}

Here, the meaning of each bit value is as follows.

□ online: Indicates that it can be used in an online environment.

□ mobile: Indicates that it can be used on mobile devices.

□ paperEnable: Indicates that paper certificate can be printed and used.

As above, critical value should be set to FALSE when generating this field.

The DateOfExpiration field is used by the certificate requestor to specify the expiration date of the certificate. If this field is not used, the expiration date is set using the expiration date defined by the vault server 130 in the certificate policy. In addition, when the critical value of this field is FALSE and the requested certificate validity expiration date exceeds the policy validity expiration date, the repository server 130 sets the certificate validity expiration date using the policy validity expiration date. The certificate expiration date must be later than the certificate request time. As described above, the critical value when generating this field may be TRUE or FALSE.

The CertifiedTime field relates to the date and time of the warranty. If the user wants to be guaranteed that the electronic document has been stored in the storage server 130 for a period of time from the time of registration, the certified time field should be described. The warranty date and time cannot be later than the certificate request time. If a message containing this field is processed normally and a certificate having the same value as this field is issued, the certificate guarantees that the electronic document was stored in the archive from the time of registering the electronic document to the time described in this field. . This field must be created only when requesting a registration certificate and cannot be included in other types of messages. As above, critical value should be set as TRUE when generating this field.

Next, the certificate response message (hereinafter, abbreviated as 'response message') will be described. In response to the certificate request, the storage server 130 issues the certificate or transmits information on the rejection or failure to the certificate requester. In the following, the structure of the response message transmitted to the certificate requester for the certificate request and the cause classification for the certificate issue failure are given.

First, in the structure of the response message, the response message sent by the archive server 130 also uses signedData represented by a ContentInfo structure presented by IETF RFC 3852 CMS (Cryptographic Message Syntax), which is an electronic signature structure, like the certificate request message. Therefore, the content of the response message is included in encapContentInfo, the electronic signature of the storage server 130 that generated the response message is included in signerInfos, and the certificate of the storage server 130 is included in certificates.

The encapContentInfo field contains the ARCCertResponse structure, which is the actual data of the response message, and is digitally signed to provide integrity. To distinguish the response message contents, the identifier uses id-kiec-arcCertReseponse. The ARCCertResponse structure includes arcCertInfo which is attestation information or arcErrorNotice which is error information, and information about each will be described later.

The certificates field is a set of certificates, and may include a certificate of a certification authority and a top certificate authority certificate, including a certificate used by the storage server 130 to sign a response message. The format of the certificate refers to an X.509 version 3 certificate issued by a public certification system. Although the certificates field is optionally available, the present invention includes a certificate of the repository server 130 to generate a response message.

The signerInfos field is a set of signerInfos and indicates a information about a signer. The archive server 130 includes the digital signature of the archive in signerInfo for the integrity of the response message. The signerInfo includes digital signatures, digital signature algorithms and attributes, and the repository server 130 may additionally use the attributes mentioned in the CMS standard.

The certificate in the response message has a structure of signedData including 'arcCertInfo' of the ARCCertResponse, and is composed of basic fields and extended fields as in the case of a certificate request message. First, the basic field will be described, and the extended field will be described later.

The certificate basic field is a part excluding extension fields of the certificate, and indicates essential information necessary for generating a certificate such as a version, serial number, issuer, issue time, expiration time, policy, requestor information, and evidence. The certificate basic field is information that must be included in the certificate.

ARCCertInfo :: = SEQUENCE {

version [0] EXPLICIT ARCVersion DEFAULT v1,

serialNumber SerialNumber,

issuer GeneralNames,

dateOfIssue GeneralizedTime,

dateOfExpiration DateOfExpiration,

policy ARCCertificatePolicies,

requestInfo RequestInfo,

target TargetToCertify,

extentions [1] EXPLICIT Extensions OPTIONAL}

ARCCertInfo follows DER encoding method and each item is as follows.

The version field indicates the version of the certificate. If dataHash is used in the target field, version 2 should be used. Otherwise, version 1 should be used.

The serialNumber field represents a serial number (specifically, an identification number) of a certificate issued by the storage server 130. Serial numbers should not be issued with the same number, only positive integer values should be used. The repository server 130 should be able to generate serial numbers of certificates up to 20 bytes, and the user software should be able to process serial numbers up to 20 bytes in length.

The issuer field refers to the repository server 130 that issues a certificate, and in a small sense, refers to an attestation system that issues a certificate. This may identify the repository server 130 that issued the certificate to be verified using the certificate issuer field. The issuer field is generated in the same manner as the requester field of the certificate request message by using the real name and identification number of the storage server 130.

The dateOfIssue field represents a point in time when the archive server 130 generates a certificate for a user's certificate issuance request (ie, a certificate issuance date). The certificate issue date uses the GeneralizedTime format.

The dateOfExpiration field means the validity expiration date of a certificate. In general, a certificate expiration date is determined based on a certificate policy. If the dateOfExpiration extension field is present in the certificate request message (hereinafter abbreviated as 'Request message') and the critical value is TRUE, the archive server 130 sets the value of this field using the value of the dateOfExpiration field of the request message. Should be. If the value of the dateOfExpiration field of the request message is TRUE or cannot be set equal to the value of the dateOfExpiration field of the request message for some reason, it should be treated as a failed certificate issue and an error message should be sent to the certificate requester.

If the critical value of the dateOfExpiration field of the request message is set to FALSE and the field value exceeds the validity expiration date according to the certificate policy, the repository server 130 sets the certificate validity expiration date by using the validity period on the policy. If the critical value of the dateOfExpiration field of the request message is set to FALSE and the field value is within the certificate policy expiration date, then the archive server 130 sets the certificate validity expiration date using that value or by using the policy expiration date. It is possible. Note that the validity expiration date of the initial registration certificate issued at the time of electronic document registration must be the same as the RetentionExpiredDate of the electronic document.

The validity period of a certificate in the use of the certificate is between the date of issue of the certificate and the expiration date of the certificate. However, if the validity of the certificate signing certificate expires soon or has already expired and the certificate is not valid to guarantee the validity of the certificate, the user issuing the certificate signed by the renewed certificate again. The vault server 130 must issue a renewal certificate of the same expiration date. The means for issuing a certificate renewal is to extend the validity of the certificate by updating the information on the signature attached to the certificate and the certificate used for signing. The contents of the certificate before the renewal and the certificate after the renewal are not changed. Therefore, the user does not need to create a separate request message to request the renewal issuance to the storage server 130, and the content of the arcCertInfo field of the certificate issued for renewal should be the same as the content of arcCertInfo of the previous certificate. Upon re-signing for certificate renewal issuance, the repository server 130 may remove the old signature information attached to the certificate and add new signature information generated using the updated repository certificate.

The policy field represents a certificate policy. The policy of a certificate includes the operating policy for that certificate in the repository where the certificate is issued and the scope of use of the certificate by the user. The archive server 130 should define registration certificate policy, issuance certificate policy, transfer certificate policy, revocation certificate policy, original certificate policy, etc. as basic certificate policy, and give each policy an object identifier (OID). If necessary, a detailed certificate policy can be defined and used under each basic certificate policy. In addition, the storage server 130 may additionally define a viewpoint verification certificate policy for issuing a viewpoint verification certificate and assign and use an OID. Because the certificate's policy determines the purpose and validity of the certificate, all subjects using the certificate must be aware of the policy content described in the certificate policy.

ARCCertificatePolicies consists of a set of PolicyInformation structures. PolicyInformation consists of a policyIdentifier describing a certificate policy and a policyQualifiers describing it in more detail. policyQualifiers include cPSuri, which represents a URI address for disclosure of business rules, and userNotice, which provides users with simple policy-related information. In the present invention, the PolicyQualifierInfo structure expressed using cPSuri must be included, and the PolicyQualifierInfo structure expressed using userNotice may be optionally included. noticeRef is not created when userNotice is used, and explicitText should be BMPString.

The requestInfo field represents a certificate request message generated by a certificate requester. A general certificate request for which a certificate requester requests a certificate must use the ARCCertRequest in the request message, or null if no request message exists, such as the original registration certificate or the original certificate.

The target field relates to an authentication target, and is a field indicating evidence of a function provided by the repository server 130 or a fact that the repository intends to guarantee through a certificate. The archive server 130 generates a record of the work in the form of OperationRecord structure based on the point of time when the processing is completed for the work such as registration, issuance, transfer, and disposal requested by users, and records it as a certificate, and as a subject of proof when issuing a certificate. We include in certificate. In addition, the storage server 130 may include the information of the original electronic document and the issued electronic document in the certificate to prove that the contents of the electronic document is the same as the original electronic document that is stored when the electronic document is issued. The original certificate issued in this way is attached to the DIP. In addition, the repository server 130 may issue the certificate including hash information sent by the certificate requester, which provides a function of proving that some data existed at a specific time.

The opRecord field is an evidence record recorded by the vault server 130 to perform a certain function and is set at the time of issuing a registration certificate, issuance certificate, transfer certificate, or revocation certificate, and the orgAndIssued field is the original electronic document stored in the vault server 130. This field consists of information and issued electronic document information. It should be set when the original certificate is issued. The dataHash field shall be set using the data hash information described in the request message when issuing a time verification certificate.

OperationRecord :: = SEQUENCE {

serialNo INTEGER,

opRequesterInfo OperationRequesterInfo,

opRequestTime GeneralizedTime,

opTime GeneralizedTime,

opType OperationType,

orgDocInfo PackageDocumentInfo,

issuedDocInfo [0] EXPLICIT PackageDocumentInfo OPTIONAL,

peerARCInfo [1] EXPLICIT PeerARCInfo OPTIONAL,

reason [2] EXPLICIT Reason OPTIONAL}

Here, the meaning of each field is as follows.

□ serialNo: identification number of the evidence

□ opRequesterInfo: Electronic document service requester information

□ opRequestTime: Electronic document service request time

□ opTime: service providing time of the storage server 130, that is, working time

□ opType: Type of service provided by the repository server 130, that is, job type.

□ orgDocInfo: Original document related information stored in the storage server 130

□ issuedDocInfo: Information related to the document issued when issuing the document

□ peerARCInfo: Related information of the relative storage server 130 when transferring or watering

□ reason: Reason for work

The values of the serialNo field and the opType field must be the same as the values of the serialNo field and the opType field in the targetRecord field of the request message. The opRequester field is the identity information of the requester for the electronic document-related task, and is generated in the same manner as the requester field of the request message by using the real name and identification number of the user who requested the electronic document task such as registration, issuance, transfer, and disposal. If the business requester is an individual, the storage server 130 directly generates a secure 160-bit random number in order to prevent the theft of the social security number to be used when generating the requester field. The storage server 130 stores the generated random number together with the evidence structure to use during the verification process when it is necessary to verify the identity of the business requester. If there is no requestor for electronic documents, such as automatic discarding of electronic documents at the expiration date, null is used instead of opRequester.

In the opRequestTime field, a value equal to the time value described in the ReceiveDateTime field of the AIP must be set. Similarly, the opTime field should be set to the same value as the time value described in the RegisterDateTime field of the AIP. Here, AIP is a preservation information package, and refers to a structure that the electronic document storage server 130 configures when storing a user's document.

The orgDocInfo field includes information of the original electronic document stored in the storage server 130, and the issuedDocInfo field includes information of the issued electronic document, which is expressed in the form of a PackageDocumentInfo structure. The orgDocInfo field should be set as the original electronic document information for all functions performed by the archive server 130, and issuedDocInfo may be optionally set as information on the issued electronic document when the archive server 130 performs the electronic document issuing function. do.

The packageID field sets a value obtained by converting a package identifier into UTF8String format. The docInfo field includes reference information of an electronic document in a package. When used in the orgDocInfo field, the docInfo field shall always contain the reference information of the original electronic document in the AIP. When used in the issuedDocInfo field, the docInfo field shall contain the reference information of the original or translated electronic document included in the DIP. The docID field sets the value of the electronic document identifier converted to UTF8String format.

The fileIDs field represents an ID of a related attachment file among attachments in the electronic document, and is expressed as a list of values of the attachment file identifiers converted to UTF8String format. If all attachments in the electronic document apply, omit the fileIDs field itself. The docHash field is represented in the form of a DocumentHash structure containing the hash value of the electronic document. The hashedDocument field is a value that hashes the contents of the electronic document once using hashAlg, which is a hash algorithm. When two or more actual document files are included in the electronic document, the contents of each document file are concatenated and hashed. At this time, the concatenation order of the document files is the same as the order in the associated electronic document.

The peerARCInfo field is a field created only when an electronic document is transferred or a water pipe is generated, and when a certificate of registration of a water pipe storage server and a water pipe certificate of a water pipe storage server are generated. When the peerARC field and the peerARCPackageID field are used to transfer or digitize an electronic document, the transfer certificate issued by the repository server that performed the transfer includes the identification information of the repository server that performed the export and the package identifier of the AIP granted by the repository server. In addition, the registration certificate issued by the repository server that performed the vestigation includes the identity information of the repository server that performed the migration and the package identifier of the AIP assigned by the repository server. If the value of opType is 0 (register) and peerARCInfo item exists, it can be seen that it is a registration certificate for an electronic document transferred from another archive server. The peerARC field is generated in the same way as the requester field of the request message by using the real name and identification number of the partner repository server.

The Reason field is an optional creation field. It sets the reason for the operation and the meaning of the value is as follows.

□ userRequest: work by user request

ArcRequest: An operation that occurred during the process in the repository server

□ expired: Retention period expired

The orgAndIssued field used in the original certificate is represented by the OriginalAndIssuedDocumentInfo structure. The orgDocInfo field included in the orgAndIssued field includes information of the original electronic document stored in the storage server 130, and the issuedDocInfo field includes information of the issued electronic document, which is expressed in the form of a PackageDocumentInfo structure. The docInfo field in the DocumentInfo structure must be created and contains the reference information of the associated electronic document contained in each package.

Similarly, the issuedDocOriginal field indicates whether the issued electronic document is an original electronic document or a converted electronic document. If the value of the issuedDocOriginal field is TRUE, the value of the hashedDocument field contained in the orgDocInfo field and the hashedDocument field contained in the issuedDocInfo field. Must have the same value, and if FALSE the two values must be different. The electronic document storage system issuing the certificate according to the present invention shall use the same hash algorithm when generating the value of the hashedDocument field in the orgDocInfo field and when generating the value of the hashedDocument field in the issuedDocInfo field. In addition, the value of the hashedDocument field included in the issuedDocInfo field must always be the same as the value hashed by concatenating all the electronic document files included in the electronic document in the DIP with the original certificate attached in the same order included in the electronic document by the same hash algorithm. .

In the case of a request message for issuing a time verification certificate, the target field is set using the targetHash field, and the storage server 130 should set the target field of the certificate using the corresponding field information when issuing the certificate. That is, the target field of the certificate must be set using the dataHash field, which is set identically using the value set in the targetHash field of the request message. Before issuing the certificate of time verification, in the process of verifying the request message received from the certificate requester, the storage server 130 uses the hash algorithm OID described in the hashAlg field, which is a subfield of the targetHash field, and a hash value generated using the corresponding hash algorithm. You should check whether the length of the hashedData field value is reasonable.

Next, the extension field will be described. The extended field has the following structure.

Extensions :: = SEQUENCE SIZE (1..MAX) OF Extension

Extension :: = SEQUENCE {

extnID OBJECT IDENTIFIER,

critical BOOLEAN DEFAULT FALSE,

extnValue OCTET STRING}

The extension consists of extnID, which indicates the type of the extension field, critical, which indicates the importance, and extnValue, which contains the value of the extension field. If critical of the extended field is set to TRUE, the certificate consumer or verifier must be able to understand and handle this extended field.

The Qualifications field is related to entitlement and indicates information on a subject to receive and use a certificate and a role to be delegated. This field shall contain the same contents as the Qualifications field of the request message. This field may not be generated in the original registration certificate and the original certificate issued without the request message. If the Qualifications extension field is present in the request message and the critical value is TRUE, the repository server 130 must generate this field. If this field cannot be created, it should be treated as a failed certificate issue and an error message should be sent to the certificate requester. When creating this field, critical value should be set as TRUE.

The UsageType field relates to a certificate use and indicates a classification method according to the use environment or use of the certificate. This field contains the same contents as the UsageType field of the request message. If the UsageType extension field is present in the request message and the critical value is TRUE, the repository MUST create this field. If this field cannot be generated, it should be treated as a failed certificate issue and an error message should be sent to the certificate requester. When creating this field, critical value should be set as FALSE.

The CertifiedTime field is related to the date and time of the guarantee. It is a field that guarantees that the electronic document has been stored in the archive from the time of electronic document registration to the time described in this field, and can be included only in the registration certificate. Registration certificate generated in accordance with the present invention must create a CertifiedTime field. However, this field should not be created for the initial registration certificate. If the CertifiedTime extension field is present in the request message and the critical value is set to TRUE, the archive server 130 confirms that the electronic document was being held by the warranty date specified in the CertifiedTime field of the request message, and then stores the value in the CertifiedTime field of the certificate. Create a certificate by writing in If the electronic document is not stored in the storage database 135 from the time of registration of the electronic document until the guarantee date described in the request message, the storage server 130 should transmit an error message to the certificate requester. If the value of the CertifiedTime field does not exist in the request message, the repository server 130 sets the value of the CertifiedTime extension field by the following procedure.

□ If an electronic document is destroyed or transferred to another archive server before the expiration date of the electronic document, set the relevant date and time.

□ If an electronic document is normally stored by the expiration date of the electronic document, set the date and time.

□ If the electronic document is currently stored in the archive database, set the same value as the certificate issue date field.

In the present invention, if the CertifiedTime extension field is present in the request message, the critical value must be set to TRUE, so the case of FALSE is not dealt with. If this field cannot be created for any other reason, it shall be treated as a failure to issue the certificate and an error message should be sent to the certificate requester. When creating this field, critical value should be set as TRUE.

Next, the error message will be described. When receiving a request message that does not apply the present invention or failing to generate a certificate that applies the present invention, the repository server 130 should generate an error message instead of the certificate and send it to the certificate requester. A message containing error information is sent to the certificate requester using ARCErrorNotice.

ARCErrorNotice :: = SEQUENCE {

    transactionStatus PKIStatusInfo,

    transactionIdentifier GeneralName OPTIONAL}

In the above, the transactionIdentifier field is not used. PKIStatusInfo uses the structure defined in IETF RFC 4210 as shown below.

PKIStatusInfo :: = SEQUENCE {

status PKIStatus,

statusString PKIFreeText OPTIONAL,

failInfo PKIFailureInfo OPTIONAL}

PKIStatus :: = INTEGER {

accepted (0),

grantedWithMods (1),

rejection (2),

waiting (3),

revocationWarning (4),

revocationNotification (5),

keyUpdateWarning (6)}

PKIFreeText :: = SEQUENCE SIZE (1..MAX) OF UTF8String

In the above, the value of PKIStatus always uses only rejection. PKIFreeText can contain detailed error messages. The failInfo field also uses PKIFailureInfo used in RFC 4210, and the values used in the present invention are as follows. See Table 1 below for the content of these values.

PKIFailureInfo :: = BIT STRING {

badAlg (0),

badMessageCheck (1),

badRequest (2),

badTime (3),

badDataFormat (5),

wrongAuthority (6),

incorrectData (7),

unacceptedPolicy (15),

unacceptedExtension (16),

badSenderNonce (18),

signerNotTrusted (20),

unsupportedVersion (22),

unAuthorized (23),

systemUnavail (24),

systemFailure (25)}

TABLE 1

number message Contents 0 badAlg Undefined or Unsupported Algorithm One badMessageCheck Request message integrity corruption (eg digital signature verification failure) 2 badRequest Unauthorized or unsupported work request 3 badTime The time of the request message is different from the system time (policy exceeds the tolerance) 5 badDataFormat Invalid request message format 6 wrongAuthority Invalid authority (the agency name of the request message is different from the response message generator) 7 incorrectData The content of the request message is incorrect 15 unacceptedPolicy Requested policy not supported 16 unacceptedExtension Requested extension field not supported 18 badSenderNonce Invalid sender nonce 20 signerNotTrusted Request message signer not identified or trusted 22 unsupportedVersion Unsupported Request Message Version 23 notAuthorized Unauthorized sender 24 systemUnavail The system is currently unavailable 25 systemFailure Failed to Take Control from System

Other error messages include: See Table 2 for details.

TABLE 2

number message Contents 8 missingTimeStamp Timestamp required but not generated 13 badRecipientNonce Invalid user nonce

Next, the certificate verification method will be described. 7 is a flowchart illustrating a certificate verification method of a certificate verifier terminal in an electronic document storage system according to a preferred embodiment of the present invention. As described above, the certificate verifier terminal is a terminal to which any one of the user who owns a certificate for which a certificate requestor, a certificate holder, or a certificate holder is not specified is connected. Such a certificate verifier terminal performs a function of verifying a certificate by interworking with the repository server 130 and the repository database 135 in the embodiment of the present invention, but the certificate verification is not necessarily limited to the certificate verifier terminal. That is, in the present invention, it is possible to allow the repository server 130 to implement such certificate verification method alone. Hereinafter, the certificate verification method will be described with reference to FIG. 7.

Certificate verification methods are largely divided into certificate validation procedures and certificate content verification procedures. Here, the certificate validation procedure is a procedure for confirming whether or not the conditions for validity as a certificate are satisfied, and the certificate content verification procedure is a procedure for confirming whether the conditions for utilizing the certificate are satisfied.

In the above-described certificate verification method, the step of verifying the certificate format issued in the embodiment of the present invention (S700), if there is no error in step S700, the step of verifying the validity period of the issued certificate (S705), the error in step S705 If there is no error in the step of verifying the revocation of the issued certificate (S710), if there is no error in step S710 (S715), if there is no error in step S715, if there is no error in the signing certificate of the issued certificate Verification step (S720), if there is no error in step S720 Verification of the certificate issued to the certificate request included in the request message (S725), if there is no error in step S725 verification of the certificate issued compared to the electronic document Step (S730), if there is no error in step S730 step of verifying the recipient who is issued the electronic document and certificate (S735), if the legitimate person in step S735 Verifying the certificate policy stored in the database 135 (S740), if there is no error in step S740, verifying the use of the electronic document and the certificate (S745), and verifying the certificate requestor in good faith in step S745 (S750), if the right person in the step S750 is implemented by displaying the pass (pass) to complete the verification (S755) and the like.

In the above, steps S700 to S720 correspond to a certificate validation procedure, and steps S725 to S750 correspond to a certificate content verification procedure. On the other hand, if there is an error in the steps S700 to S750 or is not a legitimate person or malicious, a verification failure (fail) is displayed and the process is terminated (S760). On the other hand, between the step S730 and S735 step may be a verification step for the proof evidence and the verification step for the original proof. Details will be described later. Hereinafter, each step of the certificate verification method will be described in detail.

① Certificate validation procedure (S700 ~ S720)

Certificate validation is a process of checking whether the conditions for validity of a certificate are satisfied. If the validation fails, the certificate contained in the certificate cannot be trusted. Therefore, the certificate no longer functions as a certificate issued by a trusted authority. It cannot be done. Certificate validation is divided into certificate format verification, certificate validity verification, certificate revocation verification, digital signature verification, and signature certificate verification. If it fails in one step, it is treated as verification failure without proceeding with the next process.

② Certificate format verification step (S700)

In the certificate format verification step, it is checked whether the certificate to be verified is generated in compliance with the certificate format posted in the present invention. After verifying the structure of the certificate defined in the present invention and compliance with the mandatory or prohibited field generation rule, it is confirmed that there is no contradiction between each field in the certificate. Some of the major examples of field contradictions are:

□ The signature of the certificate does not match the information in the issuer field.

□ The semantically inconsistent structure and contents of certificate policy OID and target field

□ Inconsistency between the content of requestInfo and the content of other fields

□ If it is not a registration certificate and the value of readDocument or downloadDocument is set in the nomineeRole field.

If only some of the qualification fields in the Qualifications field are set to onlyForNominee

□ Qualifications fields are created on the original registration certificate and original certificate.

□ Your enrollment certificate is not created with the CertifiedTime field.

□ You are not an enrollment certificate and the CertifiedTime field is created.

❏ If the certificate is a time-test certificate but the value of the Version field is not 2.

□ It is not a time verification certificate, but the value of Version field is not 1.

In addition, if a field generation rule defined in the present invention is not observed or there is a mutual contradiction in the contents of each field, the verification failure is treated. If the certificate to be verified is generated in the wrong format, the verification process ends here without further processing.

③ Verification period of certificate validity period (S705)

The certificate validity period means from the date of certificate issue (dateOfIssue) to the certificate validity expiration date (dateOfExpiration), this step is to confirm that the certificate verification time is within the certificate validity period. Certificates are only valid within the validity period of the certificate, so the validity of the certificate is lost if the verification date is earlier than the certificate issue date or after the certificate expiration date. The verification point (T) is compared with the certificate issue date and certificate expiration date as follows.

Iii) if dateOfIssue = T <dateOfExpiration: validation succeeded

Ii) if T <dateOfIssue or dateOfExpiration = T: validation failed

If the verification point is not within the validity period of the certificate, it is treated as a verification failure and the verification process ends.

④ Verification of whether the certificate is abolished (S710)

In this step, the certificate verifier requests the storage server 130 to confirm whether the certificate to be verified is revoked. In principle, the certificate issued by the vault server 130 as a trust authority is not revoked during the validity period. However, if a case arises that the certificate must be revoked for a serious reason, the vault server 130 revokes the certificate. In addition, the revocation information of the certificate should be provided to the certificate verifier through the certificate revocation check service. The certificate verifier sends a verification target certificate to the storage server 130 to request confirmation of revocation. The storage server 130 checks whether the certificate has been revoked, and then, in the response message, whether the certificate is revoked and revoked. In the case of a certificate, the reason for revocation is transmitted to the certificate verifier.

If the certificate verifier needs to perform the certificate requestor verification step (S750), the certificate requester may request a random number generated by the certificate requester and stored in the storage server 130 during the procedure of checking whether the certificate is revoked. The random number is included with the verification result and sent to the certificate verifier. If a response message of the storage server 130 indicating that the certificate has been revoked is received, it is treated as a verification failure and the verification process ends.

⑤ Digital signature verification step (S715)

The certificate issued by the repository server 130 includes an electronic signature for providing integrity and non repudiation, and verifies the electronic signature included in the certificate in the electronic signature verification step. Digital signature verification follows the general digital signature verification method for signedData of CMS. If the verification of the digital signature fails, it means that the integrity of the certificate has been compromised. Since the contents of the certificate can no longer be trusted, subsequent processes become meaningless.

⑥ Signature certificate verification step (S720)

The signing certificate verification step includes verifying that the certificate that signed the certificate is the certificate of the storage server 130 and verifying the validity of the certificate. The certificate verifier compares the certificate or certificate identification information of the storage server 130 owned by the certificate signing certificate and confirms that the certificate signing certificate is the certificate of the storage server 130. The process of the certificate verifier obtaining the certificate or the certificate identification information of the storage server 130 corresponds to a part that can be easily designed by those skilled in the art, and thus the content thereof is omitted in the present invention. On the other hand, the path establishment of certificate signing certificate and the validation of certificate are verified according to "KCAC.TS.CERTVAL" of "Certified Certificate Path Verification Technical Standard" of accredited certification system.

Failure to validate the Certificate Signing Certificate will also invalidate the Certificate. However, even if the validity of the certificate signature certificate fails, if the validity period of the certificate is successfully verified and the digital signature long-term verification technology is applied, if the verification is successful according to the verification technology, the result of the validation of the signature certificate is related. The certificate is considered to be successful.

The digital signature long-term verification technology is, for example, the Technical Specification (KKAC.DN; Digital Signature Certification Management System DN (Distinguished Name) Standard v1.1, established by the Korea Electronic Commerce Agency or related agencies), v1.1, Korea Information Security Agency, 2003. , "KCAC.DSCP; Digital Signature Certificate Profile Technical Specification v1.10, Korea Information Security Agency, 2004", "KCAC.SIVID; Identification Technical Specification using Identification Number v 1.11, Korea Information Security Agency, 2002"). Make sure to apply accordingly.

⑦ Verification procedure of certificate contents (S725 ~ S750)

The verification process of the contents of the certificate is a process of verifying the utility of the subject or external environment of the certificate. Even if the verification fails, the validity of the certificate itself is not lost. However, if the verification request and comparison verification, electronic document verification failed, the verification failure message is notified to the storage server 130 so that the storage server 130 checks this and abolishes the certificate to lose the validity of the certificate. The method of notifying the storage server 130 of the verification failure message may be easily performed by those skilled in the art, and thus will be omitted herein. A user of a certificate that fails verification of content cannot use the certificate.

Verification of certificate contents is divided into verification request, comparison verification, electronic document verification, officer verification, policy verification, usage verification, certificate requestor verification, and if it fails in one step, it is treated as verification failure without proceeding with the next process. The order of each verification can be changed as needed.

⑧ Verification request and comparison verification step (S725)

As soon as the certificate requester receives the certificate from the vault server 130, the certificate requester must confirm whether the issued certificate is a certificate for the certificate request sent to the vault server 130. Therefore, comparison verification with the certificate request can only be performed by the certificate requester who generated the certificate request. The certificate requester confirms that the arcCertRequest of the requestInfo field, which is the certificate request message information of the certificate issued by the storage server 130, is identical to the value of the ARCCertRequest structure of the encapContentInfo field of the certificate request generated and sent by the certificate server. If the verification of the comparison with the certificate request failed, the certificate requester notifies the repository server 130 of the fact that the comparison verification failed with the certificate request to be abolished, and to be issued a certificate again.

⑨ Electronic document verification step (S730)

If the certificate verifier has an electronic document package associated with the certificate, the verification must be performed against the hash value of the electronic document contained in the certificate subject field of the certificate. Since the original certificate is always issued attached to the DIP, the original proof must be verified during the electronic document verification work. In the case of the certificate of time verification which proves that the data existed at a certain time, this electronic document verification process is not performed.

검증 Verification step for evidence attestation

The opRecord field, which is the evidence subject field of a certificate, means evidence evidence, orgDocInfo field containing the hash value of the original electronic document and issuedDocInfo field containing the hash value of the issued electronic document. The orgDocInfo field is always included in the evidence field. As a field, the archive server 130 includes a hash value of the original electronic document included in the archived AIP, and the issuedDocInfo field includes a hash value of the electronic document included in the DIP as a field that is included only in the trace that performed the document issuing function. do. Therefore, in order for a user to be a certificate verifier and verify a hash value of an electronic document in the orgDocInfo field, an original electronic document identical to the electronic document included in the SIP and registered in the repository server 130 is required. The hash of the electronic document in the issuedDocInfo field is required. To verify the value, we need an electronic document extracted from the DIP. In the above, the SIP refers to the acquisition information package, which refers to a structure configured when the user transmits the electronic document to the electronic document storage server 130.

If the certificate verifier needs to perform an electronic document verification, the electronic document must be acquired, and the process of obtaining the electronic document by the certificate verifier is omitted below. In the process of performing the electronic document verification, the matters to be careful of, the process performed by the storage server 130 in the process of hashing each document file when a plurality of electronic document files in the original or converted electronic document in the package And the process performed by the certificate verifier must be identical. That is, the repository server 130 or the certificate verifier connects a plurality of electronic document files included in the electronic document of the original or the converted copy in the order included in the package, and then hashes the electronic document once by a predetermined hash algorithm. Generate a hash value of. If the hash value of the electronic document in the package and the hash value of the generated electronic document is different, the certificate can no longer be used, the certificate verifier notifies the repository server 130 to abolish it.

검증 Verification step for original proof

The orgAndIssued field, which means the original proof as the attestation field of the certificate, has an orgDocInfo field that contains the hash value of the original electronic document and an issuedDocInfo field that contains the hash value of the issued electronic document, similar to the evidence proof. The server 130 includes a hash value of the original electronic document included in the stored AIP, and the issuedDocInfo field includes a hash value of the electronic document included in the DIP. The orgAndIssued field also contains an issuedDocOriginal field that indicates whether the issued electronic document is an original electronic document or a converted electronic document. If the issuedDocOriginal field is TRUE, the two hash values are the same. Should be different.

Since the original certificate is always issued attached to the DIP, the certificate verifier must verify whether the hash value of the issuing electronic document set in the issuedDocInfo field and the hash value of the electronic document included in the DIP are identical. If the user needs to verify the hash value of the original electronic document set in the orgDocInfo field when the user is the certificate verifier, the original electronic document must be obtained as in the proof proof, and the process of obtaining the original electronic document by the certificate verifier is omitted below. do. The hash procedure of an electronic document is generated in the same way as for the proof of evidence. If the hash value of the electronic document in the package and the hash value of the generated electronic document is different, the certificate can no longer be used, the certificate verifier notifies the repository server 130 to abolish it. In addition, it is determined that the electronic document of the DIP to which the original certificate that failed verification is attached cannot be trusted.

검증 Commissioner verification step (S735)

If there is a Qualifications extension in the certificate that specifies the recipient and the critical value is TRUE, the certificate verifier shall check the value of the Qualifications field. Recipient verification is not a process of verifying that the information of the recipient has been correctly generated, but rather a process of verifying whether the certificate verifier or claimant is a legitimate recipient. If the value of the nomineeRole field contains onlyForNominee for all qualifications in the Qualifications field of the certificate, the certificate is issued only for the certificate holders specified in nomineeInfo of each qualification item, so that the validator or claimant claiming to be a valid person Certificates may only be used by certificate holders. Even if the verification fails, the certificate verifier or the claimant is not able to use the certificate and does not lose the validity of the certificate.

If there is no Qualifications extension, the value of critical is FALSE, or the value of the nomineeRole field in all qualification fields does not contain onlyForNominee, the certificate can be used by everyone.

⑬ Certificate Policy Verification Step (S740)

The certificate verifier must verify that the certificate policy contained in the certificate to be verified is compatible with the purpose for which it is currently being used. The policy of the certificate included in the certificate contains information on the use, use, purpose, warranty scope, and the like of the certificate, and the storage server 130 announces the content for all users who use the certificate. The certificate verifier verifies that the certificate policy in the Certificate Policy field is a suitable policy for the purpose of using his certificate. Even if the policy verification fails, the certificate cannot be used for the purpose of the certificate verifier, and the certificate does not lose its validity.

⑭ Usage Verification Step (S745)

If there is a UsageType extension that specifies the purpose of the certificate in the certificate and the critical value is TRUE, the certificate verifier shall check the value of the UsageType field. If the certificate usage environment and the certificate usage field do not match, verification will fail. In the present invention, since the critical value of the UsageType field is set to FALSE, it is not necessary to verify the purpose of the certificate.

⑮ Certificate Requester Verification Step (S750)

If the certificate includes certificate requestor information, that is, if the non-null arcCertRequest field is used as the information of the requestInfo field, the requester field in the arcCertRequest field may be verified as necessary. This certificate requestor verification process aims at verifying the identity of the person claiming to be the certificate requester and the identity of the certificate requestor in the certificate. Even if the certificate requestor verification fails, it is confirmed that the claimant who is the certificate requester is not a valid certificate requestor, and does not lose the validity of the certificate.

Meanwhile, the above-described embodiments of the present invention can be written as a program that can be executed in a computer, and can be implemented in a general-purpose digital computer that operates the program using a computer-readable recording medium. The computer-readable recording medium may include a magnetic storage medium (for example, a ROM, a floppy disk, a hard disk, etc.), an optical reading medium (for example, a CD-ROM, a DVD, etc.) and a carrier wave (for example, Storage media such as transmission over the Internet).

The above description is merely illustrative of the technical spirit of the present invention, and those skilled in the art to which the present invention pertains various modifications, changes, and substitutions without departing from the essential characteristics of the present invention. will be. Accordingly, the embodiments disclosed in the present invention and the accompanying drawings are not intended to limit the technical spirit of the present invention but to describe the present invention, and the scope of the technical idea of the present invention is not limited by the embodiments and the accompanying drawings. . The scope of protection of the present invention should be interpreted by the following claims, and all technical ideas within the scope equivalent thereto should be construed as being included in the scope of the present invention.

The present invention can be used in institutions, schools, businesses, etc. that handle electronic documents, the use thereof will be very high. Moreover, since the future society is oriented toward the ubiquitous era, the present invention is expected to shine more in the future.

1 is a conceptual diagram schematically showing the overall configuration of an electronic document storage system according to an embodiment of the present invention,

2 is a block diagram schematically illustrating an internal configuration of an electronic document storage server in an electronic document storage system according to a preferred embodiment of the present invention;

3 to 6 are flow charts for explaining a certificate issuing procedure of the electronic document storage server in the electronic document storage system according to a preferred embodiment of the present invention;

7 is a flowchart illustrating a certificate verification method of a certificate verifier terminal in an electronic document storage system according to a preferred embodiment of the present invention.

<Description of Symbols for Major Parts of Drawings>

100: electronic document storage system 110: user terminal

115: certificate requester terminal 120: certificate recipient terminal

130: electronic archive server 135: electronic archive database

150: certification authority server 200: communication unit

205: Registration management unit 210: Central processing unit

215: message generating unit 220: issuing management unit

225: integrity verification unit 230: time check management unit

235: evidence search unit 240: other management unit

Claims (19)

In the method for issuing a certificate for authenticating an electronic document, (a) generating a certificate request message requesting issuance of the certificate and transmitting the certificate request message; (b) retrieving an evidence to be proved in the certificate request message; (c) attempting to issue the certificate based on the certificate request message and the retrieved evidence; And (d) if the issuance of the certificate is successful, generate a certificate response message including the certificate and transmit the certificate response message; if the issuance of the certificate fails, generate an error message including the cause and send the error message; Steps to Electronic document certificate issuing method comprising a. The method of claim 1, The certificate includes a registration certificate certifying registration of the electronic document, an issuance certificate certifying the issuance of the electronic document, a transfer certificate certifying the electronic document transfer, a revocation certificate certifying the disposal of the electronic document, and an issued electronic document. An electronic document certificate issuing method, characterized in that it is at least one of an original certificate certifying that it is the same as the electronic document, and a time-confirmation certificate certifying that the schedule data existed at a specific time. The method of claim 1, In the step (c), the electronic document certificate issuing method, characterized in that for using the stored certificate policy. The method of claim 2, And when the certificate is the registration certificate, generating and transmitting the certificate response message including the registration certificate without receiving the certificate request message only for the initial issuance. The method of claim 2, If the certificate is the original certificate, in step (b), in addition to the electronic document original, issuing an original document certificate for a converted version having the same configuration as the original. The method of claim 2, If the certificate is the original certificate, the certificate response message generated in the step (d) is characterized in that the form contained in the DIP (Dissemination Information Packages). The method of claim 2, And the certificate request message in the step (a) includes a data hash value if the certificate is the time-confirmation certificate. The method of claim 2, Verifying the integrity of the certificate request message in an intermediate step of steps (a) and (b) if the certificate is at least one of the time-certification certificate, the issue certificate, the transfer certificate, and the revocation certificate. Characterized in that the electronic document certificate issuance method. The method of claim 2, And if the certificate is one or more of the issuance certificate, the transfer certificate, and the revocation certificate, in step (b), searching for whether there is an existing certificate based on the certificate request message. The method of claim 1, The certificate response message in the step (d) comprises an issued electronic document, characterized in that the electronic document certificate. In an electronic document storage system that handles electronic documents and certificates for the electronic documents, A user terminal to which a person requesting registration of an electronic document is connected; A requestor terminal to which the requestor of the certificate is connected; An electronic document storage server for searching for a certificate to be proved in a certificate request message indicating the request, and generating and transmitting a certificate response message including the certificate based on the certificate request message and the retrieved certificate; And An accredited certification authority server for performing public authentication between the user terminal or the requester terminal and the electronic document storage server. Electronic document storage system comprising a. The method of claim 11, A recipient terminal to which the person accepting the electronic document or the certificate connects. Include more, And said commissioner terminal is any one of said user terminal, said requestor terminal, and a third party terminal to which a third party connects. The method of claim 11, The electronic document storage server generates and transmits an error message including a cause when the generation of the certificate response message fails. The method of claim 11, The certificate generated by the electronic document storage server may include a registration certificate certifying the electronic document registration, an issuance certificate certifying the issuance of the electronic document, a transfer certificate certifying the electronic document transfer, a revocation certificate certifying the disposal of the electronic document, And at least one of an original certificate certifying that the issued electronic document is the same original as the archived electronic document, and a time verification certificate certifying that the schedule data existed at a specific time. The method of claim 11, And the electronic document storage server includes an electronic document issued in the certificate response message. The method of claim 11, An electronic document storage database operated by the electronic document storage server and storing one or more of the electronic document, the certificate and the evidence. Include more, The electronic document storage database is an electronic document storage system, characterized in that it has a write once read many (WORM) function. The method according to any one of claims 11, 13, 14 and 16, The electronic document storage server, A communication unit which receives the certificate request message and transmits the certificate response message or the error message; A registration manager for registering the electronic document, generating a mark for registering the electronic document, and generating the registration certificate; A message generator for generating the certificate response message or the error message; An issue management unit for issuing the electronic document, generating an evidence of the electronic document issuing fact, and generating the original certificate; An integrity verification unit that verifies the integrity of the certificate request message; A point-of-view management unit generating the point-of-view certificate based on the data hash value included in the certificate request message; An evidence retrieval unit for retrieving whether there is an existing evidence based on the certificate request message; Another management unit generating at least one of the issued certificate, the transfer certificate, and the revocation certificate based on the evidence retrieved by the evidence retrieval unit; And A central point for interlocking the electronic document storage database and controlling the overall operations of the communication unit, the registration manager, the message generator, the issue manager, the integrity verification unit, the time verification manager, the trace retrieval unit, and the other manager; Processing Electronic document storage system comprising a. The method of claim 11, The certificate request message processed by the electronic document archive server and the certificate response message generated by the electronic document archive server are one of Abstract Syntax Notation One (ASN.1), Basic Encoding Rules (BER), and Distinguished Encoding Rules (DER). An electronic document archiving system, characterized by forming an IETF RFC 3852 Cryptographic Message Syntax (CMS) structure that encodes in either manner. In a computer-readable recording medium, A recording medium storing a program for implementing the method according to any one of claims 1 to 10.

Images