WO2012005546A2 - 전자문서 유통 시스템 및 전자문서 유통 방법 - Google Patents

전자문서 유통 시스템 및 전자문서 유통 방법 Download PDF

Info

Publication number
WO2012005546A2
WO2012005546A2 PCT/KR2011/005027 KR2011005027W WO2012005546A2 WO 2012005546 A2 WO2012005546 A2 WO 2012005546A2 KR 2011005027 W KR2011005027 W KR 2011005027W WO 2012005546 A2 WO2012005546 A2 WO 2012005546A2
Authority
WO
WIPO (PCT)
Prior art keywords
distribution
message
electronic document
electronic
address
Prior art date
Application number
PCT/KR2011/005027
Other languages
English (en)
French (fr)
Other versions
WO2012005546A3 (ko
Inventor
안대섭
이중구
공성필
임영철
Original Assignee
정보통신산업진흥원
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 정보통신산업진흥원 filed Critical 정보통신산업진흥원
Priority to JP2013518281A priority Critical patent/JP2013535858A/ja
Priority to SG2013001870A priority patent/SG187006A1/en
Priority to US13/808,576 priority patent/US9143358B2/en
Priority to CN201180043451.8A priority patent/CN103124981B/zh
Priority to EP11803832.2A priority patent/EP2602758B1/en
Publication of WO2012005546A2 publication Critical patent/WO2012005546A2/ko
Publication of WO2012005546A3 publication Critical patent/WO2012005546A3/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/60—Business processes related to postal services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/04—Real-time or near real-time messaging, e.g. instant messaging [IM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21—Monitoring or handling of messages
    • H04L51/214—Monitoring or handling of messages using selective forwarding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection

Definitions

  • the present invention relates to an electronic document distribution system and an electronic document distribution method capable of establishing an electronic document distribution system that can be secured by the general individual, small companies, along with companies / institutions.
  • the present invention is to solve the conventional problems as described above, the object of the present invention is that the electronics that can ensure the reliability of the general individual, small businesses, such as companies / institutions that can have a certain scale electronic document distribution system It is to provide a document distribution system and an electronic document distribution method.
  • Electronic document distribution system having the above object, in the system for distributing the electronic document, a distribution for transmitting and receiving a message based on the electronic address and issuing and managing the distribution certificate for the message transmission and reception
  • a transceiving entity for distributing electronic documents through a messaging server Register / manage the electronic address of the send / receive entity, set an electronic document distribution path between the send / receive entity, provide a standard format of the electronic document to the send / receive entity, and when an error occurs in the electronic document distribution process between the send / receive entity
  • a distribution hub that acts on behalf of sending messages and issues distribution certificates; And store and receive a distribution certificate, and be a trusted third party storage institution; It includes.
  • an electronic document distribution system in a method for distributing an electronic document in an electronic document distribution system including a transmitting and receiving entity and a distribution hub, (a) the transmitting entity is a receiving entity.
  • step (b) After acquiring physical address information corresponding to the address information through the distribution hub, transmitting a message attached to the electronic document to the physical address; (b) the receiving entity receiving the message, issuing a receipt certificate or error certificate according to a result of conformance verification for the received message and the transmitting entity and delivering the received certificate or error certificate to the transmitting entity; And (c) the sender who failed to send a message to the receiving entity requests the message transmission agent to the distribution hub, and the distribution hub that receives the request for the message transmission agent issues a certificate of transmission to the sender and sends the message to the receiving entity. After performing step (b); It includes.
  • the present invention having the configuration and method as described above has the effect that it is possible to build an electronic document distribution system that can be secured by individuals, small businesses, such as companies / institutions.
  • FIG. 1 is a view showing a configuration example of an electronic document distribution system according to a preferred embodiment of the present invention.
  • FIG. 2 is a diagram for explaining the distribution messaging server of FIG.
  • FIG. 3 is a diagram for explaining the distribution client of FIG.
  • FIG. 4 is a diagram for explaining the address directory server of FIG. 1.
  • FIG. 4 is a diagram for explaining the address directory server of FIG. 1.
  • FIG. 5 is a view for explaining the electronic document format register of FIG.
  • FIG. 6 is a view for explaining the distribution relay server of FIG.
  • FIG. 7 is a diagram for explaining an external linkage gateway of FIG. 1.
  • FIG. 8 is a view for explaining the validity range of the authorized electronic address in the electronic document distribution system of FIG.
  • FIG. 9 is a view for explaining the application / issuance and operation system of the authorized electronic address in a preferred embodiment of the present invention.
  • 10 to 13 are diagrams for explaining message security when distributing electronic documents in a preferred embodiment of the present invention.
  • FIG. 18 is a diagram for explaining a physical address obtaining process in a preferred embodiment of the present invention.
  • 19 to 21 are diagrams for explaining a distribution relay support process in a preferred embodiment of the present invention.
  • 22 to 24 are views for explaining a management process, such as registration of a public electronic address in a preferred embodiment of the present invention.
  • 25 and 26 are diagrams for explaining an electronic document format application process in a preferred embodiment of the present invention.
  • 27 to 29 are diagrams for explaining a spam message processing process in a preferred embodiment of the present invention.
  • 30 and 31 are conceptual views illustrating an electronic document reading service in a preferred embodiment of the present invention.
  • FIG. 32 illustrates a conceptual diagram of an external linkage gateway server in a preferred embodiment of the present invention.
  • 33 is a view for explaining a procedure in which an electronic document is distributed in association with an external system in a preferred embodiment of the present invention.
  • 34 to 38 are views for explaining the configuration of a communication protocol for operating in conjunction with each other between components for electronic document distribution under the electronic document distribution system according to an embodiment of the present invention.
  • 39 to 43 are diagrams for explaining an error handling method under an electronic document distribution system according to a preferred embodiment of the present invention.
  • 44 to 51 are diagrams for explaining a linkage interface between a distribution messaging server and an address directory server in an electronic document distribution system according to a preferred embodiment of the present invention.
  • 52 to 63 are diagrams for explaining a linkage interface between distribution messaging servers in an electronic document distribution system according to a preferred embodiment of the present invention.
  • 64 to 78 are diagrams for explaining a linkage interface between a distribution client and a distribution messaging server in an electronic document distribution system according to a preferred embodiment of the present invention.
  • 79 to 71 are diagrams for explaining a linkage interface between a distribution messaging server and a distribution relay server in an electronic document distribution system according to a preferred embodiment of the present invention.
  • FIG. 82 is a flowchart illustrating a procedure for receiving a registration as a public electronic address by authenticating a distribution messaging server system according to another embodiment of the present invention.
  • FIG. 83 illustrates a procedure for reporting a spam message to an electronic document distribution hub when a transmitting / receiving entity serves as a receiver according to another embodiment of the present invention.
  • FIG. 84 is a view showing a procedure in the case of confirming in real time whether to reject a transmission counterpart when a transmitting / receiving entity serves as a receiver according to another embodiment of the present invention.
  • FIG. 85 is a view showing a procedure for periodically checking whether to reject a transmission counterpart when a transmitting / receiving entity serves as a receiver according to another embodiment of the present invention.
  • 86 to 100 are views for explaining a distribution messaging server system according to another embodiment of the present invention.
  • 101 to 105 are diagrams for explaining a distribution protocol applied to an electronic document distribution system and method according to another embodiment of the present invention.
  • 106 and 107 are diagrams for explaining an electronic document format register according to another embodiment of the present invention.
  • FIG. 108 is a diagram for explaining an electronic document packaging applied to an electronic document distribution system and method according to another embodiment of the present invention.
  • 109 through 114 are diagrams for explaining a distribution client application according to another embodiment of the present invention.
  • FIG. 115 illustrates a system for issuing an electronic address by an address directory server according to another embodiment of the present invention.
  • FIG. 116 is a diagram illustrating a process of issuing an electronic address by an address directory server according to another embodiment of the present invention.
  • FIG. 116 is a diagram illustrating a process of issuing an electronic address by an address directory server according to another embodiment of the present invention.
  • 117 and 118 illustrate an example of a process of retrieving address information through an address directory server according to another embodiment of the present invention.
  • Figure 1 shows an example of the configuration of the electronic document distribution system according to a preferred embodiment of the present invention.
  • an electronic document distribution system transmits and receives a message through a distribution messaging server that transmits and receives a message based on an electronic address and issues and manages a distribution certificate for message transmission and reception.
  • An electronic document distribution hub 102 for performing a message transmission and issuing a distribution certificate when an error occurs in the electronic document distribution process; And receive and store distribution certificates, and trustworthy third-party archives (public offices, authorized electronic document archives; 103); It is configured to include.
  • the distribution messaging server of the transmitting / receiving entity 101 stores the transmitted / received messages in the message box including status information for each user, and stores the message transmission / reception history in a medium which cannot be edited or deleted for a predetermined period, and distributes the message for transmission / reception. Issuing a certificate to the third-party storage organization for storage, and in connection with the address directory server of the electronic document distribution hub 102 to the electronic address registration, search, modification, deletion of the transmission and reception entity 101 It allows you to use a function that includes, and transfers the messages stored for a predetermined period to the external storage device.
  • the electronic address may include a user identifier obtained by the transmitting and receiving entity 101 through an address directory server of the electronic document distribution hub 102; An additional identifier that is a unique value assigned by the send / receive entity 101 when necessary, and is a value unique within the send / receive entity 101; A delimiter located between the user identifier and the additional identifier; It includes.
  • the electronic document distribution hub 102 is provided with an electronic document format register.
  • the electronic document format register performs management including registration, deletion, and information modification of an electronic document standard form. And classify additionally according to the above and perform management including registration and modification of the context in which the electronic document standard can be used.
  • the electronic document distribution hub 102 is provided with a distribution relay server for performing a message transmission and issuing a distribution certificate when an error occurs in the electronic document distribution process between the transmission and reception entity 101, the distribution relay server is a transmission and reception entity
  • the distribution relay server is a transmission and reception entity
  • a transmission certificate is issued to the transmission / reception entity 101 that has requested the message transmission after the message transmission is performed, and when the transmission of the requested message has failed, the transmission / reception entity 101 that has requested the message transmission. Send an error message to the.
  • the electronic document distribution hub 102 has an external linkage gateway server for linkage with an external system, and the external linkage gateway server has a distribution messaging server for transmitting and receiving a message based on an electronic address, and the linked external system.
  • Verification / translation function of sending / receiving electronic address between and electronic document distribution system, message verification / translation function between associated external system and electronic document distribution system, security verification applied to electronic document between linked external system and electronic document distribution system / It provides the function of converting and verifying the suitability of the electronic document between the connected external system and the electronic document distribution system and converting each other.
  • FIGS. 1 to 118 The electronic document distribution system and the electronic document distribution method using the same according to the preferred embodiment of the present invention having the above-described configuration will be described in detail with reference to FIGS. 1 to 118 as follows. In the following description of the present invention in detail, reference numerals of FIG. 1 will be omitted.
  • the requirements of the distribution system of the electronic document distribution system according to the present invention are as follows 1 to 7.
  • the sender / receiver entity participating in the distribution system and the sender / receiver must send and receive electronic documents in a predefined manner and agree to the service level agreement (SLA) of the management authority or the electronic document relay.
  • SLA service level agreement
  • the authorized electronic address which is the information for identifying the sender and receiver and the authorized sender and receiver in the distribution system, shall be assigned to a corporation or individual unit and registered and managed by the registrar.
  • a distribution certificate When distributing electronic documents in the distribution system, a distribution certificate must be generated and transmitted and stored to the sending entity and the third-party archiving organization that participated in the distribution.
  • a gateway that supports linkage with external systems other than distribution systems should be provided.
  • the electronic document distribution system is based on an authorized electronic address, and is based on P2P communication for sending and receiving electronic documents between transmitting and receiving entities owning a distribution messaging server.
  • the structure of the electronic document distribution system according to the present invention is as shown in Figure 1, the description of the components in the system is as shown in Table 1 and Table 2 below, the main process is shown in Table 3 below.
  • Table 1 number Object name Explanation One Send and receive objects A company or institution that has a system necessary for the distribution of electronic documents, such as a distribution messaging server, and participates in the distribution of electronic documents in a manner promised in the distribution system.
  • General concepts including electronic document relay 2 Electronic document repeater Third-party organizations certified to provide electronic document distribution services to senders and receivers who do not have the necessary systems for distribution of electronic documents, such as distribution messaging servers. 3 Electronic Document Distribution Hub It is the collective name for systems that support the distribution of electronic documents between sending and receiving entities. It performs tasks such as address management, routing, error and security processing, and external connection. 4 Transceiver End user who sends and receives actual electronic documents as a basic unit for distributing electronic documents.
  • General concepts including authorized senders 5 Authorized Transceiver Sender / receiver using electronic document distribution service by signing up for electronic document relay 6 Third Party Archive Corporations that hold or certify electronic documents for others or perform other business-related tasks as designated by the Minister of Knowledge Economy.
  • Object name Explanation One Distribution Messaging Server A messaging system that distributes electronic documents in a promised manner on behalf of the sender and receiver.
  • 2 Distributor client A general term for an application used by a sender and receiver to distribute electronic documents. An application that provides functions such as editing a message and sending and receiving a message through a distribution messaging server (eg, Outlook, webmail client, etc.).
  • 3 Address directory server A system that registers and manages the sending and receiving entities participating in the electronic document distribution system based on the authorized electronic address and the authorized electronic address of the sender and provides the necessary address information for sending and receiving.
  • 4 Electronic Document Format Register A system that registers, manages, and provides standard forms of structured electronic documents such as orders, invoices, and tax invoices for publicly available to send and receive entities.
  • Distribution relay server When an error occurs in the distribution of electronic documents between sending and receiving entities in the distribution system, a system that transfers messages on behalf of the sending entity 6 External Linkage Gateway Server A system that acts as a reliable channel for the distribution system to connect with external systems 7 NTP Server A server that sends time to systems that request time in the distribution system as a Network Time Protocol server. 8 Registration agency system System for registration agencies to handle applications such as registration and registration of authorized electronic addresses
  • the distribution messaging server is a messaging system within the sending and receiving entity and plays a key role in the distribution of electronic documents.
  • the distribution messaging server physically has one IP address, but must be able to issue and manage multiple user accounts for lower users.
  • the distribution messaging server In order to manage each user account, the distribution messaging server must manage the inbox for each user account, and the distribution messaging server is responsible for managing users' accounts and inboxes safely and reliably.
  • Table 4 number Function name Explanation One Send and receive messages -Send and receive messages according to distribution protocols 2
  • Inbox management by user -Received message is stored in the message box according to user account or internal delimiter.
  • the sent document stored in the message box is managed status information in 6 steps: 1) Sending: After receiving the document, no response is received from the receiver. Completion: Received 'receipt certificate' from the recipient's distribution messaging server.3) Outsourcing: After transmission failure, the transmission relayed to the distribution relay server. 4) Transmission failure: An error occurred in the distribution messaging server of the receiver.
  • Reading failed When an error occurs while the receiver is reading the message 6) Reading completed: 'Reading certificate' is received from the recipient's distribution messaging server -Received document stored in Inbox manages status information of the next 4 steps1) Verification error: Received message 2) Before acknowledgment: Before the recipient of the document reads the list of received documents 3) Acknowledgment: The recipient of the document reads the list of received documents 4) Confirmation of reading: The recipient of the document details the received document Read the contents-When the request for deletion is received by the receiver, the received document should be physically deleted.-The outgoing message, the receipt certificate, the reading certificate, etc.
  • Transmission history management The distribution messaging server must be able to store the transmission and reception history for a certain period of time in a medium that cannot be edited and deleted.-1) Transmission history information to be kept.
  • Hash value 2 Receiving history: Hash value for sender, receiver (including user account), reception time, received document 4
  • Message supplement -Message security functions digital signature, signature verification, encryption / decryption, etc. suggested by distribution protocol must be performed 5
  • Message packaging and validation processing The document to be sent must be packaged in a message structure defined in the distribution protocol before transmission. The received document must be verified and parsed by the message structure defined in the distribution protocol after extraction and the necessary information can be extracted.
  • Distribution certificate id Distribution certificate id, issuing time, related message id, original distribution certificate (optional), registration certificate of the third party storage institution received after storage in the third party storage institution, etc.
  • Address directory server linkage -Must be able to manage address information according to address information registration and retrieval process provided by address directory server-Must have client function to call service provided by address directory server-Address information provided by address directory server A service client function must be provided that remotely invokes the registration, search, modification, and deletion functions.
  • the distribution messaging server transmits the storage request message to the distribution messaging server installed outside the third-party archiving institution for the request for archiving the distribution certificate.
  • the distribution messaging server of the third-party archiving agency sends the distribution certificate to the third-party archiving institution.
  • Invoke custody request client for archiving -If the distribution messaging server of a third party archiving agency generates a distribution certificate directly, call the custody request client at the time of creation.
  • Requesting storage from a third party 9 Internal System Interface If the distribution messaging server is a corporate internal system rather than a distribution client, it must provide functions that can be directly linked with the internal corporate system.
  • Distribution client management Manage user account, user authentication, environment information related to distribution client 11
  • -Environmental information management Environment information management for the entire distribution messaging server and environment setting function for each user must be provided-Form management 12
  • Message Retention Management -System function to transfer to external storage for automatic preservation of messages stored for more than 1 year
  • the distribution client is an application that provides a user interface (UI) for transmitting and receiving messages, viewing and managing received electronic documents, etc. for the transceivers participating in the distribution system.
  • the distribution client cannot send or receive documents on its own and must be associated with a distribution messaging server.
  • the distribution client requests the message transmission through the distribution messaging server or inquires the message received through the distribution messaging server.
  • the distribution messaging server manages the message box for each user account, and the distribution client should be able to access only the messages stored in the user's account by checking the user account information among the received documents.
  • the distribution client may be implemented as a C / S type application or a web type screen by a request of a transmitting / receiving entity.
  • Table 5 number Function name Explanation One User authentication -The distribution client must receive the login session information after checking the user account from the distribution messaging server.-The method for the distribution client to authenticate the user is 1) user authentication based on the certificate or 2) ID / PW based. User authentication, etc.-When operating based on ID / PW, security policy for PW should be enforced. Weekly PW change, difficult letter / number combination, IP address change prohibition, etc. 2 Generate message -The distribution client must provide a user interface to compose a new message.-Providing entry of items that are not preset values by environmental information among basic information required to transmit a message.
  • View message list and view details -The distribution client must provide the function to query the list of each message corresponding to the user account.-The client should provide the function to view the detailed information of the message, including the attached document.
  • Message folder management The distribution client must inform the user of the status of each message according to the status information provided by the distribution messaging server for the sending and receiving messages based on the distribution box of the distribution messaging server. Providing the ability to define and manage your own message folders is optional.
  • Basic and environmental information management -The distribution client must provide the function to manage the necessary environmental information related to sending and receiving messages.-The distribution client must be synchronized with the environmental information managed by the distribution messaging server.
  • Message security processing -Must be able to secure messages such as digital signature or encryption / decryption
  • Register and retrieve document templates -Ability to register an electronic document form register or an electronic document form located outside as a distribution client-A function to search an electronic document form within a distribution client 10
  • Address Book Management -Function to manage frequently used public electronic addresses, etc. Optionally implement the function to automatically register and manage public electronic addresses through received messages 11
  • Link with in-house system -Linkage function such as registering electronic documents in messages with groupware and work-related systems in the enterprise 12
  • the relevant information such as distribution certificate and log information should be comprehensively processed to understand the context related to the message.
  • the address directory server is a system for managing the address information for the sender / receiver entity and the authorized sender / receiver, and provide a physical address.
  • the address directory server provides the following basic functions: 1 and 2.
  • IP address physical address
  • the address directory server basically has a function of managing whitelist information.
  • the address directory server receives a report of a spam message from a user and manages blacklist information based on the report.
  • the address directory server provides information related to the public electronic address to the send / receive entity or authorized sender through the web portal screen, and the distribution messaging server and related applications can use the services provided by the address directory server through the associated interface.
  • FIG. 4 A functional conceptual diagram of the address directory server is shown in FIG. 4, and a description of the functions is shown in Table 6 below.
  • Table 6 number Function name Explanation One Certified Electronic Address Management -Management of new registration and change of public e-mail address of the sending and receiving entity and the authorized e-mail address.
  • Spam report management -Receipt of reports on spam received from distribution clients and result notification 3
  • White / Black List Management -Create and manage / storage whitelist a list of authorized electronic addresses-Receive and process search requests for whitelists-Manage and create blacklists for publicly available electronic addresses used for inappropriate purposes such as spam-Search functions for blacklists
  • Web portal management -Provide user interface related to address management-Provide system administrator interface related to address management-Manage system environment information of address directory server-Manage various statistical information related to address
  • the electronic document format register is a system provided by the electronic document distribution hub so that it can be automatically processed by using a standard electronic document previously promised between transmitting and receiving entities, or an electronic document in an e-form form can be utilized.
  • the electronic document form register provides a server engine that manages electronic document forms, an interface that provides a function for a distribution client to search and download, and a web portal interface.
  • FIG. 5 A functional conceptual diagram of the electronic document format register is shown in FIG. 5, and a description of the functions is given in Table 7 below.
  • the distribution relay server is a system in the electronic document distribution hub. When an error occurs in the electronic document distribution process between the sending and receiving entities in the distribution system, the distribution relay server substitutes the message for the transmitting entity.
  • the distribution relay server internally integrates the functions of the distribution messaging server, it not only provides basic electronic document transmission and reception services, but also connects services such as reception of relay requests only by the distribution relay server and transmission of error messages in the event of a final failure. Provided to distribution messaging server through interface.
  • FIG. 6 A functional conceptual diagram of the distribution relay server is shown in FIG. 6, and a description of the functions is shown in Table 8 below.
  • Table 8 number Function name Explanation One Message Routing Information Processing Routing function for distribution messaging server in sending / receiving object 2 Reprocessing in case of transmission error Function to handle resend when error occurs when sending message to receiving object 3 Send certificate Issuing certificate of transmission to sending entity requesting message transmission 4 Error message sent when transmission fails Sending error message to sending object when requested message transmission fails 5 Electronic document relay request Function to request message relay in connection with distribution messaging server 6 History / statistical information management Store and process history or statistical information related to message distribution 7 Relay Status Monitoring Provides relay relay status for sending / receiving object and relay status monitoring function by system administrator
  • Externally linked gateway server is a system that acts as a reliable path for linking external systems with existing distribution systems that are difficult to include or operate in the distribution system.
  • An external gateway server can be used as a channel for linking these systems. It can serve as a channel for linking with the public sector as well as other external systems.
  • FIG. 7 A functional conceptual diagram of an external linkage gateway server is shown in FIG. 7, and a description of the functions is shown in Table 9 below.
  • Table 9 number Function name Explanation One Distribution Messaging Server Module Use some of the features on the Distribution Messaging Server 2 Validation / Conversion Module Module to verify / convert corresponding to each external system to be linked 3 Electronic Address Verification / Translation Verification and translation function of sending and receiving address between distribution system and external linked system 4 Message package verification / conversion Verification and conversion function of message package between distribution system and external linkage system 5 Electronic document security verification / conversion Security verification and conversion function applied to electronic documents between distribution system and external linked system 6 Document Conformance Verification / Conversion Ability to verify the suitability of electronic documents between distribution systems and externally linked systems and to convert each other. 7 System administration System management of the external linkage gateway server 8 Statistical Information Inquiry Statistical information search function related to the use of external linkage gateway
  • the public electronic address consists of a combination of sharp [#], numeric [0-9], hyphen [-], and period [.].
  • the structure of the authorized electronic address is shown in Table 10 below.
  • the first part of "#” consists of a combination of letters [AZ] [az], Hangul [completed Hangul 2,350 characters], number [0-9], hyphen [-], and period [.].
  • additional user identifiers may be used.
  • the user addition identifier is self-managed by the electronic document distribution messaging server.
  • the user additional identifier of the authorized electronic address shall not start or end with a hyphen or period and shall be 30 bytes or less in length.
  • the user's additional identification code of the authorized electronic address shall not use social symbols, combinations of letters and numbers that harm the morals, and other restrictions set by the head of the management authority.
  • the public electronic address and the real physical address of the distribution message server have a relationship of 1: 1 or N: 1, and thus there is no case where one public electronic address has several physical addresses.
  • the entity shall be responsible for its own distribution by user additional identifier.
  • the sending / receiving entity shall prepare the policy and management method for user authentication corresponding to the user additional identification symbol, and should be thoroughly managed according to the method.
  • the sending and receiving entity should enter into a service level agreement (SLA) with the management authority, including the contents of the authorized electronic address including the internal identifier, before participating in the distribution system.
  • SLA service level agreement
  • the validity range of the authorized electronic address in the distribution system may be expressed as shown in FIG. 8.
  • the additional user identifier must be unique within the sending and receiving entity.
  • the method of assigning additional user identification symbols is based on the individual sending / receiving entity's responsibility.
  • the distribution of electronic documents by the user additional identification symbol is also the responsibility of the sending / receiving entity.
  • Such additional user identification symbols are not included in the scope of the distribution system, but may be defined by a service level agreement (SLA) with a management agency.
  • SLA service level agreement
  • the user additional identifier is used to distribute electronic documents for the convenience of the company, and is used only as information inside the company without registering in the address directory server.
  • the "ID” is composed of a combination of alphabets (or Korean numerals), hyphens [-] and periods [.],
  • the "separator” is #, and the "registrant” is English (or Korean, Number) and period [.].
  • Table 11 Component role Management Institution (Head of Certified Electronic Address Management) -Management authority manages the authorized electronic address information of the negotiated authority as the highest management authority of the authorized electronic address-Issue and change the unique public electronic address ID for the sending and receiving objects and authorized senders Registration agency -Organizations that apply for and review public electronic addresses with the authority of management authority Send and receive objects -The most basic unit of the authorized public e-mail address (registration address)-In the case of enterprises / institutions, issue, manage and guarantee uniqueness of user accounts or additional user identification symbols for multiple users under one public e-mail address.
  • Sender -Real users participating in the distribution of electronic documents have a publicly available electronic address with a user account opened through an electronic document relay, and are a sending and receiving unit that is legally responsible. Transmitting / receiving unit managed through User Add Identifier within, not legally responsible, not registered with e-mail directory server
  • the electronic document information package is required to support the automatic registration or processing of the electronic document in an enterprise internal system such as groupware by specifying metadata about the electronic document included in the message.
  • Electronic document information packages are not essential to the distribution of messages and can therefore be used selectively where they are needed for business purposes. However, when using the product, the following requirements must be observed.
  • the electronic document information package shall be transmitted in a file separate from the electronic document included in the message.
  • the metadata of the electronic document information package is shown in Table 12 below.
  • Electronic document type classification necessary Identifier distinguishing whether the electronic document is an electronic document registered in the electronic document form register, an electronic document used in an enterprise / institution, or an own electronic document 0: Electronic document in the electronic document form register 1 Commonly used electronic document2: Electronic document used by itself 4 Electronic document type identifier Select Identifier that identifies the type when the electronic document type distinction is 0 or 1 5 Electronic signature value Select Digital signature value for the electronic document 6 Other information Select Other information related to electronic documents
  • the security of the distributed message includes 1 non repudiation of transmission / reception, 2 guarantee of integrity of transmission message, 3 authentication of transmission party, and 4 security of transmission message.
  • 1, 2, 3 may be supported by the sender's digital signature for the transmission message, and 4 should be provided through encryption of the transmission message.
  • Security applied in the distribution of electronic documents between distribution messaging servers which are the most basic of the distribution system, supports message electronic signature and encryption as shown in FIG. In each section, network encryption should be applied for transmission security.
  • the digital signature on the content is a unique area for each application and is not mentioned in the description of the present invention.
  • the encryption of the receiver public key is basic, but if there is no certificate of the receiver or the receiver is an internal transceiver, only the receiver object encryption can be selected.
  • the authentication information is mainly used for the purpose of authenticating the client to the distribution messaging server.
  • the distribution messaging server may adopt various authentication methods such as ID / PW based, token information based on single sign on (SSO), in addition to certificate-based digital signature.
  • the distribution messaging server must be digitally signed based on its own certificate when connecting to other systems (other distribution messaging servers, address directory servers, distribution relay servers). All distribution messages for linkage between components in the distribution system should basically be digital signatures, but the digital signature between the distribution client and the distribution messaging server is optional and applies only to certificate-based user authentication. In this case, however, the distribution messaging server must take full responsibility for user authentication, integrity, and non-repudiation of transmission / reception of distribution messages with the distribution client.
  • Documents attached to the distribution system can be sent after the sender chooses encryption for security. This part is for confidentiality of documents and is different from network encryption, and even if network encryption is applied, the distribution document can be additionally encrypted.
  • the encrypted section may be from the distribution client of the sender to the distribution messaging server of the receiver or the distribution client of the sender to the distribution client of the receiver. If the receiver is an authorized sender / receiver and the public certificate is registered in the address directory server, encryption is performed in "2 sender to receiver” section. Otherwise, encryption is performed in "1 sender to receiver object” section. Is performed.
  • the sender When encrypting the attached document, if the sender is kept encrypted in the "1 sender to the receiving object" section, the sender can decrypt all three steps: the sender's distribution messaging server, the receiver's distribution messaging server, and the receiver's distribution client. It should be encrypted. If encryption is to be maintained in the section "2. From sender to receiver", the sender shall encrypt the sender's distribution messaging server and the receiver's distribution messaging server so that they can be decrypted.
  • the distribution messaging server of the sending object and the receiving object stores the attached electronic document in encrypted state for the history management.
  • the sender and receiver want to verify the distribution certificate based on the decrypted document, It should be possible. To this end, the distribution messaging server must continue to manage the private key and password for accessing the revoked certificate.
  • the ciphertext uses the Enveloped-Data Content Type represented by the ContentInfo structure presented in IETF RFC 3852 "Cryptographic Message Syntax" (CMS), which is used in various standards at home and abroad.
  • CMS Chromatometic Message Syntax
  • the IETF is the subject that defines the standards for Internet operating protocols such as TCP / IP.
  • the IETF is overseen by the Internet Architecture Board (IAB), the Internet Society's oversight body for the technological evolution of the Internet.
  • IETF members are selected from members of individuals or organizations of the Internet Society.
  • the standards produced by the IETF are represented in the form of RFCs, and many domestic and international PKI-based solutions (such as various certification systems, timestamps, and third-party archival standards) are based on these RFC standards documents.
  • CMS Cryptographic Message Syntax
  • the encryption targets of the delivered message are as follows.
  • Text and attached documents in the body of the message are each encrypted independently and stored in the location.
  • the first encryption target is the contents of the body to be delivered to the receiver, targeting the value in the ⁇ Text> item of the XML body.
  • Data complies with ASN.1 Basic Encoding Rules (BER) and ensures compliance with Distinguished Encoding Rules (DER).
  • BER Basic Encoding Rules
  • DER Distinguished Encoding Rules
  • MainText in Table 13 above is the text content.
  • Data to be encrypted after the second is an attached document attached from the third MIME, and is encrypted in each attachment document unit and then entered into the corresponding MIME.
  • AttachedDoc in Table 14 above is a binary attached document.
  • Table 15 below shows the composition of EnvelopedData of RFC 3852.
  • EnvelopedData SEQUENCE ⁇ version CMSversion, originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, recipientInfos RecipientInfos, encryptedContentInfo EncryptedContentInfo, unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL ⁇
  • iginatorInfo is not used because there is no need to send CRL without using key management algorithm. (As defined in RFC 3852)
  • the recipient can pass a content-encryption key through KeyTransRecipientInfo of RecipientInfos.
  • the main text or AttachedDoc is encrypted based on the algorithm of Algorithm Identifier.
  • EncryptedContentInfo SEQUENCE ⁇ contentType ContentType, contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier, encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL ⁇
  • ContentType contains id-data (identifier-OID-information that tells what the encrypted data is).
  • contentEncryptionAlgorithm contains information about the symmetric key algorithm used for the actual encryption.
  • the input of encryptedContent is OCTET STRING (Binary value) which encrypts the DER encoded value of TaxInvoicePackage defined above by the algorithm defined in contentEncryptionAlgorithm.
  • the object to be decrypted is the sending object and the receiving object, the receiver is possible only when there is a public certificate, so the actual RecipientInfos have at least two to three RecipientInfo.
  • the cryptographic certificate uses RSA, it should be configured using only ktri (sending a symmetric key that encrypts data using a partner RSA public key, etc.).
  • Object Identifier for message composition is as follows 1 and 2.
  • 1EnvelopedData Type RFC3852
  • ContentInfo The format that delivers actual data in CMS is a structure called ContentInfo, and it is information to put in ContentType to check what data is inside.
  • Table 18 -id-envelopedData- OBJECT IDENTIFIER ⁇ iso (1) member-body (2) us (840) rsadsi (113549) pkcs (1) pkcs7 (7) 3 ⁇
  • ContentType of EncryptedContentInfo Information that is put in ContentType to check what data is in the EncryptedContentInfo structure, which is a structure that puts encrypted data.
  • the public key algorithm uses the RSA based algorithm because the certificate used is a cryptographic certificate of the GPKI or NPKI scheme.
  • the symmetric key algorithm one of three symmetric key cryptographic algorithms (SEED, ARIA, 3DES) Should be chosen and used.
  • the sender may support only one of the three symmetric key encryption algorithms, but the receiver must support all three algorithms.
  • Asymmetric Key Algorithm It is used to securely transmit symmetric key information that is randomly generated and encrypts data to the other party.
  • An example is shown in Table 20 below.
  • the sender To generate the ciphertext, it is possible to obtain the certificate of the receiver side to decrypt the actual data.
  • the sender To obtain a certificate, the sender must obtain a certificate for the recipient (or recipient) in conjunction with the address directory server. At this time, the interval in which confidentiality is maintained depends on whether the acquired certificate is a certificate of a receiving object or a certificate of an authorized recipient.
  • the sender When the sender selects encryption for the transmission message, the sender performs encryption based on the obtained receiver (or receiving object) certificate and then sends the message to the receiver. Even if an error occurs during the message transmission process and a message is sent to the distribution relay hub, the encrypted content is transmitted without change.
  • FIG. 12 shows an encrypted text delivered to an actual receiver, and it will be possible to more accurately grasp the association of actual values.
  • -ContentInfo It is expressed in RFC 3852 and is a kind of container that puts SignedData, EnvelopedData, EncryptedData, etc., which are configuration data of RFC 3852.
  • the contentType of the structure indicates what information the content is. In this guideline, an identifier of id-envelopedData should be inserted.
  • EnvelopedData A structure for passing encrypted information (see the description in the previous section).
  • EncryptedContentInfo A structure that holds encrypted information.
  • the contentType of the structure indicates what information the encryptedContent is.
  • the identifier (id-data) should be inserted.
  • the contentEncryptionAlgorithm must put an identifier (OID) for one of SEED, ARIA, or 3DES, and puts data encrypted by the algorithm using OCTET STRING (binary data) using a randomly generated secret key in encryptedContent.
  • RecipientInfo This structure selects which method to use to decrypt the receiver. This guideline should use KeyTransRecipientInfo.
  • KeyTransRecipientInfo This structure is used to encrypt and deliver the random private key which encrypted above encryptedContent so that receiver can decrypt using receiver's public key.
  • Encrypted secret key is put in encryptedKey and includes RecipientIdentifier which is information about who used public key and KeyEncryptionAlgorithmIdentifier which is algorithm information used to encrypt secret key.
  • the receiver receiving the encrypted electronic document decrypts the encrypted body and the attached document according to the procedure described with reference to FIG. 12.
  • the recipient can obtain the plain text body and the attached document by decrypting the encrypted body and the attached document, respectively.
  • Step 1 Extract the EnvelopedData structure from the ciphertext and read it
  • Step 2 Extract the decryption information structure (RecipientInfo) from the EnvelopedData structure and obtain encrypted symmetric key information (KeyTransRecipientInfo) from the extracted decryption information structure.
  • RecipientInfo decryption information structure
  • KeyTransRecipientInfo encrypted symmetric key information
  • Step 3 The receiver decrypts the encryptedKey extracted from the encrypted symmetric key information with the receiver's private key (mapped with the certificate's public key) to obtain the symmetric key used to encrypt the body and the attached document.
  • Step 4 Get the encrypted structure of the body or attached document from the EnvelopedData structure extracted in step 1.
  • Step 5 Decrypt the encrypted text or attached document extracted in Step 4 using the symmetric key obtained in Step 3.
  • Step 6 Obtain the final decrypted text and attached documents.
  • Networks in all sections of the electronic document distribution (between the sender's distribution client and distribution messaging server, between the sender's and receiver's distribution messaging server, and the receiver's distribution messaging server and distribution client) for the confidentiality of messages distributed between the sender and receiver.
  • SSL Secure Sockets Layer
  • the message transceiving process is a process in which documents are exchanged with each other, such as mail or e-mail, in a form of directly sending and receiving messages between a sender and a receiver.
  • Table 22 number Process name Explanation One Obtain physical address and security information for the recipient ⁇
  • the sending object obtains this by requesting the address directory server for the physical address information and security information (if the receiving password for the outgoing message) to which the actual message should be delivered, based on the address information of the other party.
  • the address directory server checks whether the requesting public object's public electronic address is blacklisted or whitelisted (if it is on the blacklist, notifies the sending object of a message transmission error).
  • the sending entity packages the message according to the technical specifications and then performs the digital signature based on the public certificate of the distribution messaging server.
  • the distribution messaging server packages the message to the physical address obtained and sends the electronic signature message.
  • the distribution messaging server of the receiving object verifies the basic packaging structure of the message, the validity of the digital signature, and the suitability of the sender, and then generates a receipt certificate or an error message for acknowledgment.
  • the created receiving certificate is transmitted to the sending entity.
  • the distribution messaging server of the sending object receives the receiving certificate, 1) verifies the suitability of the receiving certificate, 2) attaches the verified information to the receiving certificate, and 3) the receiving certificate itself. Request for storage and storage to 3rd party archival organization 3 Acknowledgment of work recipient ⁇
  • the sender requests the certificate of reading of the receiving object at the time of message transmission, the receiving object generates and sends a reading certificate that can confirm the reading confirmation to the sending object at the time of reading the message.
  • the sending entity Upon transmission, the sending entity receives 1) verification of the validity of the reading certificate, 2) attaches the verified information to the reading certificate, 3) keeps the reading certificate in-house and asks the third party archiving agency, 4) receives it.
  • Send acknowledgment messages synchronously to the object 4 Issuance and Storage of Distribution Certificate ⁇
  • the sending entity receives the certificate for receiving, reading and sending according to each stage from the receiving entity or distribution relay server, and keeps it in the third-party storage institution. Secure grounds for proof
  • the message transmission / reception process can be divided into a transmission process and a reception process, and the transmission process is divided into synchronous transmission and asynchronous transmission by a linkage method between a distribution client and a distribution messaging server.
  • the synchronous message transmission and reception process when a distribution client of a sending entity requests transmission to a distribution messaging server, the synchronous message transmission and reception process is a real time transmission to the distribution messaging server of a receiving entity and a response is synchronously returned through the distribution messaging server of the sender. Synchronous processes can simplify the definition of business processes because the distribution client can immediately see the results of the transmission.
  • the asynchronous transmission process verifies only the validity of the transmission request to the distribution messaging server and returns an acknowledgment message for the request to the distribution client. This is a process of sending a real-time transmission to the distribution messaging server of the receiving entity and receiving a response synchronously through the distribution messaging server of the sending entity.
  • Asynchronous processes are used in situations where the client is unable to wait for a response because it takes a long time for the message to be sent, such as when the message to be sent is large or when multiple recipients are specified for a message.
  • the distribution client connects to the distribution messaging server and makes a request for receiving a message to get the message received from itself. ⁇ If there is a response message sent from the receiving object, the distribution client receives it as a response message. 5 Acknowledgment of work recipient ⁇ Same as above message sending / receiving process 6 Issuance and Storage of Distribution Certificate ⁇ Same as above message sending / receiving process
  • the process of receiving a message through the distribution client by the document receiver is shown in FIG.
  • the recipient's distribution messaging server receives the message from the sender, it sends a receipt in response to the message and puts the document in the final recipient's message box.
  • the distribution client requests the list of the received messages from the distribution messaging server from time to time, and if there is a newly received message, the distribution client receives the received message list as a response message, and gets the received document through the message requesting detailed information.
  • Table 25 number People Explanation One Receive a message ⁇
  • the receiving object When the receiving object receives a message, the receiving object returns a receiving response message for the received message to the sending object and keeps the received message in the user's mailbox. 2 Inbox List Get ⁇
  • the receiving client's distribution client authenticates with the associated distribution messaging server system and requests the receiving document.
  • the receiving object's distribution messaging server sends the list of received documents stored in the mailbox of the user who requested the receiving document to the distribution client in a synchronous response.
  • relay 3 Received Documents Get ⁇
  • the distribution client When the recipient requests to view the details of a message in the list of incoming messages, the distribution client requests the distribution messaging server system to deliver the details, including the attachment of the message.
  • the recipient's distribution messaging server system sends a message containing the reading certificate to the sender of the message when the user requests detailed information on the received document.
  • a reading certificate should be generated and delivered to the sender's distribution messaging server.
  • the receiving distribution messaging server delivers the decryption error message to the sender instead of the reading certificate.
  • the sending entity participating in the distribution system must know the physical real address information based on the public electronic address information before sending the message to the other party. Additionally, in order to encrypt the attached document, the recipient's disclosure in the address directory server is required. The key information must be obtained.
  • the procedure for acquiring the physical address of the public electronic address is an essential step, as described below.
  • the sending object queries the address directory server to obtain the physical address information and security information of the receiving object based on the address information of the receiving object.
  • the address directory server processes the query after receiving / verifying the query of the sending object.
  • the sender sends a message to the receiver by setting a route based on the received physical address.
  • the distribution messaging server of the receiving object receives it and distributes the message internally according to user account or internal delimiter.
  • the physical address of the authorized electronic address in the distribution system can be classified into two types, as shown below 1 and 2.
  • the distribution client When the distribution client enters the recipient's address information, it makes a request to the address directory server to get the physical address and the recipient's public key: 1) To check the validity of the certified electronic address in advance, 2) The distribution client Message encryption between the server and the distribution messaging server (sending object)
  • distribution messaging server gets physical address from address directory server
  • 19 is a process of acquiring the physical address and security information of the authorized electronic address.
  • the distribution system is based on direct communication (P2P) between the transmitting and receiving objects.
  • P2P direct communication
  • a relay process for relaying / representing the distribution is provided for the user's convenience and smooth support of the distribution.
  • the distribution relay server in the electronic document distribution hub proves the transmission object by entrusting / transmitting the message on behalf of the sending object. It reduces the system burden on the sending entity.
  • FIG. 23 is A basic flow is presented, and FIG. 24 shows a process in which a distribution relay server relays a message.
  • Table 26 below illustrates the distribution relay process step by step.
  • the sender sends a message to the receiver after packaging and securing the message.
  • the received distribution relay server synchronously issues and transmits a certificate to the sender.
  • Message consignment relay ⁇
  • Distribution relay server sends a message that has been relayed. If transmission fails, retries are attempted at regular intervals (the number of retries and the interval is determined according to the policy of the distribution relay server). Passing 3 Receive and read certificate ⁇ After the receiving object has received the message normally, the receiving certificate is sent to the distribution relay server. ⁇ After the recipient has read the electronic document, the receiving object sends the reading certificate directly to the sending object without passing through the distribution relay server.
  • a distribution certificate must be generated and stored in a third party repository. This is because the distribution certificate containing the distribution evidence can be stored in a legally recognized third-party storage institution, thereby obtaining legal estimation of the distribution fact.
  • the process of storing distribution certificates is a separate process from the distribution of electronic documents, and it is a supporting process to prove the fact of distribution.
  • all distribution messaging servers must be subscribed to a specific third party archiving agency with the ability to receive and store distribution certificates in advance.
  • the entire message may be stored in a third-party storage institution in addition to the distribution certificate.
  • Distribution messaging server of 3rd party custodian agency System that is required to send and receive distribution messaging with distribution messaging server in distribution system
  • Third party storage organization linked client module Module for communicating with the third party storage organization linked interface to store the distribution certificate received through the distribution messaging server of the third party storage institution.
  • a distribution messaging server may not be additionally required.
  • FIG. 28 illustrates a process of storing a distribution certificate between a transmitting and receiving entity and a third party storage institution operator.
  • the process of storing the distribution certificate is shown in Table 27 below.
  • the sender's distribution messaging server receives the distribution certificate from the recipient's distribution messaging server. ⁇ If the receiving certificate is received from the receiving distribution messaging server or if the receiving certificate is received from the relay hub, the distribution certificate is received by the response message. If you receive a certificate of receipt through a relay hub or receive a distribution certificate by request message 2 -If the validity of the received distribution certificate is verified, the distribution certificate and certificate verification information are transmitted to the distribution messaging server of the pre-set third-party archiving organization. Request for retransmission by notifying the verification error message ⁇ If the distribution certificate is received as a request message, send the verification error message as a response message (synchronous) ⁇ If the distribution certificate is received as the response message, send the verification error message with a new request message.
  • the public electronic address information management process includes a management process for registration, modification, and deletion associated with the public electronic address, and a blacklist / white list management process.
  • the management agency manages the authorized electronic address by setting up a certified electronic address registration agency for efficient management of the authorized electronic address.
  • the registration agency performs the following tasks: 1 to 4.
  • the management agency may select a third party archiving agency and an electronic document relay who satisfy the requirements as the registrar.
  • the information related to the registered official electronic address may be changed for various reasons, but the official electronic address and the owner information cannot be changed because they must maintain the same identity.
  • the authority to change information related to the public electronic address should be delegated to the registrar. However, historical information on the change of information should be kept in accordance with the service level agreement (SLA) between the management agency and the registrar.
  • SLA service level agreement
  • a related process is the same as that of FIG. 23, and referring to FIG. 23, only the authorized electronic address can be changed.
  • the public electronic address, registration number, and name cannot be changed, so the public electronic address must be withdrawn and newly created.
  • the authorized electronic address cannot be changed, and the registration number (business registration number) and the business name must be changed with the new official certificate received after being changed with the corresponding information.
  • the address directory server should be able to request temporary suspension of public electronic addresses.
  • the address directory server allows the user to select a temporary suspension of the official electronic address when leaving the public electronic address, thereby maintaining the official electronic address for a certain period of time when the registrar is changed.
  • the registered registered electronic address must be updated in accordance with the established service life. After registration of the public electronic address, the owner must renew before the expiration date set in accordance with the service policy. If the owner does not renew, the ownership of the public electronic address is lost and the public electronic address is automatically erased.
  • This process is to increase the utilization of the post-message distribution step.
  • This is to process the electronic documents contained in the message in an automatic or semi-automated manner in the corporate internal system.
  • the distribution messaging server is dedicated to sending and receiving messages between the parties, and the distribution client provides an interface for the sender and the receiver to easily send and receive messages.
  • the next step is to utilize the electronic document in the message.
  • the electronic document form register or electronic document form provides a method for more efficient operation of the electronic document utilization step.
  • This additional function introduces the electronic document exchange (EDI) function, which can automatically convert the electronic document received from the internal system of the receiving object by transmitting and receiving document data based on the promised electronic document format between the transmitting and receiving objects. It was.
  • EDI electronic document exchange
  • the form of the electronic document can be used in two ways as follows.
  • the enterprise, institution or individual user can retrieve the electronic document form registered in the electronic document form register, and then register and use it in the distribution client. There are two ways to use the electronic document format register as follows 1 and 2.
  • the electronic document is retrieved from the electronic document form register site, downloaded to the local PC, and registered and used in the distribution client.
  • the management institution should operate / manage systematically to have the following criteria.
  • Table 28 division Explanation Remarks area Distinguish whether the electronic document can be distributed internationally, in a specific region, or only in a specific country Sphere door Whether the syntax applied to the electronic document is EDIFACT based, XML based, or private format industry Used when the electronic document only applies to specific industries. For example, whether a purchase order is used in the trade sector or in the manufacturing, distribution, and logistics sectors. product
  • the electronic document uses a specific company product format. Whether it is in PDF format or a specific company e-Form format Enterprise Distinguish when the electronic document is only available to certain companies Other If it can be divided into other contexts (contexts) other than the above
  • FIG. 25 illustrates a basic flow of a process for utilizing an electronic document format register. Specifically, FIG. 25A illustrates a case in which an electronic document format register and a distribution client are directly connected. FIG. 25B shows an electronic document format register site. The case of using is shown.
  • Table 29 below describes the process of using forms in direct connection with distribution clients.
  • Table 29 Number division Explanation One Electronic Document Format Search Retrieve electronic document forms from the electronic document form register directly from the distribution client 2 Get Format If a form is found, import it to the distribution client 3 Form registration Registering a form imported into a distribution client with a distribution client 4 Import / Create Electronic Document Formats Import an electronic document form registered in a distribution client, create an electronic document, and attach it to a message
  • Table 30 below shows the process for using the Electronic Document Format Register site.
  • the purpose is to distribute the tasting at the site operated by the company, etc., for the purpose of doing business with the parties related to the particular company.
  • FIG. 26 illustrates a procedure using an agreed electronic document format, and a description of the process associated with FIG. 26 is given in Table 31 below.
  • Table 31 Number division Explanation One Electronic document template distribution Entity A distributes electronic document forms that can be handled by its system on its own website, allowing them to use them in their businesses. 2 Save Form to Local PC Enterprise B2 downloads form from website and saves it to local PC 3 Form registration Register the form stored on the local PC to the distribution client of Entity B 4 Import / Create Electronic Document Formats Import an electronic document form registered in a distribution client, create an electronic document, and attach it to a message 5 Send message Send messages through distribution messaging server 6 Automatic / semi-automatic processing of attached electronic documents Register the electronic document attached to the received message automatically or semi-automatically in the company A's internal system by converting
  • the sender transmits through the authorized distribution messaging server, and the receiver also receives through it. Therefore, the sender has an infrastructure to hold the sender accountable when spam is sent.
  • the distribution system provides a system that can manage the white list based on the certification list management, the black list with spam or malicious intention, and enhance the safety and reliability of the distribution system. .
  • the function to report spam message and to check the sending party is an essential function. All distribution messaging servers must build this function.
  • the address directory server that received the spam message report from the distribution messaging server returns a confirmation message that it was received.
  • the authority that manages the address directory server analyzes the message and examines the sender to examine and determine whether to add a blacklist for the sender's public electronic address.
  • the address directory server adds the public electronic address to the blacklist and notifies the sender of the blacklist addition.
  • the address directory server forwards the results of the spam message request to the spam reporter (recipient).
  • the receiver determines that the received message is a spam message, the receiver reports the spam message to the address directory server by the process shown in FIG. 27.
  • Blacklist If the sender's address is registered as a spammer, it is registered as a blacklist.
  • the management agency may decide to cancel the authentication of the distribution message server, and then cancel the authentication and delete it from the whitelist.
  • the receiving entity When the receiving entity receives the message, the receiving entity checks the whitelist and the blacklist of the address directory server to confirm whether the sending party is a reliable and legitimate user, and then decides whether to reject the receiving party.
  • the sender can be checked at the time of reception by checking 1 in real time or by checking the list managed in the form of cache in the distribution messaging server system of the receiver.
  • Real-time confirmation process At the time of receiving a message, the receiving object determines whether the address of the sending object is registered in the whitelist or blacklist in the address directory server and then decides whether to reject the message.
  • Table 33 number People One When the recipient's distribution messaging server receives the message, it sends an acknowledgment message to the address directory server to verify that it is a legitimate user. 2 The address directory server checks whether the address information of the requested user is included in the whitelist. 3 If the address is not on the whitelist, the address directory server immediately returns a result message indicating that the user is not registered to the verification requester. 4 The address directory server returns a result message for the blacklist registration to the verification requester. 5 If the receiver receives the result message from the address directory server as the sender is not a legitimate user (when it is not in the whitelist or is registered in the blacklist), the recipient processes the received message as a spam message and then receives the processing result message received from the address directory server. Record and keep track of spam messages 6 The processing history of spam messages must be kept for more than a month to confirm the validity of the rejection of the sender.
  • Periodic verification process Recipient receives periodic whitelist and blacklist from address directory server and manages itself and based on this, determines whether sender's address is registered in whitelist and blacklist, and then decides whether to reject the message.
  • Table 34 number People One Distribution messaging server of receiving object requests the latest whitelist and blacklist from address directory server in advance and manages itself. At this time, when the change of the list occurs, the automatic notification request is delivered together. (Even when the automatic change notification is requested, the request for bringing the latest list to the address directory server is periodically performed so that the list information does not differ more than 1 day. box) 2
  • the address directory server broadcasts the change to the user who requested the change notification when the change occurs in the whitelist and blacklist.
  • the distribution messaging server receiving the change of the list synchronizes by modifying the information of the self-managed list. 4 When a recipient receives a message, it checks its own managed list to determine whether the user is a legitimate user on the address directory server.
  • the receiver determines that the sender is not a legitimate user (when it is not in the white list or is registered in the black list) as a result of the self-managed list check, the receiver processes the received message as a spam message and records and archives the spam message receiving history. 6 The processing history of spam messages must be kept for more than a month so that the validity of the rejection of the sender can be verified.
  • 29 shows a process for periodically checking for managing spam messages between a distribution messaging server and an address directory server.
  • All errors for synchronous transmissions are based on retransmissions, since the sender can see them immediately.
  • the retransmission method is determined by the system policy of the company or organization participating in the distribution system, but for the same message transmission, the same messageId value is set and resent.
  • Types related to synchronous error handling are as follows 1 to 4.
  • Request message transmission failure When the sender transmits a message and a transmission error occurs, the request message cannot be delivered to the receiver. The sender recognizes the transmission failure through a timeout or network error message for the transmission attempt. .
  • 3rd stage synchronous error The distribution of messages between three entities linked to other distribution messaging servers, address directory servers and distribution relay hubs through distribution messaging servers is synchronously linked to immediately confirm the final result among the types of associations. Support the way. In the process, if an error occurs in the linkage step between the distribution messaging server and the receiver, the distribution messaging server immediately generates an error and then delivers it to the distribution messaging server as a response message.
  • the distribution of messages between three distribution clients connected to other distribution messaging servers, address directory servers, and distribution relay servers through distribution messaging servers also supports asynchronous connection so that distribution clients can operate independently of the final recipient's situation. do.
  • the final error for the asynchronous transmission cannot be immediately confirmed by the sender. Therefore, an error message for the distribution client should be generated when the distribution messaging server finally confirms the error, and the distribution client can receive it.
  • the electronic document reading service is a service that provides access to electronic documents stored in the sender's system or a third-party archival institution, rather than an exchange of electronic documents directly between the sender and the receiver.
  • the electronic document reading service uses the existing distribution system. However, the sender does not transmit the message containing the electronic document to the receiver, but transmits the message containing the right to view the electronic document stored in the sender system or the third-party archive.
  • the electronic document reading service can be divided into a method of using a sender using its own system and a method of using a third party.
  • FIG. 30 illustrates a flow of a sender using an electronic document reading service by using a system of his own. The procedure described in FIG. 30 is described in Table 35 below.
  • the sender should have a system that can provide the electronic document reading service in addition to the distribution system.
  • FIG. 31 illustrates a flow in which a transmitting entity uses an electronic document reading service by using a third party.
  • the procedure shown in FIG. 31 is described in Table 36 below.
  • Table 36 number People Explanation One Obtain public key of incoming object certificate Obtain the public key of the receiving object certificate from the address directory server when creating the e-mail viewing authority 2 Request for electronic document storage and reading service 2 Request for electronic document storage and reading service The sending entity keeps and requests an electronic document to a third-party archiving agency and requests a reading service for it. 3 Create a certificate with security rights such as access rights and DRM Create a certificate that applies security such as DRM and a security certificate such as DRM to view the electronic document 4 Send Certificate of Reading Authority Send the certificate to the receiving entity, including the right to view third-party custody. 5 Electronic document reading Recipients of the receiving entity have access to view third-party documents by accessing third-party archives.
  • Certificate of Distribution If the recipient of the third-party archival recipient receives the electronic document, a distribution certificate is created and stored. 7 Send Certificate of Distribution (Reading) In addition, the certificate of distribution (reading) is transmitted to the sending entity who requested the third-party archiving service.
  • the electronic document distribution system based on the authorized electronic address may be linked to the inside of the company / institution in the following ways.
  • the interworking method with the internal system is mainly used when a distribution messaging server is installed in a company or an institution.
  • the distribution client is developed as a system integration (SI) form in the internal system.
  • SI system integration
  • the method that does not interwork with the internal system is mainly suitable for the authorized sender who uses a user account issued by the electronic document relay, and is a distribution client application that is distributed by the electronic document relay using a web distribution client provided by the electronic document relay. Is installed on the local PC and used for details, see Table 39 below.
  • the web method is a web method that users access and process, so that individual users do not need to install a program on their local PC.
  • the individual user downloads the installation program, installs the program on the local PC, and connects to the distribution messaging server.
  • the distribution system has a distribution network based on its own system and the Internet. Electronic document distribution may be limited because it is only within the distribution system.
  • the distribution system has an external gateway server for the distribution of electronic documents with systems that are not directly connected.
  • FIG. 32 A basic conceptual diagram of an external linkage gateway server is shown in FIG. 32.
  • the external linkage gateway server acts as an intermediate waypoint.
  • One side has a distribution messaging server for the distribution system, and the other side has its own adapters for linking with external systems.
  • the business component is an agreement between the parties regarding the procedures, methods, etc. related to the linkage, and the management body and the external linked system management body shall enter into a service level agreement (SLA).
  • SLA service level agreement
  • Technical elements refer to technical elements related to user authentication, messaging, and message format necessary for the connection.
  • the sender shall write the stopover address and the final destination address.
  • the sender shall provide user information so that external system can authenticate the sender. If you have previously subscribed to an external system, you can use the authentication identifier of the external system.
  • the received message should be disassembled and assembled into the message suitable for external system.
  • External system linked with distribution system can be added or changed. Information on the external system is managed by the address directory server, and the distribution messaging server should query and process the address directory server if necessary.
  • a common basic communication protocol and a message exchange method are first defined, and a message structure for each link type is defined and presented as a standard.
  • the present invention is constructed by different environments and development methods. Linkages between components can be facilitated and interoperable.
  • the distribution linkage message is based on the "ebXML Message Services v2.0 specification" (hereinafter ebMS). It is defined as a more general form by extending it hierarchically.
  • the ebXML infrastructure consists of independent but closely related elements such as SOAP, SOAP with Attachment, Security, and Reliability.
  • the "Based Communication Protocol for Linkage” (hereinafter referred to as “Based Communication Protocol”) is based on these basic elements and defines the necessary elements in the distribution system and consists of an organic recombination form.
  • the underlying communication protocol consists of packaging that composes the message to be transmitted, message envelope construction, message security, and message transmission and reception, which finally transmits and receives the message.
  • the entire message structure of the distribution-related message complies with the ebMS v2.0 specification.
  • the message defined in this base communication protocol has two logical MIME parts.
  • the first MIME part contains a SOAP message, which in turn consists of a header and a body.
  • payload containers From the second MIME part, called payload containers, it contains application-level messages and attached documents.
  • This area describes common information for message distribution (such as message routing-related information, SOAP message exchange patterns, digital signatures, error information, and location information for second attached data).
  • the second MIME part attaches request and response messages for each interfacing interface, and the existence of the MIME part after the third is determined by the type of the interfacing interface. When delivering electronic documents or certificates using the distribution system, they are included in the third MIME part.
  • FIG. 34 The basic structure of the distribution association message is shown in FIG. 34.
  • 1 "SOAP-ENV: Header” is configured according to the distribution protocol standard, and consists of MesageHeader and Signature information.
  • 2 "SOAP-ENV: BODY” is distribution. Mainfest element information and user login information defined in the protocol specification are included.
  • 3 "Transport container # 1 (payload container # 1)” is a part including request message and response message. The details of the business document are defined according to the error message, and 4 "Transport Container # 2 (Payload Container # 2)" includes documents to be attached sequentially from Payload Container # 2 according to the type of the associated interface.
  • all MIME Header elements of the distribution association message must conform to the SOAP Messages with Attachments specification.
  • the Content-Type MIME Header in the message MUST have the same type attribute as the MIME media type of the MIME Body part containing the SOAP message document.
  • a MIME type of a SOAP message must have a value of "text / xml".
  • the root part shall contain a Content-ID MIME Header with a structure conforming to [RFC2045] and in addition to the required parameters for the Multipart / Related media type, a start parameter (optional in [RFC2387]) must always be present.
  • An example MIME Header of a multipart / related message package is shown in Table 40 below.
  • the first MIME Part header container must contain a SOAP message.
  • the MIME Content-Type header of the header container shall have the value "text / xml" according to the SOAP specification.
  • the Content-Type header must include a "charset" attribute. An example is shown in Table 41 below.
  • the MIME charset attribute is then used to identify the character family used to generate the SOAP message.
  • the encoding declaration of the MIME charset attribute value and the SOAP message located in the header container must match and its value must be UTF-8.
  • An example of a header container is shown in Table 42 below.
  • the number of payload containers may vary depending on the type of associated interface.
  • Each payload container must be referenced by a Manifest element in the SOAP Body according to the ebMS specification. Examples are shown in Table 43 below.
  • MIME headers may be added for convenience of implementation.
  • the added MIME Header must be an item specified in [RFC2045].
  • the additional MIME header does not need to be recognized and interpreted by the side not added.
  • extension element content must be restricted to a valid namespace.
  • All ebXML SOAP extension element contents defined in the present invention should be limited to the ebXML SOAP Envelope extension namespace.
  • Namespace declarations may be included in SOAP Envelop, Header, or Body elements, or may be included directly in each SOAP extension element.
  • SOAP Envelop is a root item of SOAP message and declares various namespaces in SOAP message.
  • the namespace to be declared is as follows.
  • the message envelope schema structure is shown in FIG. 35, and an example message envelope is shown in Table 45 below.
  • the SOAP Header element is the first child element of the SOAP Envelop element and includes extension elements such as the following 1 to 4.
  • MessageHeader Required element including routing information (To / From, etc.) of message and other context information about message.
  • ErrorList An element that contains the error history when returning an error message due to an error in processing a message such as message syntax verification, message digital signature verification, etc.
  • the SOAP Body element is the second child element of the SOAP Envelope element and contains an extension element such as Manifest.
  • Manifests are elements that point to data located elsewhere, such as a payload container or the web.
  • the manifest element must exist to refer to the payload container.
  • the manifest element is a composite of one or more reference elements. Each Reference element identifies data related to the message, either a remote resource that is included as part of the payload document (s) contained in the payload container or is accessible by a URL. It is recommended not to load payload data in the SOAP Body.
  • the purpose of the manifest is as follows 1 and 2.
  • Manifest element is composed of the following attributes and elements.
  • Reference element is a complex element composed of sub elements such as 1 to 2 below.
  • Schema elements Information about the schema (s) defining the instance document identified in the parent Reference element.
  • Description elements A description of the payload object referenced by the parent reference element.
  • the Reference element is itself a simple link to [XLINK].
  • XLINK is currently the W3C Candidate Recommendation (CR). Note that the use of XLINK is provided here as a term to clarify the association. The use of an XLINK processor or engine is not essential, but may be useful depending on your implementation requirements.
  • the Reference element contains the contents of the following attributes 1 through 5.
  • Xlink-type This attribute defines an element as an XLINK simple link. It has a fixed value of "simple"
  • Xlink href: This required attribute is the URI value of the referenced payload object. This should be based on a simple link in the [XLINK] specification.
  • Xlink role: This attribute identifies the payload object or resource that describes its purpose. If present, it must have a valid URI value per the [XLINK] specification.
  • the receiving MSH can ignore external namespace attributes in addition to those defined above.
  • Schema element must exist as a child of a Reference element if the referenced item has a schema (s) describing it (eg, XML Schema, DTD, or Database Schema). It is used to identify the schema and version, and defines the payload object identified by the parent Reference element.
  • Schema elements have the following attributes: 1 and 2.
  • the MIME with that content-id must be represented in the message's payload container. Otherwise, an error with errorCode as MimeProblem and severity as Error should be sent to the calling party. If the xml: href attribute does not contain a URI with a content id (URI scheme "cid"), the URI will not be interpreted and the implementation must decide whether or not to forward an error. If it is determined that an error should be delivered, an error with errorCode as MimeProblem and severity as Error should be sent to the calling party.
  • Table 46 shows the mainfest of a message with a typical payload MIME Body part.
  • the MessageHeader element is a mandatory element that must be present in every ebXML message and must be expressed as a child element of the SOAP Header element.
  • the MessageHeader element is a composite element consisting of the following subelements.
  • the schema structure of the MessageHeader is shown in FIG. 36.
  • the MessageHeader item code table is shown in Table 48 below, and the Service / Action items for each task are shown in Table 49 below.
  • SyncReply means synchronous transmission and has the following 1 to 4 attributes.
  • Distribution-linked messages must be electronically signed to counter the various risks that can occur during transmission and reception. Therefore, Signature element must exist as child element of SOAP Header.
  • the subject of digital signatures in distribution-related messages are the entire SOAP message and the messages and attachments contained in the payload container.
  • Each signature subject information is digested and included in the digital signature information, respectively.
  • the number of payload containers is repeatedly described.
  • the URI value describes the content ID value defined in the MIME Header of the attached document. (Digest target is Content part except Mime Header)
  • SignatureValue of SignedInfo is calculated based on the algorithm specified in SignedInfo as specified in [XMLDSIG].
  • the algorithm information used in the digital signature is as follows.
  • the algorithm basically follows the algorithm part (6.0 Algorithms) of W3C “XML-Signature Syntax and Processing” (RFC3275). It also uses the algorithm defined in TTAS.IF-RFC3075 "Extensibility Generation Language Digital Signature Syntax and Processing” (Korea Information and Communication Technology Association, 2004).
  • Algorithms used in message digital signatures conform to the relevant provisions of accredited certification schemes.
  • Algorithm that processes and selects the data that is actually signed from the entire XML data. There are various conversion algorithms, but only three of them are used. The first is the Enveloped Signature transformation because the digital signature follows the format contained within the signature subject, the second is the canonicalization described above, and the third is XPath Filtering to select the signature subject information.
  • the structure of the digital signature syntax is shown in FIG. 37, and an example of the digitally signed message is shown in Table 57 below.
  • ErrorList element should be created under Header and returned synchronously to sender when error occurs during communication protocol processing such as message syntax verification, message digital signature verification.
  • RefToMessageId must exist in the MessageHeader element and RefToMessageId must refer to the MessageId of the message in which the error has occurred.
  • the ErrorList element has the following attributes: 1 to 5.
  • the ErrorList element MUST NOT exist unless there are errors to be reported.
  • the structure of the ErrorList is as shown in FIG.
  • the highestSeverity attribute indicates the most severe state of all Error elements. In particular, if an Error element has severity set to Error, highestSeverity must be set to Error, otherwise highestSeverity must be set to Warning.
  • the Error element has the following attributes: 1 through 6.
  • the id attribute uniquely identifies the ErrorList element in the document.
  • the codeContext attribute represents the namespace or schema of errorCodes. It must be a URI.
  • the default value of this property is urn: oasis: names: tc: ebxml-msg: service: errors. If there is no default value for this attribute, the implementation of the specification indicates that it uses errorCodes.
  • the required errorCode attribute indicates the nature of the error in the message that contains the error.
  • the severity attribute which is a required attribute, indicates the severity of the error. Valid values are the same as Warning and Error. Warning indicates that an error exists but other messages in the conversation are being generated normally. Error indicates that an unrecoverable error exists in the message and no other messages are generated during the conversation.
  • the location attribute points to the message part where the error exists. If the error is in an ebXML element and the element is "well-formed" then the location attribute's content must be [Xpointer].
  • the content of the Description element provides a descriptive description of the error in the language defined by the xml: lang attribute. Usually this is a message generated by the XML parser or software that validates the message. This means that the content is defined by the vendor or developer of the software that created the Error element.
  • ErrorList is shown in Table 58 below.
  • Errors to report include message structure errors, messaging errors, and security errors.
  • Errors related to data communication protocols such as HTTP and Socket belonging to a lower layer than the distribution protocol defined in the present invention should be found and reported by a standard mechanism supported by the data communication protocol, and use the error reporting mechanism defined in the present invention. I never do that.
  • Error codes are classified by error object and type. Details are shown in Table 59 below.
  • HTTP response code defined in [RFC2616] should be used.
  • the main response codes are shown in Table 61 below.
  • the transmission between all distribution messaging servers and distribution message servers in the distribution system or between distribution messaging servers and distribution clients must use HTTP / S (Secure Hypertext Transfer Protocol) using Secure Socket Layer (SSL) V3.0 for network transmission security. Should be used.
  • HTTP / S Secure Hypertext Transfer Protocol
  • SSL Secure Socket Layer
  • an error occurrence type is largely divided into an error occurrence for a synchronous response and an error occurrence for an asynchronous response.
  • the distribution of all messages between two entities between a distribution messaging server, another distribution messaging server, an address directory server, a distribution client and a distribution relay server is a synchronous distribution.
  • the distribution of messages between three entities in which a distribution client is connected to another distribution messaging server, an address directory server, and a distribution relay server through a distribution messaging server may be linked in a synchronous or asynchronous manner depending on the type of connection.
  • All errors for synchronous transmissions are based on retransmissions, since the sender can see them immediately.
  • the retransmission method is determined according to the policy of the system of the company or organization participating in the distribution system, but the same message transmission is set by sending the same MessageId value again.
  • the same request is detected by detecting the receipt of duplicate messages even when the error in the message transmission process is not an error at the time of transmission but in the case of the receiver sending a response message synchronously after successful reception. Prevent duplicate processing.
  • the sender and receiver of a synchronous error can be a distribution messaging server, an address directory server, a distribution client, or a distribution relay server, depending on the type of association.
  • Request message transmission failure When the sender transmits a message and a transmission error occurs, the request message cannot be delivered to the receiver. . 39 shows a process when a request message transmission fails, the processing procedure is as follows 1) to 3).
  • a transmission error occurs during the message sender's transmission. Many cases are caused by a network error.
  • the sender recognizes the transmission failure error and retransmits the same message to the receiver with the same MessageId.
  • the receiver If the receiver receives the same message as the previous received message, the receiver sends an acknowledgment message with duplicate reception and internal processing.
  • FIG. 41 illustrates a process related to error message reception, and processing procedures are as follows 1) to 3).
  • 3rd stage synchronous error Distribution of messages between 3 entities linked to other distribution messaging server, address directory server and distribution relay server through distribution messaging server is synchronously linked to confirm the final result among the types of linkage. Support the room. If an error occurs in the linkage step between the distribution messaging server and the receiver during this process, the distribution messaging server should immediately generate an error and deliver it to the distribution messaging server as a response message. 42 illustrates a process related to a three-phase synchronous error, and processing procedures are as follows 1) to 3).
  • the error refers to the case where all errors occur in the synchronous transmission between the distribution messaging server and the receiver.
  • the distribution messaging server generates an error message for the distribution client when the error is recognized and delivers it to the distribution client as a response message.
  • the error message generated by the distribution messaging server is structured as shown in Table 62 below.
  • the distribution of messages between the three entities that the distribution client connects with other distribution messaging servers, address directory servers, and distribution relay servers through the distribution messaging server is an asynchronous method so that the distribution client user can operate independently of the situation of the end receiver. It also supports linkage.
  • the final error of the asynchronous transmission cannot be immediately confirmed by the sender, so that the distribution messaging server generates an error message for the distribution client at the time when the distribution messaging server finally confirms the error, so that the distribution client can receive it.
  • the error refers to the case where all errors occur in the synchronous transmission between the distribution messaging server and the receiver.
  • the distribution messaging server generates an error message for the distribution client and finally delivers it to the distribution client's inbox after retrying.
  • the distribution client recognizes an error about a previous request message through an error message received in its inbox at the step of requesting a reception message from a distribution messaging server.
  • the error message generated by the distribution messaging server is structured as shown in Table 63 below.
  • the address directory server is a system that manages the official electronic address information, which is the most basic element in the distribution system.
  • the interface between the distributed messaging server and the address directory server is divided into two main functions.
  • the first is an interface related to work such as registration of a public electronic address with a registrar
  • the second is an interface related to work such as physical address query / response and spam report with a distribution messaging server.
  • Interfaces related to business such as registration of authorized electronic addresses with the above registrars can be distinguished separately, but since the registrar is done by an electronic document relay or a third-party archival agency, an interface function is inserted into the distribution messaging server.
  • the distribution messaging server installed in the transmitting / receiving entity does not include the associated interface related to the registration of the public electronic address.
  • Table 64 shows the interface functions between the distributed messaging server and the address directory server.
  • Requestor is an electronic document relay Change of authorized electronic address information ⁇ Interface that receives the result after requesting the change to the address directory server in case of a change in the public information (ex: security information, ID) Delete public e-mail address ⁇ Address The interface that receives the result after requesting deletion to the address directory server when the public electronic address registered in the directory server is no longer used.
  • Address search retrieve physical address information ⁇ Interface that requests the user's security information (certificate certificate) and physical address information corresponding to the public electronic address information from the directory server and receives the result
  • the requestor is an entity sending and receiving with the electronic document relay Blacklist management Report Spam
  • the interface that reports the spam message to the address directory server and receives it as a result.
  • the address directory server sends the final message on whether the message is reported as spam or not to the sender and the spammer. Notified using Notification White list notification ⁇ Interface that whitelists the address directory server to send / receive objects Blacklist notification ⁇ Interface that blacklists address directory server to send / receive object
  • the digital signature information of the sending object must be included and transmitted.
  • the address directory server is used to perform the digital signature of the SOAP message. Additional sender information (CorpNum, RValue) required to verify that the owner of the certificate matches the corresponding sender (VID verification) must also be included and conveyed.
  • the information of additional sending objects shall be located as an extension element (any ## other position) under the MessageHeader element in the SOAP message of the request message.
  • the extended element structure is shown in Table 65 below, and an example of extended elements is shown in Table 66 below.
  • the SOAP message is located in the first MIME part of the message, and the distribution message for the corresponding request and response is located in the second MIME part.
  • the SOAP structure between the distributed messaging server and the address directory server is shown in FIG. 44.
  • the request distribution message structure is shown in Table 67 below, and an example message is shown in Table 68 below.
  • the response distribution message structure is shown in Table 69 below, and an example message is shown in Table 70 below.
  • the public e-mail address change interface is an interface where an electronic document relay requests a change of the public e-mail address information of the authorized sender and receiver registered in the address directory server and receives a response. After the transmission, the result of the change processing of the address directory server is received as a response message.
  • the message exchange flow associated with the authorized electronic address information change processing is illustrated in FIG. 46.
  • the request distribution message structure is shown in Table 71 below, and an example message is shown in Table 72 below.
  • the response distribution message structure is shown in Table 73 below, and an example message is shown in Table 74 below.
  • the public electronic address deletion interface is an interface where an electronic document relay requests a deletion of the public electronic address information of the public electronic address information of the authorized sender and receiver registered in the address directory server and receives a response. Is included in the request message and transmitted, and the result of the deletion process of the address directory server is received in the response message.
  • the message exchange flow associated with the public electronic address deletion process is illustrated in FIG. 47.
  • the request distribution message structure is shown in Table 75 below and an example message is shown in Table 76 below.
  • the response distribution message structure is shown in Table 77 below, and an example message is shown in Table 78 below.
  • ErrorCode enters the error code corresponding to the cause of the error if ResultCode is entered as a failure (0).
  • the physical address information retrieval interface is an interface where an electronic document relay or a transceiving entity receives a response from the address directory server by requesting the physical address information corresponding to the authorized electronic address of the electronic document recipient and the certificate information for message security processing. After receiving the request message, including the electronic address of the recipient and whether or not to request a public certificate in the request message, and receives the physical address information (IP address or domain address) and public certificate information of the electronic document recipient from the address directory server as a response message.
  • IP address or domain address IP address or domain address
  • the request distribution message structure is shown in Table 79 below, and an example message is shown in Table 80 below.
  • Spam message report accepting interface is an interface where an electronic document relay or a sender / receive entity reports a spam message to an address directory server.
  • the spam message is sent from the address directory server after the spam message is included in the request message. Receive a response message whether the report is received.
  • the address directory server notifies the report of the result of the spam message using the "message transmission" interface of the interfacing interface between the distribution messaging servers when the spam message is determined.
  • the message exchange flow related to the spam message report receiving process is illustrated in FIG. 49.
  • the request distribution message structure is shown in Table 83 below, and an example message is shown in Table 84 below.
  • ResultCode is the result of a simple receipt process for spam report messages.
  • the white list notification interface is an interface for notifying a sending / receiving entity of a white list (list of sending / receiving entities participating in the distribution system and a list of authorized electronic addresses of the sender and receiver).
  • the message exchange flow related to the white list notification is shown in FIG. 50.
  • the request distribution message structure is shown in Table 87 below, and an example message is shown in Table 88 below.
  • ResultCode is the result of a simple receipt process for spam report messages.
  • the blacklist notification interface is an interface for notifying a blacklist (rejection list) to a transmitting / receiving object. Notified blacklists are used for blacklist management by sending and receiving entities.
  • the message exchange flow related to the black list notification is shown in FIG. 51.
  • the request distribution message structure is shown in Table 91 below, and an example message is shown in Table 92 below.
  • the distribution messaging server basically has to establish a connection with the distribution messaging server established by another sending / receiving entity or an electronic document relay for sending and receiving messages.
  • a distribution certificate delivery linkage function must be additionally provided between the distribution messaging server of the third party archive provider and the other messaging server in order to store the distribution certificate in the third party archive.
  • the interfacing interface between distribution messaging servers is a protocol for transmitting and receiving messages and distribution certificates between messaging servers, and is divided into the interfaces shown in Table 95 below.
  • the SOAP message shall contain the sender's digital signature information and be delivered.
  • the receiver shall verify that the owner of the certificate used for the digital signature of the SOAP message matches the sender. Additional sender information (CorpNum, RValue) necessary for (VID verification) shall also be included and conveyed.
  • Additional sender information shall be located as an extension element (any ## other position) under the MessageHeader element in the SOAP message of request and response messages.
  • the extended element structure is shown in Table 96 below, and the schema structure is shown in Table 97 below.
  • the message transfer interface is used when a distribution messaging server transmits a message to another distribution messaging server.
  • the request format is as shown in FIG. 53.
  • the first MIME part includes a SOAP message
  • the second MIME part includes a request distribution message
  • the user attaches a document.
  • the structure of the request distribution message is shown in Table 98 below.
  • the response format is shown in FIG. 54.
  • a SOAP message is located in the first MIME part
  • a response distribution message is located in the second MIME part
  • a receipt certificate is located in the third MIME part. . If an error occurs in the processing of the request message, the third MIME part is not created.
  • the structure of the response distribution message is shown in Table 100 below, and the actual example is shown in Table 101 below.
  • the distribution certificate delivery interface is used when the distribution messaging server transmits a reading certificate to another distribution messaging server. It is also used when the distribution relay server sends an electronic document to the receiving distribution messaging server after sending an electronic document to the receiving distribution messaging server and sending the received certificate to the requesting distribution messaging server.
  • the message exchange flow related to the distribution certificate delivery process is shown in FIG. 55.
  • the distribution certificate delivery request format is shown in FIG. 56.
  • a SOAP message is located in the first MIME part
  • a request distribution message is located in the second MIME part
  • a distribution certificate is located in the third MIME part.
  • the request distribution message structure is shown in Table 102 below, and the actual example is shown in Table 103 below.
  • the distribution certificate delivery response format is as shown in FIG. 57 (if 57a is successful and 57b is an error), and in the entire message structure as shown in FIG. 57, if the processing of the request message is successful, it is received in the first MIME part. Acknowledgment Acknowledgment Only the SOAP message is located. In case of an error, the SOAP message is located in the first MIME part and the error response distribution message is located in the second MIME part.
  • the response distribution message structure is shown in Table 104 below, and Table 104 is applicable only when the processing result is an error.
  • the distribution certificate storage request interface is used when a distribution messaging server of a transmitting / receiving entity makes a request for storage of a distribution certificate to a distribution messaging server of a third-party storage institution operator in order to store the distribution certificate in a third-party storage organization.
  • the response message on this interface includes only the acknowledgment information, and the initial registration certificate issued as a result of storing the distribution certificate in the third party storage institution is requested to be stored using the "3rd party storage institution storage result delivery interface" described below. Deliver to distribution messaging server.
  • the request format for storing the distribution certificate is shown in FIG. 59.
  • the SOAP message is located in the first MIME part
  • the request distribution message is located in the second MIME part
  • the distribution certificate is located in the third MIME part. .
  • the requested distribution message structure is shown in Table 105 below, and the actual example is shown in Table 106 below.
  • the distribution certificate storage response format is as shown in FIG. 60 (if 60a is successful and 60b is an error), and in the entire message structure as shown in FIG. 60, if the processing of the request message is successful, it is received in the first MIME part. Acknowledgment Acknowledgment Only the SOAP message is located. In case of an error, the SOAP message is located in the first MIME part, and the error response distribution message is located in the second MIME part.
  • Table 107 The response distribution message structure is shown in Table 107 below. Table 107 is applicable only when the processing result is an error.
  • the third party storage organization storage result delivery interface is a distribution messaging server in which the distribution messaging server of the third party storage institution operator stores the distribution certificate in the third party storage institution and requests the storage certificate of the distribution certificate received as the result of the initial registration certificate. Used when sending to.
  • the message exchange flow related to the third-party archival institution storage result transfer processing is shown in FIG. 61.
  • the storage format of the third-party custody storage result is shown in FIG. 62.
  • a SOAP message is used for the first MIME part, a request distribution message for the second MIME part, and an initial registration certificate for the third MIME part. Is located. If an error occurs in the process of storing the distribution certificate in the third-party archive, the third MIME part is not created.
  • the requested distribution message structure is shown in Table 108 below, and the actual example is shown in Table 109 below.
  • the third-party custody storage result response format is shown in FIG. 63 (when 63a is successful and 63b is an error).
  • the first message is displayed when the processing of the request message is successful. Only acknowledgment Acknowledgement SOAP message is placed in the first MIME part. In case of an error, the SOAP message is located in the first MIME part and the error response distribution message is located in the second MIME part.
  • the response distribution message structure is shown in Table 110 below, and Table 110 is applicable only when the processing result is an error.
  • the distribution messaging server should provide the basic document transmission / reception function to the user in connection with the system (distribution client) for the user (internal transceiver or authorized transceiver) requesting the actual electronic document distribution.
  • the interfacing interface between the distribution client and the distribution messaging server is a protocol for primarily communicating with the distribution messaging server in order to transmit and receive electronic documents, and is divided into the interfaces shown in Table 111 below.
  • the SOAP message the first MIME part of the request message sent by the distribution client to the distribution messaging server, must be delivered with the user's digital signature information.
  • the owner of the certificate used by the distribution messaging server in the digital signature of the SOAP message is Additional user information (IDN, RValue) required to verify user conformity (VID verification) should also be included and conveyed.
  • This information should be placed as an extension element (any ## other position) under the MessageHeader element in the SOAP message of the request message.
  • the extended element structure is shown in Table 112 below, and an example of extended elements is shown in Table 113 below.
  • the message transfer request interface is used when a distribution client sends a message to a distribution messaging server for sending a message through the distribution messaging server.
  • the message transmission processing flow of the distribution client is as shown in FIG.
  • the message transmission request format of the distribution client is shown in FIG. 65.
  • a SOAP message is located in the first MIME part and a request distribution message is located in the second MIME part. If there is a document attached by the user, it is located from the third MIME part.
  • the requested distribution message structure is shown in Table 114 below, and the actual example is shown in Table 115 below.
  • Text can be omitted if the text is not needed for document delivery.
  • the distribution client message transmission response format is as shown in FIG. 66 (when 66a is successful and 66b is an error).
  • the first MIME part when the processing of the request message is successful. Only acknowledgment Acknowledgment SOAP message is located at.
  • SOAP message is located at the first MIME part and error response distribution message is located at the second MIME part.
  • the response distribution message structure is shown in Table 116, and Table 116 is applicable only when the processing result is an error.
  • the message list request interface is used when a distribution client requests a list of messages received by the distribution messaging server.
  • the message list processing flow of the distribution client is as shown in FIG.
  • the message list request format of the distribution client is shown in FIG. 68.
  • a SOAP message is located in the first MIME part and a request distribution message is located in the second MIME part.
  • the requested distribution message structure is shown in Table 117 below, and the actual example is shown in Table 118 below.
  • the message list response format of the distribution client is shown in Table 67.
  • the SOAP message is displayed in the first MIME part and the response distribution message is in the second MIME part (the list of distribution messages received by the distribution messaging server). This is located.
  • the response distribution message structure is shown in Table 119 below, and the actual example is shown in Table 120 below.
  • the message detail request interface is used when a distribution client requests a specific message and an attached document received by the distribution messaging server.
  • the detailed information request processing flow of the distribution client is illustrated in FIG. 69.
  • the message detail request format of the distribution client is shown in FIG. 70.
  • a SOAP message is located in the first MIME part and a request distribution message body is located in the second MIME part.
  • the request distribution message structure is shown in Table 121 below, and the actual example is shown in Table 122 below.
  • the response format of the message detail information of the distribution client is shown in FIG. 72.
  • the first MIME part includes a SOAP message
  • the second MIME part includes a response distribution message (distribution message detail information) and an attached document. If present, they are placed in order from the third MIME part.
  • the response distribution message structure is shown in Table 123 below, and the actual example is shown in Table 124 below.
  • the spam message reporting interface is used when a distribution client reports a spam message to a distribution messaging server.
  • the distribution messaging server reports the spam message to the address directory server and delivers the result to the distribution client.
  • the spam message report processing flow of the distribution client is shown in FIG. 73.
  • the spam message report format of the distribution client is shown in FIG. 74.
  • a SOAP message is located in the first MIME part and a request distribution message is located in the second MIME part.
  • the structure of the request distribution message is shown in Table 125 below, and an example message is shown in Table 126 below.
  • the response format of the spam message of the distribution client is shown in FIG. 75.
  • the SOAP message is displayed in the first MIME part and the response distribution message is in the second MIME part (the list of distribution messages received by the distribution messaging server). This is located.
  • ResultCode is the result of a simple receipt process for spam report messages.
  • the physical address lookup interface is used by the distribution client to request a physical address lookup from the distribution messaging server.
  • the distribution messaging server retrieves the physical address from the address directory server and delivers the result.
  • the physical address search request message format is shown in FIG. 77.
  • a SOAP message is located in the first MIME part and a request distribution message is located in the second MIME part.
  • the request distribution message structure is shown in Table 129 below, and an example message is shown in Table 130 below.
  • the physical address retrieval response message format is shown in FIG. 78.
  • the first MIME part has a SOAP message
  • the second MIME part has a response distribution message (list of distribution messages received at a distribution messaging server). Located.
  • the response distribution message structure is shown in Table 131 below, and the actual example is shown in Table 132 below.
  • the RAddress can be omitted (Endpoint and Cert are omitted as a result).
  • ErrorCode enters the error code corresponding to the cause of the error when ResultCode is entered as a failure (0), that is, when another error occurs except an error in the absence of an address.
  • the distribution relay server is a system for performing electronic document transmission on behalf of the transmission distribution messaging server when an error occurs during transmission of an electronic document directly between distribution messaging servers in an electronic document distribution system.
  • Distribution relay server is managed by ICT Industry Promotion Agency. All distribution messaging servers can be supported in case of errors in P2P distribution process in connection with distribution relay server.
  • connection interface between the distribution messaging server and the distribution relay server is a protocol for requesting transmission of an electronic document to the distribution relay server by the distribution messaging server, and is classified into an interface as shown in Table 133 below.
  • the SOAP message the first MIME part of the message, must contain the digital signature information of the distribution messaging server.
  • the distribution relay server is the owner of the certificate used for the digital signature of the SOAP message.
  • the additional distribution messaging server information (CorpNum, RValue) needed to verify that the server matches the distribution messaging server (VID verification) should also be included and delivered.
  • the information of the additional distribution messaging server shall be located as an extension element (any ## other location) under the MessageHeader element in the SOAP message.
  • the extended element structure is shown in Table 134 below, and an example of extended elements is shown in Table 135 below.
  • the message transmission request interface is used when a distribution messaging server requests a message transmission to a distribution relay server and receives a transmission certificate when a reception error on the other distribution messaging server occurs while transmitting a message to another distribution messaging server.
  • the distribution relay server immediately returns only the result of receiving the message transmission request from the distribution messaging server, and after receiving the message to the receiving distribution messaging server, the reception certificate received by using the above-mentioned "distribution certificate delivery interface" is used for distribution messaging.
  • the message relay processing flow is as shown in FIG.
  • the message relay request message format is shown in FIG. 80.
  • a SOAP message is located in the first MIME part and a request distribution message is located in the second MIME part. If there is a document attached by the user, it is located from the third MIME part.
  • the request distribution message structure is shown in Table 136 below, and the actual example is shown in Table 137 below.
  • the message relay response message format is shown in FIG. 81.
  • a SOAP message is located in the first MIME part
  • a response distribution message is located in the second MIME part
  • a transmission certificate is located in the third MIME part. If an error occurs in the processing of the request message, the third MIME part is not created.
  • the response distribution message structure is shown in Table 138 below, and the actual example is shown in Table 139 below.
  • Electronic document distribution is based on peer-to-peer communication where companies / institutions that comply with the standards for trust distribution directly exchange electronic documents with each other.
  • the basic element of the electronic document distribution system according to the present invention for performing such P2P communication is a standard specification-based distribution messaging server system that supports distribution between an address directory server managing address information and each send / receive entity. .
  • a basic structure for distributing electronic documents can be provided by a company or institution, and a distribution certificate is issued to prove document distribution between senders and receivers.
  • the legal basis for distribution can be secured by storing in a third party storage institution (public office, authorized electronic archives).
  • Electronic document distribution system in addition to the above basic elements, in order to facilitate the distribution of electronic documents to general users (company / organization, individual), the distribution client application (APP) that provides a user interface for the document transmission and reception function
  • APP distribution client application
  • Additional components include an electronic document form register that provides standard document forms to enhance the convenience of document preparation, and a public sector linkage gateway for relaying electronic documents with administrative agencies.
  • each send / receive entity In order for electronic document distribution to take place, first, there must be “1 send / receive entity”, which is the subject of distribution, and each send / receive entity must have “2 distribution messaging server system” that complies with the distribution messaging server standard to distribute documents. . In addition, there should be a “3 Address Directory Server” that registers and manages each send / receive object and a user's public electronic address as a basic component of electronic document distribution.
  • the unit of distribution is the sending / receiving entity.
  • the sending / receiving entity performs the sender or receiver according to the role of participating in the distribution.
  • the document (information) is distributed according to the distribution protocol specification through the server system.
  • All the sending / receiving entities participating in the distribution establish a distribution messaging server system that can send and receive documents according to the distribution messaging standard, and then register the physical address information of the distribution messaging server system in the address directory server to participate in the electronic document distribution. It will create a foundation. At this time, each transmitting and receiving entity has a real distribution user having at least one authorized electronic address.
  • the entity that can be recognized as a sending / receiving entity in the electronic document distribution is limited to an entity certified by the Information and Communications Industry Promotion Agency for standard conformance and interoperability after establishing a system that complies with the messaging server standard.
  • the distribution certificate shall be issued according to the standard and stored in the third-party storage institution.
  • the transmission and reception entity is divided into an entity that is responsible for the direct transmission of the electronic document as a legal owner and responsible for the electronic document, and an entity that acts on behalf of the electronic document for the user who is the owner and the responsible person of the electronic document in circulation.
  • the owner of the electronic document is a transmitting / receiving entity that transmits the electronic document directly
  • the standard suitability and interoperability of the distribution messaging server system can be authenticated, and the distribution document can be securely participated in the sending / receiving entity simply by keeping the distribution certificate in a third-party storage institution. have.
  • the sending / receiving entity that is responsible for the third party transmission on behalf of the electronic document owner (user)
  • it must prove that the sending / receiving entity manages the transmission message in a safe and reliable manner, and manages and authenticates the user information. do.
  • the third party custody carriers can transmit / receive such a third party for a limited time.
  • the distribution messaging server system In order to distribute electronic documents (information) based on the distribution messaging server standard, the distribution messaging server system must establish a function of retrieving address information and security-related information about the recipient in connection with a message transmission / reception function and an address directory server.
  • the distribution messaging server system physically has one electronic address (IP address), but can issue and manage a plurality of user accounts for lower users, and each user account has one public electronic address.
  • the distribution messaging server system must manage an electronic document mailbox for each user account in order to manage each user account, and the distribution messaging server system has a safe and reliable electronic document distribution responsibility on behalf of this user account.
  • the authentication system that authenticates the standard conformance and interoperability of the distribution messaging server system must manage the authenticated send and receive objects. If the address directory server requests verification of whether the authentication has passed during the registration of the public electronic address, the result is returned. Should give.
  • an enterprise / institution or individual user who wants to be a transmitting / receiving entity establishes a distribution messaging server system in accordance with the present technical standard.
  • the automated test tool provided by the authentication test bed verifies the standard conformance and interoperability of the deployed messaging server system.
  • the sending / receiving entity that has completed all its verifications requests an authentication test from the authentication test bed.
  • the sending / receiving entity prepares the next procedure for registering the public electronic address.
  • the authentication test bed delivers information about the send / receive entity that passed the authentication audit to the address directory server, and the address directory server uses this information as a condition of address registration.
  • the sending / receiving entity applies for issuing a unique ID to the address directory server in order to register the distributed messaging server system that has passed the authentication.
  • the distribution messaging server system can participate in the electronic document distribution.
  • a user account is opened, and in the case of a representative public electronic address, the user account requests registration of the public electronic address.
  • the distribution client APP refers to an application that provides a UI for sending and receiving documents, viewing and managing received documents, etc., for users participating in document distribution.
  • the distribution client APP cannot send and receive documents on its own and must be linked with the distribution messaging server system.
  • Documents created or attached to the distribution client APP are delivered to the distribution messaging server system to request transmission, and the documents received through the distribution messaging server system are inquired. If the distribution messaging server system manages the sending and receiving mailbox through a user account, the distribution client APP can access only the document through checking the user account information among the received documents.
  • the distribution client APP may be implemented as a C / S type application or a web type screen at the request of a user.
  • public sector linkage gateways relay documents between administrative, public institutions and private enterprises, institutions and individuals under the electronic document distribution system.
  • the Electronic Document Format Register can be used to create a sent document directly using Office tools for users who want to send electronic documents using a distributed messaging server system, but the standard document form can be used to help users create electronic documents more easily. It is a system that supports management such as document form registration and management, document form search, reading and downloading, document form deletion, and so on, for use by user applications such as distribution client APP while registering and managing the system.
  • the electronic document form register provides a standard interface that allows the server engine and client application (APP) that manages document standard forms to retrieve them, download them, and plug them into internal programs for use.
  • APP server engine and client application
  • the entire process for distributing electronic documents in electronic document distribution can be broadly classified into three stages: “1 preparation before distribution”, “2 electronic document distribution step”, and “3 proof for distribution”.
  • the "document transmission and reception method”, “distribution proof method” and “spam message processing method” will be described in detail with the detailed description of the three steps.
  • register manager registers standard document form to use using electronic document tasting register.
  • -Participants in the transmission and reception decide whether to build their own distribution messaging server system for trust distribution or to open and use user accounts in the existing distribution messaging server system.
  • a certification test is performed for the standard conformance and interoperability of the distribution messaging server system through a certification authority. After accessing the address directory server and requesting and issuing an ID of the send / receive object for the authorized distribution messaging server system, the user registers and manages the internal identifier for the internal real user.
  • the document sender selects a document to distribute or prepares a document to send through the document writer.
  • the distribution client APP obtains the physical address information and the public key information for encryption based on the public address of the receiving party in association with the address directory server. (Optionally, the Distribution Messaging Server does this if the Distribution Client APP does not obtain a physical address.)
  • the distribution client APP makes a request to the distribution messaging server based on the recipient's address information. (Both physical address information or authorized electronic address)
  • the distribution messaging server queries the address directory server for the physical address information of the receiver's transmitting / receiving entity based on the authorized electronic address.
  • the recipient shall generate a "receipt certificate" at the time of receipt of the document to confirm the receipt of the document and deliver it to the sender.
  • the recipient of the received document shall keep the "receipt certificate" in the third party archive.
  • the receiver delivers the received document to the person in charge of the actual document (user), and then generates a "reading certificate” and sends it to the sender when the person checks the received document.
  • the document sender who receives the "reading certificate” Keeps the "Certificate of Reading” in a third-party repository. (Issuance of Certificate of Reading applies only at the request of the sender.)
  • the sender attempts to deliver the document to the receiver but fails, the document is sent to the objective 3rd party electronic document distribution hub for proof of the attempted transmission, and the electronic document distribution hub that has been requested to send the document has been submitted.
  • the "Transmission Certificate” shall be issued and delivered to the sender, who shall receive the "Transmission Certificate” in the third-party archive.
  • the distribution messaging server system Through the distribution messaging server system, senders and receivers distribute documents electronically.
  • the distribution messaging server system sends and receives electronic documents according to distribution protocols.
  • For the distribution of trust messages all messages are composed of a combination of transmission and acknowledgment (or certificate of receipt) messages. Obtained through
  • Distribution certificate means a reliable way to prove the facts related to the transmission, reception, and viewing of electronic document distribution.
  • the “distribution certificate” is referred to collectively as the certificate issued for the acts related to electronic document distribution.
  • the distribution messaging server system issues a distribution certificate at the time of transmission and reception in order to verify the transmission and reception behavior, and stores the issued distribution certificate in a certified electronic document third-party storage institution to use as evidence of distribution behavior. Make sure
  • the distribution messaging server system proves the facts on the transmission, reception, and reading of electronic documents and generates distribution certificates for each fact.
  • the distribution certificate identifies distribution certificate identification information, distribution certificate creation time and expiration time, distribution certificate policy and distribution certificate. Include the subject.
  • the distribution certificate for the electronic document transmission is generated by the electronic document distribution hub and includes the sender identification information, the recipient identification information, the distribution identification information, the document identification information, and the request time of the electronic document transmission.
  • the distribution certificate for receiving the electronic document is generated by the receiver who has received the electronic document and includes the sender identification information, the recipient identification information, the distribution identification information, the document identification information, the electronic document transmission time, and the electronic document reception time.
  • the distribution certificate for reading the electronic document is generated by the user who has confirmed receipt of the electronic document, and the sender identification information, the recipient identification information, the distribution identification information, the document identification information, the electronic document transmission time, the electronic document reception time, and the electronic document reception are applied to the distribution certificate object.
  • a confirmation time must be included.
  • the distribution certificate thus generated should be digitally signed with an NPKI or GPKI certificate, the generated distribution certificate should be delivered to the sender of the electronic document, and all distribution certificates should be kept in a third-party archive.
  • Electronic document distribution basically transmits through the authorized distribution messaging server system, and the receiver also receives it by default, so it has an infrastructure to hold the sender accountable when sending spam.
  • a spammer establishes a user account in a distribution messaging server system and transmits using the same.
  • the current authentication method is only for the technical content of the system, when the spammer constructs the distribution messaging server system and technically authenticates it and then uses it as a spam sending means, it is initially blocked. This is not an easy situation.
  • the standard document distribution infrastructure provides a white list based on the authentication list management and a black list based on the spam target list management based on the user report method. To prevent spam messages by applying a process that can be unsubscribed.
  • the function to report spam message and to check the sending party is an essential function. All distribution messaging servers must build this function.
  • the receiver determines that the received message is a spam message
  • the receiver reports the spam message to the address directory server of the electronic document distribution hub by the process shown in FIG. 83, and the related procedure is as follows.
  • the receiver reports the message as a received message to the address directory server through the distribution messaging server system.
  • the address directory server that receives the spam message report from the distribution messaging server system returns a confirmation message indicating that the message has been received.
  • the ICT which manages the address directory server, analyzes the message and examines and determines whether to add a blacklist to the sender's public electronic address through a survey of the sender.
  • the address directory server adds the public electronic address to the blacklist and notifies the sender of the blacklist addition.
  • the address directory server delivers the processing result of the spam message request to the spam reporter (recipient).
  • the whitelist is recorded only with information on the messaging server system that is authenticated and registered by the sending distribution messaging server system, and the blacklist is registered when the sender's address is registered as a spammer. If duplicate spam addresses registered in the blacklist are generated through the same distribution messaging server system, the electronic document distribution hub may determine whether to cancel the authentication of the distribution messaging server system, and then cancel the authentication and delete the whitelist.
  • the receiver When the receiver receives the message, the receiver checks the whitelist and the blacklist of the address directory server to confirm whether or not the sender is a reliable and legitimate user, and then decides whether or not to reject the message. There is a periodic verification method to confirm the sender through real-time confirmation at the time of reception or through a list managed in a cache form in the distribution messaging server system of the receiver.
  • the process of checking the sender in real time is performed by determining whether the sender's address is registered in the whitelist or the blacklist at the address directory server at the time when the receiver receives the message, as shown in FIG.
  • the detailed processing procedure of the process of determining whether to reject the reception and performing the identification on the sender in real time is as follows.
  • the recipient's distribution messaging server system forwards a confirmation request message to the address directory server to confirm whether the user is a legitimate user.
  • the address directory server checks whether the address information of the requested user is included in the white list.
  • the address directory server immediately returns a result message indicating that the user is not registered to the verification requester. If the address is in the whitelist, the address directory server checks again whether the address is registered in the blacklist.
  • the address directory server returns a result message as to whether the blacklist has been registered to the requestor.
  • the recipient processes the received message as a spam message and receives the message from the address directory server. Record and store the result of receiving messages and spam messages.
  • the processing history of the spam message must be kept for at least one month, so that the validity of the rejection of the sender can be confirmed.
  • the process of periodically checking the sender is performed by receiving a whitelist and a blacklist from an address directory server in advance and manages itself based on the sender's address. After determining whether or not the message is registered in the list, it is determined whether to reject the message.
  • the detailed processing procedure of the process of periodically checking the sender is as follows.
  • the recipient's distribution messaging server system requests the latest whitelist and blacklist from the address directory server in advance and manages itself.
  • the automatic notification request is transmitted together.
  • the request for obtaining the latest list to the address directory server is periodically performed so that the list information does not differ by at least one day.
  • the address directory server broadcasts the change to the user who requested the change notification.
  • the user distribution messaging server system receiving the change to the list synchronizes by modifying the information of the self-managed list.
  • the recipient checks a self-managed list to see if he or she is a legitimate user on the address directory server.
  • the receiver determines that the sender is not a legitimate user (when it is not in the whitelist or is registered in the blacklist) as a result of the self-managed list check, the receiver processes the received message as a spam message and records the history of receiving the spam message. And keep it.
  • the processing history of the spam message must be kept for at least one month, so that the validity of the rejection of the sender can be confirmed.
  • Distribution messaging server system is largely composed of message transmission, message reception, mailbox management for incoming messages, message security (user authentication, document encryption / decryption, etc.), transmission / reception history management, address directory server connection, message verification, internal system connection interface, distribution It consists of issuance and management of certificates, and connection with third party custody institutions.
  • FIG. 86 illustrates a structure of the distribution messaging server system. Referring to FIG. 86, each of the components 1 to 9 of the distribution messaging server system will be described in detail as follows.
  • the status "in transmission” is a state in which no response is received from the receiver after the document is transmitted
  • the "transmission complete” state is a state in which a "receipt certificate” is received from the distribution messaging server system of the receiver, and the "transmission failed” state is received.
  • An error occurs inside the distributed messaging server system to return a SOAP Fault message, or a network error occurred during transmission or reception.
  • a "Contact Receive Complete” status indicates that the sending distribution messaging server system verified the document of the contact person from the receiver. You have received a "proof of reading”.
  • the "validation error” status is an error in the basic structure verification of the received message
  • the "before receipt confirmation” status is before the recipient of the receiving document reads the list of received documents in the mailbox
  • the "acknowledgement” status is the receipt document.
  • the person in charge reads the list of received documents in the mailbox
  • the "view confirmation” status indicates that the person in charge of the receiving document has read the details of the received document.
  • the recipient's distribution messaging server system issued a "reading certificate”. It will deliver to the sender later.
  • the transmission document, the acknowledgment message for the transmission, and the acknowledgment message of the recipient have related information so that they can be related to each other.
  • -Address information is managed according to the address information registration and search process provided by the address directory server.
  • -It basically performs the message security function (message digital signature, signature verification) suggested by distribution protocol.
  • the distribution messaging server system must keep / manage at least one year of sending / receiving history.
  • transmission history and reception history includes message id, related message id, sender (including user account), receiver, transmission time, and hash value for transmission document. Contains the hash value for the sender, receiver (including user account), reception time, and received document.
  • the distribution messaging server system issues and manages distribution certificates so that the contents of document transmission and reception can be proved.
  • the certificate of distribution is guaranteed to its credibility by requesting it to a third-party repository.
  • the distribution certificate issuance history includes distribution certificate id, distribution certificate issuance time, related message id, original distribution certificate (optional), and storage of third party storage institution. Contains archive-key information received afterwards.
  • the general sending / receiving entity transmits the request for storing the third party storage institution to the distribution messaging server system of the third party storage institution for the request for storing the distribution certificate (remote storage request).
  • the distribution messaging server system of the third-party archiving agency When the distribution messaging server system of the third-party archiving agency receives the request message for storing the authorized electronic archives, it calls the archiving request client for storing the distribution certificate to the third-party archiving agency.
  • the client for the distribution certificate storage request requests the storage to the third party storage organization according to the interworking interface specification of the third party storage organization.
  • the distribution certificate storage request module is stored in a third party when storing the distribution certificate. Request for storage by calling the interface client developed according to the organization interface specification.
  • the distribution messaging server system according to the present invention having the above components 1 to 9 is applied to a general transmission / reception entity (general operator) as shown in FIG.
  • the message is sent to the messaging server system to store the distribution certificate and processed by receiving the processing result.
  • the process of distributing a message directly between a sender and a receiver by using the distribution messaging server system according to the present invention having the components 1 to 9 as described above, includes: "acquiring physical address and security information for the receiver” and "2 message”. It consists of four steps, including “transmission and confirmation of transmission”, “3.3 receiving recipient's receipt”, “4. distribution certificate issuance and storage”, which will be described in detail with reference to FIG. .
  • the sender's system obtains this by requesting the address directory server for the physical address information and security information (if the receiving password for the outgoing message) to which the actual message should be delivered, based on the address information of the other party.
  • the physical address and security information for the recipient causes the distribution client APP to forward the recipient's physical address information to the distribution messaging server after making a request to the address directory server.
  • -Address information about the receiver can be obtained only by the id of the user (for example, social security number, business registration number, etc.), but in this case, it is possible only if the receiver allows the sender to search for id based address information.
  • This procedure can be omitted if the sender already knows the recipient's physical address information and security information.
  • the sender packages the message according to the distribution protocol specification and performs the digital signature based on the public certificate of the distribution messaging server system.
  • the retail messaging server system packages the previously obtained physical address and transmits the digitally signed message.
  • the receiving distribution messaging server system that receives the message verifies the basic packaging structure of the message, the validity of the digital signature, and the suitability of the sender (for details on verification, see “2.4.6 Message Verification”). Generate a receipt or error message for verification.
  • the receiving distribution messaging server system transmits the generated response message to the sender.
  • the transmission and acknowledgment process consists of synchronous message processing.
  • the receiver When the sender requests the confirmation message of the person in charge of the work at the time of message transmission, the receiver must generate and send a reading certificate that can confirm the confirmation of the person in charge to the sender at the time of the business acknowledgment of the message.
  • the original message sender sends the acknowledgment message synchronously.
  • the sender issues a certificate of receipt, reading and transmission at each stage and secures the basis of legal evidence on distribution by issuing it in a third-party storage institution.
  • the process of distributing a message directly between a sender and a receiver by using a distribution messaging server system includes the above-mentioned "acquisition of physical address and security information for the receiver", “2 message transmission and transmission confirmation", "3 tasks”.
  • "acknowledgement of the receiver” In addition to the "acknowledgement of the receiver", “4. issue and store the distribution certificate”, "5 error processing” is also performed.
  • the error handling function will be described in detail as follows.
  • All message sending and receiving processes in the distributed messaging server system are based on synchronous processing. Therefore, all errors on the transmission are based on retransmission because the sender can check them, and the same message transmission is sent again by setting the same MessageId value so that the receiver duplicates the error in the transmission of the acknowledgment message after successful reception. Allows you to detect receipt of a message.
  • the distribution messaging server system follows the processing flowchart as shown in FIG. 90 when the request message transmission fails. That is, if a transmission error occurs due to a network error during the message sender's transmission, if the sender receives an error message such as an HTTP error, the sender requests to resend the same message again, and the sender sends the message only when the recipient receives an acknowledgment message. Recognize it as a success.
  • an error message such as an HTTP error
  • the distribution messaging server system follows the processing flowchart as shown in FIG. 91 when the response message reception fails. That is, if the message is delivered to the receiver normally but the sender does not receive the acknowledgment message from the receiver, the sender recognizes it as a transmission failure error and resends the same message to the receiver with the same MessageId. If the same as the previous received message, the acknowledgment message is sent with duplicate reception and internal processing is performed.
  • the distribution messaging server system follows the processing flowchart as shown in FIG. 92 when the error message reception fails. That is, if the message sent by the sender to the receiver is correctly delivered, but there is an error in the transmission message itself, and the error message is responded, the sender has different message processing according to the type of error. It is not necessary and can be handled differently depending on the work situation.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Entrepreneurship & Innovation (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • General Physics & Mathematics (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Information Transfer Between Computers (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

본 발명은 기업/기관 등과 함께 일반 개인, 소기업들도 신뢰성을 확보받을 수 있는 전자문서 유통 체계를 구축하는 것이 가능한 전자문서 유통 시스템 및 전자문서 유통 방법에 관한 것이다. 이러한 본 발명에 따른 전자문서 유통 시스템은, 전자주소를 기반으로 메시지를 송수신하고 메시지 송수신에 대한 유통증명서를 발급 및 관리하는 유통 메시징서버를 통해 전자문서를 유통하는 송수신 개체; 상기 송수신 개체의 전자주소를 등록/관리하며, 상기 송수신 개체 간의 전자문서 유통 경로를 설정하고, 상기 송수신 개체에게 전자문서의 표준서식을 제공하며, 송수신 개체 간의 전자문서 유통 과정에서 오류가 발생하였을 시에 메시지 전송을 대행하고 유통증명서를 발급하는 유통 허브; 및 유통증명서를 전달받아 보관하며, 신뢰할 수 있는 제3자 보관기관; 을 포함한다.

Description

전자문서 유통 시스템 및 전자문서 유통 방법
본 발명은 기업/기관 등과 함께 일반 개인, 소기업들도 신뢰성을 확보받을 수 있는 전자문서 유통 체계를 구축하는 것이 가능한 전자문서 유통 시스템 및 전자문서 유통 방법에 관한 것이다.
일반적으로 전자문서 유통은 기업/기관들이 개별적인 고유 규약을 기반으로 특정 산업군 또는 커뮤니티 내에서만 한정적으로 이루어져 왔다.
또한, 일반 개인들 간, 개인과 기업/기관들 간에는 신뢰적 전자유통의 개념이 없이 이메일을 보조 수단으로 활용하거나, 개인, 개인사업자, 소기업들이 대기업 사이트에 접속하는 방법을 통해서만 온라인 소통이 가능한 단점이 있어왔다.
따라서, 일정 규모의 유통 시스템을 보유할 수 있는 기업뿐만 아니라, 일반 개인, 개인사업자, 소기업들도 유통에 대한 신뢰성을 보장받을 수 있는 전자문서 유통 기반 인프라의 구축이 기대되고 있다.
본 발명은 상기와 같은 종래의 문제점을 해결하기 위한 것으로서, 본 발명의 목적은 일정 규모의 전자문서 유통시스템을 보유할 수 있는 기업/기관 등과 함께 일반 개인, 소기업들도 신뢰성을 확보할 수 있는 전자문서 유통 시스템 및 전자문서 유통 방법을 제공하는 것이다.
상기와 같은 목적을 가지는 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템은, 전자문서를 유통하는 시스템에 있어서, 전자주소를 기반으로 메시지를 송수신하고 메시지 송수신에 대한 유통증명서를 발급 및 관리하는 유통 메시징서버를 통해 전자문서를 유통하는 송수신 개체; 상기 송수신 개체의 전자주소를 등록/관리하며, 상기 송수신 개체 간의 전자문서 유통 경로를 설정하고, 상기 송수신 개체에게 전자문서의 표준서식을 제공하며, 송수신 개체 간의 전자문서 유통 과정에서 오류가 발생하였을 시에 메시지 전송을 대행하고 유통증명서를 발급하는 유통 허브; 및 유통증명서를 전달받아 보관하며, 신뢰할 수 있는 제3자 보관기관; 을 포함한다.
상기와 같은 목적을 가지는 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템은, 송수신 개체와 유통허브를 포함하는 전자문서 유통 시스템에서 전자문서를 유통하는 방법에 있어서, (a) 송신 개체는 수신 개체의 주소 정보에 대응되는 물리적 주소 정보를 유통허브를 통해 획득한 후에, 전자문서를 첨부한 메시지를 상기 물리적 주소로 전송하는 단계; (b) 메시지를 수신한 수신 개체는 수신 메시지 및 송신 개체에 대한 적합성 검증 결과에 따라 수신증명서 또는 오류증명서를 발급하여 송신 개체에게 전달하는 단계; 및 (c) 수신 개체에게 메시지를 전송하였으나 실패한 송신 개체는 유통허브에 메시지 전송 대행을 의뢰하며, 메시지 전송 대행 의뢰를 받은 유통허브는 송신증명서를 발급하여 송신 개체에게 전달하고 수신 개체에게 메시지를 전송한 후에 상기 (b)단계를 수행하는 단계; 를 포함한다.
상기와 같은 구성 및 방법을 가지는 본 발명은 기업/기관 등과 함께 개인, 소기업들도 신뢰성을 확보받을 수 있는 전자문서 유통 체계를 구축하는 것이 가능한 효과가 있다.
도 1은 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템의 구성 예를 도시한 도면.
도 2는 도 1의 유통 메시징서버에 대하여 설명하기 위한 도면.
도 3은 도 1의 유통 클라이언트에 대하여 설명하기 위한 도면.
도 4는 도 1의 주소 디렉터리 서버에 대하여 설명하기 위한 도면.
도 5는 도 1의 전자문서 서식등록기에 대하여 설명하기 위한 도면.
도 6은 도 1의 유통 중계서버에 대하여 설명하기 위한 도면.
도 7은 도 1의 외부 연계 게이트웨이에 대하여 설명하기 위한 도면.
도 8은 도 1의 전자문서 유통 시스템 내에서 공인전자주소가 가지는 효력범위를 설명하기 위한 도면.
도 9는 본 발명의 바람직한 실시예에서 공인전자주소의 신청/발급 및 운영 체계를 설명하기 위한 도면.
도 10 내지 도 13은 본 발명의 바람직한 실시예에서 전자문서를 유통할 시에 메시지 보안에 대하여 설명하기 위한 도면.
도 14 내지 도 17은 본 발명의 바람직한 실시예에서 메시지 송수신 프로세서에 대하여 설명하기 위한 도면.
도 18은 본 발명의 바람직한 실시예에서 물리적 주소 획득 프로세스를 설명하기 위한 도면.
도 19 내지 도 21은 본 발명의 바람직한 실시예에서 유통 중계 지원 프로세스를 설명하기 위한 도면.
도 22 내지 도 24는 본 발명의 바람직한 실시예에서 공인전자주소 등록 등 관리 프로세스를 설명하기 위한 도면.
도 25와 도 26은 본 발명의 바람직한 실시예에서 전자문서 서식 적용 프로세스를 설명하기 위한 도면.
도 27 내지 도 29는 본 발명의 바람직한 실시예에서 스팸 메시지 처리 프로세스를 설명하기 위한 도면.
도 30과 도 31은 본 발명의 바람직한 실시예에서 전자문서 열람서비스 개념도를 도시한 도면.
도 32는 본 발명의 바람직한 실시예에서 외부 연계 게이트웨이 서버 개념도를 도시한 도면.
도 33은 본 발명의 바람직한 실시예에서 외부 시스템과 연계하여 전자문서가 유통되는 절차를 설명하기 위한 도면.
도 34 내지 도 38은 본 발명의 바람직한 실시예에 따른 전자문서 유통체계 하에서 전자문서 유통을 위해 각 구성요소들 간에 서로 연계되어 동작하기 위한 통신 프로토콜의 구성을 설명하기 위한 도면.
도 39 내지 도 43은 본 발명의 바람직한 실시예에 따른 전자문서 유통체계 하에서 오류 처리 방안을 설명하기 위한 도면.
도 44 내지 도 51은 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템에서 유통 메시징서버와 주소 디렉터리 서버 간의 연계 인터페이스를 설명하기 위한 도면.
도 52 내지 도 63은 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템에서 유통 메시징서버 상호 간의 연계 인터페이스를 설명하기 위한 도면.
도 64 내지 도 78은 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템에서 유통 클라이언트와 유통 메시징서버 간의 연계 인터페이스를 설명하기 위한 도면.
도 79 내지 도 71은 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템에서 유통 메시징서버와 유통 중계서버 간의 연계 인터페이스를 설명하기 위한 도면.
도 82는 본 발명의 다른 실시예에 있어서 유통 메시징서버 시스템이 인증을 받아 공인전자주소로서 등록을 받기 위한 절차를 도시한 도면.
도 83은 본 발명의 다른 실시예에 있어서 송수신 개체가 수신자로서의 역할을 할 시에 스팸메시지를 전자문서 유통허브에 신고하는 절차를 도시한 도면.
도 84는 본 발명의 다른 실시예에 있어서 송수신 개체가 수신자로서의 역할을 할 시에 송신 상대방에 대하여 수신거부를 할 것인지 여부를 실시간으로 확인하는 경우의 절차를 도시한 도면.
도 85는 본 발명의 다른 실시예에 있어서 송수신 개체가 수신자로서의 역할을 할 시에 송신 상대방에 대하여 수신거부를 할 것인지 여부를 주기적으로 확인하는 경우의 절차를 도시한 도면.
도 86 내지 도 100은 본 발명의 다른 실시예에 따른 유통 메시징서버 시스템에 대하여 설명하기 위한 도면.
도 101 내지 도 105는 본 발명의 다른 실시예에 따른 전자문서 유통 시스템 및 방법에 적용되는 유통 프로토콜에 대하여 설명하기 위한 도면.
도 106과 도 107은 본 발명의 다른 실시예에 따른 전자문서 서식 등록기에 대하여 설명하기 위한 도면.
도 108은 본 발명의 다른 실시예에 따른 전자문서 유통 시스템 및 방법에 적용되는 전자문서 패키징에 대하여 설명하기 위한 도면.
도 109 내지 도 114는 본 발명의 다른 실시예에 따른 유통 클라이언트 어플리케이션에 대하여 설명하기 위한 도면.
도 115는 본 발명의 또다른 실시예에 있어서 주소 디렉터리 서버가 전자주소를 발급하는 체계를 도시한 도면.
도 116은 본 발명의 또다른 실시예에 있어서 주소 디렉터리 서버가 전자주소를 발급하는 프로세스를 도시한 도면.
도 117과 도 118은 본 발명의 또다른 실시예에 있어서 주소 디렉터리 서버를 통해 주소 정보를 검색하는 프로세스의 예를 도시한 도면.
이하, 첨부한 도면 및 표를 참조하여 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템 및 전자문서 유통 방법에 대하여 설명하면 다음과 같다.
도 1에는 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템의 구성 예를 도시하였다.
도 1을 참조하면 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템은, 전자주소를 기반으로 메시지를 송수신하고 메시지 송수신에 대한 유통증명서를 발급 및 관리하는 유통 메시징서버를 통해 전자문서를 유통하는 송수신 개체(101); 상기 송수신 개체(101)의 전자주소를 등록/관리하며, 상기 송수신 개체(101) 간의 전자문서 유통 경로를 설정하고, 상기 송수신 개체(101)에게 전자문서의 표준서식을 제공하며, 송수신 개체(101) 간의 전자문서 유통 과정에서 오류가 발생하였을 시에 메시지 전송을 대행하고 유통증명서를 발급하는 전자문서 유통허브(102); 및 유통증명서를 전달받아 보관하며, 신뢰할 수 있는 제3자 보관기관(공전소, 공인전자문서 보관소; 103); 을 포함하여 구성된다.
상기 송수신 개체(101)의 유통 메시징서버는, 송수신한 메시지는 사용자별로 상태 정보를 포함하여 메시지함에 보관하고, 메시지 송수신 이력을 편집 및 삭제가 불가능한 매체에 소정 기간 동안 보관하며, 메시지 송수신에 대한 유통증명서를 발급하여 상기 제3자 보관기관에 보관을 의뢰하고, 상기 전자문서 유통허브(102)의 주소 디렉터리 서버와의 연계를 통해 상기 송수신 개체(101)에게 전자주소 등록 및 검색, 수정, 삭제를 포함하는 기능을 사용할 수 있도록 하며, 소정 기간 이상 보관된 메시지들을 외부 저장장치에 이관하여 보관한다.
상기 전자주소는, 상기 송수신 개체(101)가 상기 전자문서 유통허브(102)의 주소 디렉터리 서버를 통해 발급받은 이용자 식별기호; 상기 송수신 개체(101)가 필요한 경우에 자체적으로 부여하는 고유한 값이며, 해당 송수신 개체(101) 내에서 고유한 값인 추가 식별기호; 상기 이용자 식별기호와 추가 식별기호 사이에 위치하는 구분 기호; 를 포함한다.
상기 전자문서 유통허브(102)는 전자문서 서식 등록기를 구비하며, 상기 전자문서 서식 등록기는 전자문서 표준서식의 등록, 삭제 및 정보 수정을 포함하는 관리를 수행하며, 전자문서 표준서식을 문맥(context)에 따라 추가로 분류하고, 전자문서 표준서식이 사용될 수 있는 문맥(context)에 대한 등록, 수정을 포함하는 관리를 수행한다.
상기 전자문서 유통허브(102)는 송수신 개체(101) 간의 전자문서 유통 과정에서 오류가 발생하였을 시에 메시지 전송을 대행하고 유통증명서를 발급하는 유통 중계서버를 구비하며, 상기 유통 중계서버는 송수신 개체(101)로부터 메시지 전송을 의뢰받으면 메시지 전송을 대행한 후에 메시지 전송을 의뢰한 송수신 개체(101)에게 송신증명서를 발급하며, 의뢰받은 메시지 전송을 실패하였을 시에는 메시지 전송을 의뢰한 송수신 개체(101)에게 오류 메시지를 전송한다.
상기 전자문서 유통허브(102)는 외부 시스템과의 연계를 위한 외부 연계 게이트웨이 서버를 구비하며, 상기 외부 연계 게이트웨이 서버는 전자주소를 기반으로 메시지를 송수신하는 유통 메시징서버를 구비하며, 연계된 외부 시스템과 전자문서 유통 시스템 간의 송수신 전자주소의 검증/변환 기능과, 연계된 외부 시스템과 전자문서 유통 시스템 간의 메시지 검증/변환 기능, 연계된 외부 시스템과 전자문서 유통 시스템 간의 전자문서에 적용된 보안의 검증/변환 기능, 연계된 외부 시스템과 전자문서 유통 시스템 간의 전자문서의 적합성을 검증하고 상호간 변환하는 기능을 제공한다.
상술한 바와 같은 구성을 가지는 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템 및 이를 이용한 전자문서 유통 방법에 대하여 도 1 내지 도 118을 참조하여 상세히 설명하면 다음과 같다. 이하에서 본 발명에 대하여 상세히 설명함에 있어서 도 1의 도면 부호는 생략하도록 한다.
[전자문서 유통 시스템의 구조]
전자문서 유통의 신뢰성 및 안전성을 보장하기 위해 본 발명에 따른 전자문서 유통 시스템이 유통체계가 갖추어야 하는 요건은 다음 ① 내지 ⑦과 같다.
① 유통체계에 참여하는 송수신 개체 및 송수신자는 사전에 정의된 방식으로 전자문서를 송수신하여야 하며, 관리기관 또는 전자문서 중계자의 서비스 레벨 협약(SLA)에 동의하여야 한다.
② 유통체계 내 참여하는 송수신 개체 및 공인 송수신자는 신원확인이 가능하여야 하며, 전자문서 유통 행위는 그 사실에 대한 부인방지가 가능하여야 한다.
③ 유통체계에서 송수신 개체 및 공인 송수신자를 식별하기 위한 정보인 공인전자주소는 법인 또는 개인 단위로 부여가 되고 등록기관에 의해 등록 및 관리되어야 한다.
④ 유통체계 내 전자문서 유통 시, 유통증명서는 반드시 생성되어야 하며, 유통 행위에 참여한 송신 개체 및 제3자 보관기관에 전송 및 보관되어야 한다.
⑤ 모든 전자문서 유통행위는 P2P(Peer to Peer) 통신을 기본으로 하나, 다양한 환경적 요인으로 인해 통신에 실패한 경우 이를 지원하기 위한 체계가 있어야 한다.
⑥ 유통체계 내에서 당사자 간의 전자문서 교환뿐만 아니라, 전자문서 열람서비스 등 다양한 부가서비스도 지원될 수 있어야 한다.
⑦ 유통체계 이외의 외부 시스템과의 연계를 지원하는 게이트웨이가 제공되어야 한다.
본 발명에 따른 전자문서 유통 시스템은 공인전자주소를 기반으로 하며, 유통 메시징서버를 소유하고 있는 송수신 개체들 간에 전자문서를 주고 받는 P2P 통신을 기본으로 한다.
이와 같은 본 발명에 따른 전자문서 유통 시스템의 구조는 도 1과 같고, 시스템 내의 구성 요소에 대한 설명은 아래 표 1 및 표 2와 같으며, 주요 프로세스는 아래 표 3과 같다.
표 1
번호 개체명 설명
1 송수신 개체 유통 메시징서버 등 전자문서 유통에 필요한 시스템 등을 구비하여 유통체계에서 사전에 약속된 방식으로 전자문서 유통에 참여하는 기업 또는 기관. 전자문서 중계자를 포함한 일반적인 개념
2 전자문서 중계자 유통 메시징서버 등 전자문서 유통에 필요한 시스템을 구비하지 못한 송수신자에게 전자문서 유통서비스를 제공하기 위해 인증을 받은 제3자 기관
3 전자문서 유통허브 송수신 개체들 간의 전자문서 유통을 지원해주는 시스템들을 통칭하는 것으로 주소관리, 경로설정, 오류 및 보안처리, 외부와의 연계 등의 작업을 수행
4 송수신자 전자문서를 유통하는 기본 단위로서 실제 전자문서를 송신수신하는 최종 사용자. 공인 송수신자를 포함한 일반적인 개념
5 공인 송수신자 전자문서 중계자에 가입하여, 공인전자주소를 발급받아 전자문서 유통 서비스를 이용하는 송수신자
6 제3자 보관기관 지식경제부 장관의 지정을 받아 타인을 위하여 전자문서를 보관 또는 증명하거나 그 밖에 전자문서와 관련된 업무를 수행하는 법인
표 2
번호 개체명 설명
1 유통 메시징서버 송수신자를 대행하여 사전에 약속된 방식으로 전자문서를 유통하는 메시징 시스템으로 송수신 개체 또는 전자문서 중계자에 설치되는 시스템
2 유통 클라이언트 송수신자가 전자문서를 유통하기 위해 사용하는 어플리케이션을 통칭하는 말로서, 메시지의 편집과 유통 메시징서버를 통하여 메시지의 송수신 등의 기능을 제공하는 어플리케이션(예: 아웃룩, 웹메일 클라이언트 등)
3 주소 디렉터리서버 공인전자주소 기반 전자문서 유통체계에 참여하는 송수신 개체 및 송수신자의 공인전자주소를 등록,관리하며 송수신을 위해 필요한 주소정보를 제공해주는 시스템
4 전자문서 서식등록기 주문서, 송장, 세금계산서 등 구조화될 수 있는 전자문서의 표준서식을 송수신 개체가 공개적으로 이용할 수 있도록 등록,관리,제공해주는 시스템
5 유통 중계서버 유통체계에서 송수신 개체 간 전자문서 유통과정에서 오류가 발생하였을 때, 송신 개체를 대신하여 메시지 전송을 대행하는 시스템
6 외부 연계 게이트웨이 서버 유통체계가 외부 시스템 등과 연계하기 위한 신뢰성있는 통로 역할을 하는 시스템
7 NTP 서버 Network Time Protocol 서버로 유통체계 내 시간을 요청하는 시스템들에게 시간을 보내주는 역할을 하는 서버
8 등록대행 시스템 등록대행기관이 공인전자주소의 신청 접수 및 등록 등의 업무를 처리하기 위한 시스템
표 3
번호 프로세스명 설명
1 메시지 송수신 송수신 개체 간에 (전자문서를 포함한)메시지를 주고받는 행위로, 송수신 개체 내에 있는 유통 메시징서버를 통하여 메시지를 송신 및 수신하고, 유통증적 정보를 담은 유통증명서를 주고 받는 행위
2 물리적 주소 획득 전자문서를 전송하기에 앞서, 수신자의 공인전자주소에 해당하는 물리적 주소를 알기 위해 전자문서 유통허브 내에 있는 주소 디렉터리 서버에 질의하고 물리적 주소를 수신하는 행위
3 유통 중계 지원 네트워크 및 수신자 시스템 오류 등 다양한 오류에 의해 송수신개체 간 전자문서 유통이 원활하지 않을 때, 유통 중계서버가 전자문서 전송을 대행해주는 프로세스
4 유통증명서 보관 등 송신 개체가 수신한 유통증명서를 사전에 협약된 제3자 보관기관에 보관하는 행위(필요에 따라 메시지도 보관)
5 공인전자주소 등록 등 관리 송수신 개체 또는 공인 송수신자의 공인전자주소 등록, 변경 등을 하기 위한 프로세스
6 전자문서 서식 적용 유통 클라이언트에서 전자문서 서식등록기에 등록되어 있는 전자문서를 활용하는 프로세스
7 스팸 메시지 처리 특정 송수신자가 스팸 발송 등 유통체계 내에서 부적절한 행위를 하였을 때 이를 신고 및 처리하는 프로세스
8 오류처리 유통체계 내에 전자문서 유통 등 다양한 실패사례가 발생하였을 때, 이에 대한 원인 분석 및 이에 대해 대응,보완하는 행위
[전자문서 유통 시스템의 구성 요소]
① 유통 메시징서버
유통 메시징서버는 송수신 개체 내에 있는 메시징 시스템으로 전자문서 유통의 핵심적인 역할을 담당한다. 유통 메시징서버는 물리적으로 하나의 전자주소(IP Address)를 가지나, 하위의 사용자를 위해 복수의 사용자 계정을 발급하고 관리할 수 있어야 한다. 각 사용자 계정을 관리하기 위해 유통 메시징서버는 사용자 계정별 메시지함을 관리하여야 하며, 유통 메시징서버는 사용자들의 계정과 메시지함을 안전하고 신뢰성 있게 관리하여야 할 책임이 있다.
유통 메시징서버의 기능 개념도는 도 2와 같으며, 기능에 대한 설명은 아래 표 4와 같다.
표 4
번호 기능명 설명
1 메시지 송신,수신 - 유통 프로토콜에 따라 메시지를 송신하고 수신
2 사용자별 메시지함 관리 - 송수신한 메시지는 사용자 계정 또는 내부 구분자에 따라 메시지함에 보관- 메시지함에 보관된 송신문서는 다음 6단계의 상태정보 관리1) 송신 중 : 문서 전송 후, 수신자로부터 아무런 응답을 받지 못한 상태 2) 송신 완료 : 수신자의 유통 메시징서버로부터 '수신증명서'를 받은 상태3) 송신 위탁 : 송신 실패된 이후, 유통 중계서버에게 송신을 위탁한 상태 4) 송신 실패 : 수신자의 유통 메시징서버 내부에서 오류가 발생하여 SOAP Fault 메시지를 리턴하거나 송수신하는 과정에서 네트워크 오류가 발생한 경우5) 열람 실패 : 수신자가 메시지를 열람하는 과정에서 오류가 발생한 경우 6) 열람 완료 : 수신자의 유통 메시징서버로부터 '열람증명서'를 받은 상태 - 메시지함에 보관된 수신문서는 다음 4단계의 상태정보 관리1) 검증 오류 : 수신한 메시지에 대한 기본구조 검증에서 오류 발생 2) 수신 확인 전 : 당해 문서 수신자가 수신문서 목록을 읽기 전3) 수신 확인 : 당해 문서 수신자가 수신문서 목록을 읽음4) 열람 확인 : 당해 문서 수신자가 수신문서에 대한 상세 내용을 읽음 - 수신자에 의해 삭제 요청이 오면 해당 수신문서를 물리적으로 삭제 처리해야 함- 메시지함에서 송신메시지, 수신증명서, 열람증명서 등은 서로 연관될 수 있도록 연관정보를 가져야 함
3 송수신 이력관리 - 유통 메시징서버는 송수신 이력을 편집 및 삭제가 불가능한 매체에 일정기간 보관할 수 있어야 함- 보관하여야 하는 송수신 이력정보 1) 송신이력 : 메시지id, 연관메시지id, 송신자, 수신자, 송신시간, 송신문서에 대한 해쉬값2) 수신이력 : 송신자, 수신자(사용자 계정 포함), 수신시간, 수신문서에 대한 해쉬값
4 메시지 보완 - 유통 프로토콜에서 제시하는 메시지 보안 기능(전자서명, 서명 검증, 암/복호화 등)을 수행하여야 함
5 메시지 패키징 및 검증 처리 - 송신하는 문서는 전송 전에 유통 프로토콜에 정의된 메시지 구조로 패키징되어야 함- 수신한 문서는 수신 후에 유통 프로토콜에 정의된 메시지 구조에 의해 검증,파싱되고 필요한 정보가 추출되어야 함
6 유통증명서 발급 및 관리 - 유통 메시징서버는 문서 송수신 사실에 대한 내용을 증빙할 수 있도록 유통증명서를 발급하고 이를 관리해야 함 - 발급된 유통증명서를 수신하자마자 제3자 보관기관에 보관, 의뢰- 유통증명서 이력정보 : 유통증명서id, 발급시각, 관련 메시지id, 유통증명서 원본(선택적), 제3자 보관기관에 보관 후 수신한 제3자 보관기관의 등록증명서 등 - '전자문서 유통증명서' 기술규격 참조
7 주소 디렉터리 서버 연계 - 주소 디렉터리 서버가 제공하는 주소정보 등록 및 검색 프로세스에 따라 주소정보를 관리할 수 있어야 함- 주소 디렉터리 서버가 제공하는 서비스를 호출할 수 있는 클라이언트 기능이 있어야 함- 주소 디렉터리 서버가 제공하는 주소정보 등록, 검색, 수정, 삭제 기능을 원격에서 호출하는 서비스 클라이언트 기능이 제공되어야 함
8 제3자 보관기관 연계 - 유통 메시징서버는 유통증명서의 보관요청을 위해 제3자 보관기관 외부에 설치되어 있는 유통 메시징서버에 보관요청 메시지를 전송- 제3자 보관기관의 유통 메시징서버는 제3자 보관기관에 유통증명서 보관을 위한 보관요청 클라이언트를 호출- 제3자 보관기관의 유통 메시징서버가 직접 유통증명서를 생성한 경우에는 생성시점에 보관요청 클라이언트를 호출 - 보관요청 클라이언트는 제3자 보관기관의 연계인터페이스 규격에 따라 제3자 보관기관에 보관을 요청함
9 내부 시스템 연계 인터페이스 - 유통 메시징서버가 유통 클라이언트가 아니라 기업 내부 시스템일 경우, 기업 내부 시스템과 직접 연계될 수 있는 기능들을 제공하여야 함
10 유통 클라이언트 관리 - 유통 클라이언트와 관련된 사용자 계정관리, 사용자 인증, 환경정보 등을 관리
11 부가 기능 관리 - 메시지 유통과 관련된 이력 및 통계정보 등 - 시스템 관리 : 시스템 모니터링 등 - 환경정보 관리 : 유통 메시징서버 전체에 대한 환경정보 관리와 사용자별로 환경설정 기능 등을 제공하여야 함 - 문서양식(Form) 관리
12 메시지 보존 관리 - 1년 이상 보관된 메시지들을 자동으로 보존하기 위해 외부 저장장치에 이관하는 시스템 기능
위의 표 4에 개시된 기능 이외에, 유통 메시징서버의 신뢰성을 제고하기 위해서는 서버 시스템 관리에 있어서 다음 ① 내지 ④와 같은 원칙을 준수하여야 한다.
① 시스템 관리자는 개인의 메시지함을 보거나 임의로 삭제할 수 없어야 함
② 서버 시스템 관리와 관련된 이력정보는 임의로 삭제할 수 없어야 하며, 불변경 매체 등에 10년 이상 보관하여야 함
③ 시스템 관리자는 인증된 유통 메시징서버 솔루션의 기본 기능 등을 임의로 변경할 수 없음
④ 시스템 관리와 관련된 업무 지침을 작성하여 그에 따라 관리가 이루어져야 함
② 유통 클라이언트
유통 클라이언트는 유통체계 내에 참여하는 송수신자들을 위해 메시지 송신 및 수신, 수신된 전자문서 열람 및 관리 등의 UI(User Interface)를 제공하는 어플리케이션이다. 유통 클라이언트는 독자적으로 문서를 송수신할 수 없으며, 반드시 유통 메시징서버와 연계되어야 한다.
유통 클라이언트는 유통 메시징서버를 통하여 메시지 전송을 요청하거나, 유통 메시징서버를 통해 수신된 메시지를 조회한다. 유통 메시징서버는 사용자 계정별로 메시지함을 관리하게 되며, 유통 클라이언트는 수신문서 중 사용자 계정정보 확인을 통해 본인 계정에 보관되어 있는 메시지에만 접근이 가능하여야 한다.
유통 클라이언트는 송수신 개체의 요구에 의해 C/S 형태의 어플리케이션 또는 웹 형태의 화면으로 구현될 수 있다.
유통 클라이언트의 기능 개념도는 도 3과 같으며, 기능에 대한 설명은 아래 표 5와 같다.
표 5
번호 기능명 설명
1 사용자 인증 - 유통 클라이언트는 유통 메시징서버로부터 사용자 계정을 확인한 후 로그인 세션 정보를 받아야 함- 유통 클라이언트가 사용자 인증을 받기 위한 방법으로는 1)인증서를 기반으로 한 사용자 인증 또는 2)ID/PW를 기반으로 한 사용자 인증 등이 있음 - ID/PW 기반으로 운용시, PW에 대한 보안 정책을 강제할 수 있어야 함. 1주 단위의 PW변경, 어려운 문자/숫자 조합, IP주소 변경 금지 등
2 메시지 생성 - 유통 클라이언트는 신규 메시지를 작성할 수 있는 사용자 인터페이스를 제공하여야 함 - 메시지를 전송하기 위해 필요한 기본정보들 중 환경정보에 의해 기 설정된 값이 아닌 항목은 입력할 수 있도록 제공- 메시지 본문은 필수 항목은 아니며, 선택적으로 본문을 추가,작성할수 있음
3 메시지 목록 조회 및 상세내용 열람 - 유통 클라이언트는 사용자 계정에 해당하는 각 메시지의 목록을 조회하는 기능을 제공하여야 함- 첨부문서를 포함하여, 메시지의 상세정보를 열람할 수 있는 기능을 제공하여야 함
4 메시지 폴더 관리 - 유통 클라이언트는 유통 메시징서버의 메시지함을 기반으로 송신과 수신 메시지를 유통 메시징서버가 제공하는 상태정보에 따라 사용자에게 각 메시지의 상태를 알려주어야 함 - 임시보관함, 지운 메시지함을 제공하거나 사용자가 직접 메시지 폴더를 정의하고 관리할 수 있도록 하는 기능을 제공하는 것은 선택사항
5 기본정보 및 환경정보 관리 - 유통 클라이언트는 메시지 송수신과 관련해서 필요한 환경정보를 관리하는 기능을 제공하여야 함 - 유통 클라이언트는 유통 메시징서버에서 관리하고 있는 환경정보와 동기화되어야 함. 아울러, 유통 메시징서버의 개별 환경정보를 설정하고 관리하는 기능 제공 - 유통 클라이언트의 시스템 환경에 대한 부가정보 관리는 어플리케이션의 개발범위에 따라 정의하여 제공
6 문서 작성 - 등록되어 있는 전자문서 서식을 불러와서 전자문서를 작성하는 기능
7 메시지 송신 요청 & 수신 메시지 Get - 유통 클라이언트는 사용자 계정 정보를 바탕으로 유통 메시징서버와의 연계 인터페이스를 통해 메시지 송신기능과 수신메시지 가져오기 기능을 수행하여야 함
8 메시지 보안 처리 - 전자서명 또는 암호화/복호화 등 메시지에 대한 보안 처리를 할 수 있어야 함
9 문서 서식 등록 및 검색 - 전자문서 서식등록기 또는 외부에 위치해 있는 전자문서 서식을 유통 클라이언트로 등록할 수 있는 기능 - 유통 클라이언트 내에 있는 전자문서 서식을 검색할 수 있는 기능
10 주소록 관리 - 자주 사용하는 공인전자주소 등을 관리하는 기능- 수신한 메시지를 통해 자동으로 공인전자주소를 등록,관리하는 기능을 선택적으로 구현
11 기업내 시스템과 연계 - 메시지 내의 전자문서를 기업 내의 그룹웨어, 업무관련 시스템에 등록시키는 등의 연계 기능
12 메시지 보존 관리 - 정책적으로 설정해 놓은 보관연한이 지난 메시지의 보존을 위해, 외부 저장장치 등에 이관하는 기능- 이 경우, 메시지와 관련된 문맥을 파악할 수 있도록 유통증명서, 로그정보 등 관련 정보까지 포괄적으로 보존 처리되어야 함
13 스팸 신고 - 스팸 등 부적절한 목적으로 수신된 메시지를 신고하는 기능
14 문서 열람 지원 - 선택적 기능으로, 송신 개체의 시스템 또는 제3자 보관기관에 전자문서를 보관하고, 이를 열람할 수 있는 권한만 전송하는 기능- 수신자는 열람 권한을 가지고 전자문서를 다운로드 받지 못하고, 오직 열람만 가능
③ 주소 디렉터리 서버
주소 디렉터리 서버는 송·수신 개체와 공인 송·수신자에 대한 주소 정보를 관리하고, 물리적 주소를 제공하기 위한 시스템이다.
주소 디렉터리 서버는 다음 ① 및 ②와 같은 기본 기능을 제공한다.
① 수신 개체의 유통 메시징서버의 물리적 주소(IP 주소) 관리 및 제공
② 공인전자주소의 정보를 등록, 수정 등 관리 기능
아울러, 주소 디렉터리 서버는 화이트리스트 정보를 관리하는 기능을 기본적으로 가지며, 사용자로부터 스팸메시지에 대한 신고를 접수하고 이를 기준으로 블랙리스트 정보를 관리한다.
주소 디렉터리 서버는 웹 포탈화면을 통해 공인전자주소와 관련된 정보를 송수신 개체 또는 공인 송수신자에게 제공하며 연계 인터페이스를 통해 유통 메시징서버 및 관련 어플리케이션들이 주소 디렉터리 서버에서 제공하는 서비스를 이용할 수 있다.
주소 디렉터리 서버의 기능 개념도는 도 4와 같으며, 기능에 대한 설명은 아래 표 6과 같다.
표 6
번호 기능명 설명
1 공인전자주소 관리 - 송수신 개체 및 공인 송수신자의 공인전자주소의 신규 등록 및 변경 등 관리 - 공인전자주소를 소유한 송수신 개체의 정보 및 이력정보 열람 등
2 스팸신고 관리 - 유통 클라이언트로부터 수신한 스팸 등에 대한 신고 접수 및 결과 통지 기능 등
3 화이트/블랙 리스트 관리 - 공인전자주소 목록인 화이트리스트 생성 및 관리/보관- 화이트리스트에 대한 검색 요청 접수 및 처리 기능 - 스팸 등 부적절한 목적으로 사용한 공인전자주소에 대한 블랙리스트 생성 및 수정 등 관리 - 블랙리스트에 대한 검색 기능
4 주소정보 검색 및 물질적 주소 통호 - 유통 메시징서버로부터 요청받은 공인전자주소의 물리적 주소 요청 접수 및 이를 리턴해주는 기능 - 이와 관련된 이력정보의 검색 기능
5 웹 포털 관리 - 주소 관리와 관련된 사용자 인터페이스 제공 - 주소 관리와 관련된 시스템 관리자 인터페이스 제공- 주소 디렉터리 서버의 시스템 환경정보 관리 - 주소 관련 각종 통계정보 관리
④ 전자문서 서식등록기
전자문서 서식등록기는 송수신 개체 간에 사전에 약속된 표준전자문서를 이용하여 자동으로 처리될 수 있거나, e-Form 형태의 전자문서 등을 활용할 수 있도록 전자문서 유통허브에서 제공하는 시스템이다.
전자문서 서식 등록기는 전자문서 서식을 관리하는 서버 엔진과 유통 클라이언트가 이를 검색 및 다운로드할 수 있도록 기능을 제공하는 인터페이스와 웹 포털 인터페이스 등을 제공한다.
전자문서 서식등록기의 기능 개념도는 도 5와 같으며, 기능에 대한 설명은 아래 표 7과 같다.
표 7
번호 기 능 명 설 명
1 전자문서 서식 관리 - 전자문서 서식의 등록, 삭제, 정보 수정 등 관리 - 전자문서 등록/삭제 등과 관련된 내역 통지
2 전자문서 검색 및 수신 관리 - 전자문서 서식의 검색 기능 제공 - 검색된 전자문서 서식의 다운로드 등 수신
3 전자문서 서식 연계 인터페이스 - 유통 클라이언트와 직접 연계된 상태에서 전자문서를 검색, 다운로드하는 기능 등을 제공
4 문맥(컨텍스트) 관리 - 해당 전자문서 서식명이 똑같다고 하더라도 국가나 산업 등의 문맥(컨텍스트)에 따라 다른 서식이 사용될 수 있기 때문에 전자문서 서식을 문맥에 따라 추가 분류 - 국가, 지역, 산업, 기업, 프로세스 등 전자문서 서식이 사용될 수 있는 문맥(컨텍스트)에 대한 등록, 수정 등 관리
5 전자문서 서식 심사&평가 기능 - 사용자가 전자문서 서식을 등록하기 위해 제출하고 대기 - 평가자에 의해 평가된 이후, 정식 등록되거나 반환하는 프로세스 ※전자문서 서식, 제출 방법 등에 대해서는 추가 공지
6 웹 포털 관리 - 전자문서 관리와 관련된 사용자 인터페이스 제공 - 전자문서 관리와 관련된 시스템 관리자 인터페이스 제공- 전자문서 서식등록기 서버의 시스템 환경정보 관리 - 전자문서 서식등록기의 각종 통계정보 관리
⑤ 유통 중계서버
유통 중계서버는 전자문서 유통허브 내에 있는 시스템으로 유통체계에서 송수신 개체 간 전자문서 유통과정에서 오류가 발생하였을 때, 송신 개체를 대신하여 메시지 전송을 대행하는 시스템이다.
유통 중계서버는 내부적으로 유통 메시징서버의 기능을 내장하고 있으므로, 이를 통해 기본적인 전자문서 송수신 서비스를 제공할 뿐 아니라, 유통 중계서버만이 가지는 중계 의뢰접수 및 최종 실패시 오류 메시지 전송 등의 서비스를 연계 인터페이스를 통해 유통 메시징서버에 제공한다.
유통 중계서버의 기능 개념도는 도 6과 같으며, 기능에 대한 설명은 아래 표8과 같다.
표 8
번호 기 능 명 설 명
1 메시지 Routing 정보처리 송수신 개체에 있는 유통 메시징서버에 대한 경로 설정 기능
2 전송오류시 재처리 작업 메시지를 수신 개체에 전송 시 오류 발생시 재 전송 등의 처리를 하는 기능
3 송신증명서 발급 메시지 전송을 의뢰한 송신 개체에게 송신증명서를 발급하는 기능
4 전송실패 시 오류메시지 전송 의뢰받은 메시지 전송이 실패 시 송신개체에게 오류 메시지를 전송하는 기능
5 전자문서 중계 의뢰 유통 메시징서버와 연계된 상태에서 메시지 중계를 의뢰받는 기능
6 이력/통계 정보 관리 메시지 유통중계와 관련된 이력이나 통계 정보를 보관 및 처리하는 기능
7 중계현황 모니터링 송수신 개체에 대한 유통 중계 현황 제공 및 시스템 관리자에 의한 중계 현황 모니터링 기능
⑥ 외부 연계 게이트웨이 서버
외부 연계 게이트웨이 서버는 기존에 운용되고 있거나 유통체계 내로 포함되기 힘든 외부 시스템과 유통체계가 연계하기 위한 신뢰성 있는 통로 역할을 하는 시스템이다.
공공부문의 경우, 행정정보 공동이용센터 또는 전자문서 유통지원센터 등을 통하여 민원서류 등을 전자적으로 유통하고 있는 데, 이러한 시스템들과 연계하기 위한 채널로써 외부 연계 게이트웨이 서버가 활용되어 질 수 있다. 공공부문뿐만 아니라 기타 외부 시스템들과도 연계하기 위한 채널 역할을 수행할 수 있다.
외부 연계 게이트웨이 서버의 기능 개념도는 도 7과 같으며, 기능에 대한 설명은 아래 표 9와 같다.
표 9
번호 기능명 설명
1 유통 메시징서버 모듈 유통 메시징 서버에 있는 기능 중 일부 사용
2 검증/변환 모듈 연계되는 외부 시스템 별로 대응되는 검증/변환하는 모듈
3 전자주소 검증/변환 유통체계와 외부 연계 시스템 간 송수신 주소의 검증 및 변환 기능
4 메시지 패키지 검증/변환 유통체계와 외부 연계 시스템 간 메시지 패키지의 검증 및 변환 기능
5 전자문서 보안 검증/변환 유통체계와 외부 연계 시스템 간 전자문서에 적용된 보안의 검증 및 변환 기능
6 문서적합성 검증/변환 유통체계와 외부 연계 시스템 간 전자문서의 적합성을 검증하고 상호 간 변환하는 기능
7 시스템 관리 외부 연계 게이트웨이 서버의 시스템 관리
8 통계정보 조회 외부 연계 게이트웨이 이용과 관련한 통계정보 조회 기능
⑦ 공인전자주소
유통체계에 참여하는 송수신 개체와 공인 송수신자는 고유의 공인전자주소를 발급받아야 한다.
공인전자주소는 sharp[#], 숫자[0-9], 하이픈[-], 마침표[.]의 조합으로 구성한다.
공인전자주소의 구성 체계는 아래 표 10과 같다.
표 10
구분 공인전자주소 내용
구분자 이용자 식별기호
개인용도 # 000-0000-0000 숫자 및 하이픈으로 구성된 13자리 기호로 조합된 신청자의 임의부여 숫자
기타용도 000-00-00000 숫자 및 하이픈으로 구성된 12자리 기호로 조합된 사업자등록번호 또는 고유등록번호
공인전자주소 구성 체계와 관련된 원칙은 다음 ① 내지 ③과 같다.
① "#"의 앞부분은 이용자의 편의를 위하여 문자 [A-Z][a-z], 한글[완성된 한글 글자 2,350자], 숫자[0-9], 하이픈[-], 마침표[.]의 조합으로 구성된 이용자 추가 식별기호를 선택적으로 사용할 수 있다. 이 경우에 이용자 추가식별 기호는 전자문서 유통 메시징서버에서 자체 관리한다.
② 공인전자주소의 이용자 추가식별기호는 하이픈 또는 마침표로 시작하거나 끝나지 않아야 하며, 길이는 30바이트 이하로 한다.
③ 공인전자주소의 이용자 추가식별기호로는 사회적 관습, 미풍양속을 해치는 문자 및 숫자의 조합, 그 밖에 관리기관의 장이 정하는 제한 기호는 사용할 수 없다.
공인전자주소와 실 물리적 주소(유통 메시지서버의 실 물리적 주소)인 IP Address와는 연관관계에 대해서는 주소 디렉터리 서버를 통해서만 관리가 된다. 공인전자주소와 유통 메시지서버의 실 물리적 주소는 1:1 또는 N:1의 관계를 갖으며, 이에 따라 하나의 공인전자주소가 여러 개의 물리적 주소를 갖는 경우는 존재하지 않는다.
공인전자주소에 대한 정보(문서)의 법적 수신책임은 "#" 뒤에 존재하는 기업/기관/개인이 가져야 하며, 이용자 추가식별기호에 의한 배부는 기업/기관/개인이 편의를 위해 구분한 것이므로 송수신 개체는 이용자 추가식별기호에 의한 배포에 대해서 자체적으로 책임을 져야 한다. 이 경우 송수신 개체는 이용자 추가식별기호에 해당하는 사용자 인증에 대한 정책 및 관리 요령을 준비하여야 하며, 요령에 따라 철저히 관리하여야 한다. 아울러, 송수신 개체는 유통체계에 참여하기에 앞서 관리기관과 서비스 레벨협약(SLA)를 체결하면서 내부 구분자를 포함한 공인전자주소 내용을 포함하여 체결하여야 한다.
유통체계 내에서 공인전자주소가 가지는 효력범위는 도 8과 같이 표현될 수 있다.
이용자 추가식별기호는 송수신 개체 내에서 고유한 값이어야 한다. 이용자 추가식별기호에 대한 부여방식은 개별 송수신 개체가 책임을 지는 것을 기본으로 하며, 이용자 추가식별기호에 의한 전자문서의 배부 역시 송수신 개체가 책임져야 하며, 문제 발생시 송수신 개체가 해결하여야 한다. 이러한 이용자 추가식별기호는 유통체계의 효력범위에 포함되지 않으나, 관리기관과의 서비스 레벨 협약(SLA) 등에 의해 규정받을 수 있다.
이용자 추가식별기호는 기업의 업무 편의를 위해 전자문서를 분배하기 위한 용도로 사용되며, 주소 디렉터리 서버에 등록하지 않고 기업 내부의 정보로서만 사용한다.
상술한 바와 같은 공인전자주소의 다른 예로서 다음과 같은 구조가 가능하다.
공인전자주소 = ID + 구분기호 + 등록자
여기서, 상기 "ID"는 영문(또는 한글, 숫자), 하이픈[-] 및 마침표[.] 등이 조합되어 구성되고, 상기 "구분 기호"는 #이며, 상기 "등록자"는 영문(또는 한글, 숫자)와 마침표[.]가 조합되어 구성된다.
이러한 공인전자주소의 일 예로서 "swconvergence#mke.go.kr" 가 있으며, 이와 같은 예를 구성함에 있어서 "swconvergence"는 정부기관의 부서명, "mke"는 정부기관, "go"는 특성, "kr"는 국가를 나타내도록 하였다.
공인전자주소의 신청/발급과 운영 체계는 도 9와 같으며, 이와 관련된 구성 요소에 대한 설명은 아래 표 11과 같다.
표 11
구성요소 역할
관리기관(공인전자주소 관리총괄) - 관리기관은 공인전자주소의 최상위 관리주체로서 협의의 공인전자주소 정보를 관리- 송수신개체 및 공인 송수신자에 대한 고유 공인전자주소 ID를 발급 및 변경 관리
등록대행기관 - 관리기관의 위임을 받아 공인전자주소 신청 및 심사를 하는 기관
송수신 개체 - 협의의 공인전자주소(등록주소)의 가장 기본이 되는 단위- 기업/기관의 경우, 하나의 공인전자주소 하위에 복수 사용자를 위한 사용자 계정 또는 이용자 추가식별기호를 발급, 관리 및 유일성 보장
(공인 또는 내부)송수신자 - 전자문서유통에 참여하는 실 사용자- 공인 송수신자는 전자문서 중계자를 통해 개설한 사용자 계정을 가진 공인전자주소를 가지며, 법적 책임을 가진 송수신 단위임 - 내부 송수신자는 송수신에 대한 법적 책임을 가진 송수신 개체 내에서 이용자 추가식별기호를 통해 관리되는 송수신 단위로서, 법적 책임을 지지 않으며, 전자주소 디렉터리 서버에 등록되지 않음
⑧ 전자문서 정보패키지
전자문서 정보패키지는 메시지 내부에 포함되어 있는 전자문서에 대한 메타데이터를 명시함으로써 그룹웨어 등과 같은 기업 내부 시스템에서 해당 전자문서를 자동으로 등록하거나 처리하는 것을 지원하기 위해 필요하다.
전자문서 정보 패키지는 메시지 유통에 반드시 필수적인 요소는 아니기 때문에 업무상 필요한 곳에서만 선택적으로 사용될 수 있다. 단, 사용 시에는 다음 ①② 및 ②와 같은 요건을 준수하여야 한다.
① 전자문서 정보패키지는 메시지에 포함되는 전자문서와 별개의 파일형태로 전송되어져야 한다.
② 전자문서 정보패키지는 XML 파일형태로 제공되어져야 한다.
전자문서 정보패키지의 메타데이터는 아래 표 12와 같다.
표 12
번호 메타 정보 필수/선택 설 명
1 전자문서 명 필수 메시지 내에 포함되어 있는 전자문서에 대한 파일명
2 전자문서 식별자 필수 전자문서를 식별할 수 있는 고유 식별자
3 전자문서 유형 구분 필수 해당 전자문서가 전자문서 서식등록기에 등록되어 있는 전자문서인지, 기업/기관 내에서 사용되는 전자문서인지, 자체 전자문서 인지를 구분하는 식별자 0 : 전자문서 서식 등록기에 있는 전자문서 1 : 기업/기관 내에서 공통으로 사용되는 전자문서2 : 자체적으로 사용되는 전자문서
4 전자문서 유형 식별자 선택 전자문서 유형 구분이 0 또는 1인 경우에, 유형을 식별할 수 있는 식별자
5 전자문서 서명 값 선택 전자문서에 대한 전자서명 값
6 기타 정보 선택 전자문서와 관련된 기타 정보
[메시지 보안]
유통체계에서 가장 중요한 부분 중의 하나가 전송 메시지에 대한 보안이다. 유통되는 메시지에 대한 보안으로는, ① 송수신 사실에 대한 부인방지, ② 전송 메시지에 대한 무결성 보장, ③ 전송 상대방에 대한 인증, 및 ④ 전송 메시지에 대한 기밀성 보장이 요구되는데, 이 가운데 ①, ②, ③은 전송 메시지에 대한 전송자의 전자서명으로 지원될 수 있으며, ④는 전송 메시지에 대한 암호화를 통해 제공되어야 한다.
유통체계의 가장 기본이 되는 유통 메시징서버 간 전자문서 유통에 있어서 적용되는 보안은 도 10과 같이 메시지 전자서명과 암호화를 지원하고 있다. 각 구간에는 전송보안을 위해 네트워크 암호화가 적용되어야 한다.
컨텐츠에 대한 전자서명은 어플리케이션 별 고유 영역으로 본 발명을 설명함에 있어서는 언급하지 않는다. 그리고, 본 발명에서는 수신자 공개키로 암호화를 하는 것이 기본이나 수신자의 인증서가 없는 경우 또는 수신자가 내부 송수신자인 경우에는 수신개체 암호화만 선택 가능하다. 또한, 메시지 전송과정에서 메시지에 대한 인증정보를 포함해서 유통 메시징서버에 전송하며, 이때 인증정보는 유통 메시징서버가 클라이언트를 인증하기 위한 용도로 주로 사용된다. 또한, 유통 메시징서버가 유통 클라이언트를 인증하기 위해 인증서 기반의 전자서명 외에 ID/PW기반, SSO(Single Sign On)에 의한 토큰정보 기반 등 다양한 인증방식을 채택할 수 있다.
이하, 전자서명 방법에 대하여 상세히 설명하면 다음과 같다.
유통 메시징서버는 다른 시스템(타 유통 메시징서버, 주소 디렉터리 서버, 유통 중계서버)과의 연계 시 반드시 자신의 공인인증서를 기반으로 전자서명이 되어야 한다. 유통체계 내 구성요소 간 연계를 위한 모든 유통 메시지는 기본적으로 전자서명이 되어야 하나, 유통 클라이언트와 유통 메시징서버 간 전자서명은 선택사항으로 인증서 기반의 사용자 인증방식인 경우에만 전자서명을 적용한다. 단, 이 경우 유통 메시징서버는 유통 클라이언트와의 유통 메시지에 대한 사용자 인증, 무결성, 송수신 사실 부인방지에 대한 모든 책임을 져야 한다.
이하, 암호화 방안에 대하여 상세히 설명하면 다음과 같다.
유통체계에서 첨부되는 문서는 보안을 위해 전송자가 암호화를 선택한 후, 전송이 가능하다. 이 부분은 문서에 대한 기밀성을 위한 부분으로 네트워크 암호화와는 구별되며, 네트워크 암호화가 적용된 경우에도 유통문서를 추가적으로 암호화를 할 수 있다.
암호화되는 구간은 도 10과 같이 ①송신자의 유통 클라이언트에서부터 수신자의 유통 메시징서버 또는 ②송신자의 유통 클라이언트에서 수신자의 유통 클라이언트까지가 될 수 있다. 수신자가 공인 송·수신자이고 공인인증서를 주소 디렉터리서버에 같이 등록해 놓은 경우에는 "② 송신자에서 수신자까지 구간"에서 암호화를 수행하고, 그렇지 않은 경우에는 "① 송신자에서 수신 개체까지 구간"에서 암호화가 수행된다.
첨부되는 문서를 암호화할 때 송신자는 "① 송신자에서 수신개체까지 구간"에서 암호화가 유지되는 경우에는 송신자의 유통 메시징서버, 수신자의 유통 메시징서버, 수신자의 유통 클라이언트 등 3단계에서 모두 복호화가 가능하도록 암호화를 하여야 한다. "② 송신자에서 수신개체까지 구간"에서 암호화가 유지되어야 하는 경우에는 송신자는 송신자의 유통 메시징서버와 수신자의 유통 메시징서버가 복호화가 가능하도록 암호화를 하여야 한다.
송신개체와 수신개체의 유통 메시징서버는 첨부된 전자문서가 암호화된 경우에는 암호화된 상태로 이력관리를 위해 보관하다가, 송수신자가 복호화된 문서를 기준으로 유통증명서를 검증하고자 할 때 복호화를 해서 검증할 수 있어야 한다. 이를 위해 유통 메시징서버는 폐기된 인증서의 개인키 및 개인키 접근을 위한 비밀번호를 계속 관리하여야 한다.
이하, 암호와 방안에 있어서 암호화 개요를 설명하면 다음과 같다.
유통체계에서 유통되는 메시지가 송신자에 의해 기밀성을 보장해야 한다고 판단된 경우에는 반드시 다음과 같은 암호화 과정을 준수해야 한다.
암호문은 국내외에서 각종 표준으로 이용되는 IETF RFC 3852 "CMS(Cryptographic Message Syntax)"에서 제시하는 ContentInfo 구조체로 표현된 Enveloped-Data Content Type을 사용한다.
※RFC 3852 CMS
1) IETF는 TCP/IP와 같은 인터넷 운영 프로토콜의 표준을 정의하는 주체이다. IETF는 IAB(Internet Architecture Board, 인터넷의 기술적 진화에 대한 Internet Society의 감독기구)의 감독을 받으며, IETF 구성원들은 Internet Society의 개인 또는 조직의 구성원들로부터 선발된다. IETF에서 제작된 표준들은 RFC의 형태로 나타내어지며 국내외 많은 PKI 기반 솔루션(각종 인증시스템, 타임스탬프, 제3자 보관기관 규격 등)은 이러한 RFC 표준 문서를 기반으로 만들어진다.
2) CMS(Cryptographic Message Syntax)는 최초 RSA 사에 작성한 "PKCS#7 v1.5"를 근간으로 만들어졌으며, 이를 IETF에서 규격화한 RFC 표준으로 작성한 것이 RFC2630이다. 최초 PKCS#7에는 key transfer(암호화에 이용된 대칭키를 RSA를 이용하여 상대방에게 전달) 방식만이 있었으나 RFC2630의 CMS에서는 key agreement(DH 알고리즘을 이용하여 키를 전달하는 방식) 등이 추가되었다.
3) 후에 알고리즘 부분을 별도 분리 및 다양한 키 관리 기법을 적용한 RFC3369가 2002년도에 제정되었으며, RFC3369의 내용 중 문제가 되는 부분이 많이 보고되었고 이를 최종 수정한 버전이 본 발명에서 적용한 RFC 3852이다.
추가 적용 표준으로, 암호문 생성 시 Content Encryption(실제 전송되는 전자세금계산서패키지)에서 사용되는 알고리즘 및 알고리즘에 해당하는 파라미터 등은 IETF RFC 3370 "Cryptographic Message Syntax(CMS) Algorithm" 및 IETF RFC 4010 "Use of the SEED Encryption Algorithm in Cryptographic Message Syntax(CMS)"을 따른다.
이하, 암호와 방안에 있어서 암호화 대상 데이터에 대하여 설명하면 다음과 같다.
도 11을 참조하면, 전달되는 메시지의 암호화 대상은 다음 ① 및 ②와 같다.
① 메시지의 두 번째 MIME에 들어가는 유통정보
② 메시지본문 내용 중 본문의 실 내용이 들어가는 <Text> 영역과 첨부문서
메시지 본문에 있는 Text 및 첨부문서는 각각 독립적으로 암호화되어 해당 위치에 수록된다.
첫 번째 암호화 대상은 수신자에게 전달하고자 하는 본문 내용으로서 XML 본문 중 <Text>항목 내의 값을 대상으로 한다.
다음은 대상 데이터의 구성방법이다. 데이터는 ASN.1 Basic Encoding Rules(BER)을 따르며 Distinguished Encoding Rules(DER)를 준수하도록 한다.
표 13
MainText ::= OCTET STRING
위 표 13의 MainText는 텍스트 형태의 본문내용이다.
두 번째 이후의 암호화 대상 데이터는 세 번째 MIME부터 첨부되는 첨부문서로서 각 첨부문서 단위로 독립적으로 암호화된 후 해당 MIME에 들어가게 된다.
다음은 대상 데이터의 구성방법으로, 데이터 구성은 첫 번째 암호화 방식과 동일하게 ASN.1 Basic Encoding Rules(BER)을 따르며 Distinguished Encoding Rules(DER)를 준수하여야 한다.
표 14
AttachedDoc ::= URL
위 표 14의 AttachedDoc는 binary 형태의 첨부되는 문서이다.
이하, 암호와 방안에 있어서 암호화 처리 절차 및 구조를 설명하면 다음과 같다.
아래 표 15는 RFC 3852의 EnvelopedData의 구성이다.
표 15
EnvelopedData ::= SEQUENCE {version CMSversion,originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,recipientInfos RecipientInfos,encryptedContentInfo EncryptedContentInfo,unprotectedAttrs [1] IMPLICIT UnprotectedAttributes OPTIONAL }
표 15에서, version은 RFC 3852의 syntax version number 구성을 따른다.
iginatorInfo는 key management 알고리즘을 이용하지 않고 CRL을 전송할 필요가 없으므로 사용하지 않는다. (RFC 3852에 정의되어 있음)
현재 이용할 수 있는 암호용 인증서의 알고리즘이 RSA이므로 RecipientInfos의 KeyTransRecipientInfo를 통해 수신자가 복호화할 수 있는 키(content-encryption key)를 전달한다.
encryptedContentInfo에는 내부에 정의된 Algorithm Identifier의 알고리즘을 기반으로 암호화한 MainText 또는 AttachedDoc를 넣어준다.
unprotectedAttrs는 이 버전에서는 별도로 이용하지 않으므로 송신자측에서 관리의 목적으로 값을 넣어줄 수 있으나 수신자 측에서는 이를 풀어보거나 값을 이용할 필요는 없다.
다음 ① 및 ②는 RFC 3852의 EnvelopedData의 생성에 있어 주요 부분에 대한 설명이다.
① EncryptedContentInfo의 생성
표 16
EncryptedContentInfo ::= SEQUENCE {contentType ContentType,contentEncryptionAlgorithm ContentEncryptionAlgorithmIdentifier,encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }
- ContentType은 id-data(암호화된 데이터가 어떤 정보인지를 알려주는 구분자-OID- 정보임)를 넣는다.
- contentEncryptionAlgorithm은 실제 암호화에 이용된 대칭키 알고리즘 정보를 넣는다.
- encryptedContent의 입력은 위 정의된 TaxInvoicePackage의 DER 인코딩된 값을 contentEncryptionAlgorithm에 정의된 알고리즘 방식으로 암호화한 OCTET STRING(Binary 값)이다.
② RecepientInfo의 생성
표 17
RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfoRecipientInfo ::= CHOICE {ktri KeyTransRecipientInfo,kari [1] KeyAgreeRecipientInfo,kekri [2] KEKRecipientInfo,pwri [3] PasswordRecipientInfo,ori [4] OtherRecipientInfo }
- 복호화를 할 대상이 송신 개체, 수신 개체는 필수이며, 수신자는 공인인증서가 있는 경우에만 가능하므로 실제 RecipientInfos는 하위에 RecipientInfo를 최소 2개에서 최대 3개까지 갖게 된다.
- 암호용 인증서가 RSA를 이용하므로 ktri(상대방 RSA 공개키 등을 이용하여 데이터를 암호화한 대칭키를 보내는 방식)만을 이용하여 구성하도록 한다.
이하, 암호와 방안에 있어서 메시지에 대한 OID 정의를 설명한다.
메시지 구성을 위한 Object Identifier는 다음 ① 및 ②와 같다.
①EnvelopedData Type : RFC3852 CMS에서 실제 데이터를 전달하는 포맷은 ContentInfo라는 구조체이며 내부에 있는 데이터가 어떤 데이터인지를 확인할 수 있도록 ContentType에 넣어주는 정보이다.
표 18
- id-envelopedData- OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 3 }
②EncryptedContentInfo의 ContentType : 암호화된 데이터를 넣는 구조체인 EncryptedContentInfo 구조체에서 내부에 있는 데이터가 어떤 데이터인지를 확인할 수 있도록 ContentType에 넣어주는 정보이다.
표 19
- id-data- OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }
이하, 암호화 방안에 있어서 암호화 알고리즘을 설명한다.
암호화에서 이용되는 알고리즘은 크게 두 가지로 구분된다.
① 대상 데이터를 직접 암호화하는데 이용하는 대칭키 알고리즘
② 대칭키를 수신자만 복호화할 수 있게 전달하는 공개키 알고리즘
공개키 알고리즘은 이용되는 인증서가 GPKI 또는 NPKI 체계의 암호용 인증서이므로 RSA 기반 알고리즘을 이용하게 되며, 대칭키 알고리즘에 대해서는 반드시 아래에 속한 대칭키 암호알고리즘 세 가지(SEED, ARIA, 3DES) 중 하나를 택해서 사용해야 한다.
송신자측은 대칭키 암호알고리즘 세 가지 중 한 가지만 지원해도 관계없으나, 수신자측은 세 가지 알고리즘에 대해 모두 지원이 가능하여야 한다.
① 비대칭키 알고리즘(RSA) : 랜덤하게 생성되어 데이터를 암호화한 대칭키 정보를 상대방에게 안전하게 암호화하여 전달하는 데 이용되며, 예제는 아래 표20과 같다.
표 20
RSA Encryption- rsaEncryption- OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
② 대칭키 알고리즘(SEED, ARIA, 3DES) : 랜덤하게 생성되어 실제 전달 데이터를 암호화하는데 이용되며, 예제는 아래 표 21과 같다.
표 21
Triple-DES CBC - des-ede3-cbc- OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 7 }- Algorithm의 파라미터는 반드시 존재해야하며 parameters는 반드시 CBCParameter를 가지고 있어야 한다.또는SEED CBC- id-seedCBC - OBJECT IDENTIFIER ::= { iso(1) member-body(2) korea(410) kisa(200004) algorithm(1) seedCBC(4) - Algorithm의 파라미터는 반드시 존재해야하며 parameters는 반드시 SeedCBCParameter를 가지고 있어야 한다.또는ARIA CBC- id-aria128-cbc OBJECT IDENTIFIER ::={ iso(1) member-body(2) korea(410) gcma(100001) gpki-alg(1)aria128-cbc(20) } - id-aria192-cbc OBJECT IDENTIFIER ::={ iso(1) member-body(2) korea(410) gcma(100001) gpki-alg(1)aria192-cbc(21) } - id-aria256-cbc OBJECT IDENTIFIER ::={ iso(1) member-body(2) korea(410) gcma(100001) gpki-alg(1)aria256-cbc(22) } Algorithm의 파라미터는 반드시 존재하여야 하며 parameters는 반드시 ARIACBCParameter를 가지고 있어야 한다.ARIACBCParameter::= ARIAIV -- Initialization VectorARIAIV ::= OCTET STRING(SIZE(16))
이하, 암호와 방안에 있어서 암호화용 인증서의 획득과 검증에 대하여 설명한다.
암호문 생성을 위해서는 실제 데이터를 복호화하려는 수신자측의 인증서를 획득하여야만 가능하다. 인증서의 획득을 위해 송신자는 주소 디렉터리서 서버에 연계하여 수신자(또는 수신개체)에 대한 인증서를 획득하여야 한다. 이때 획득한 인증서가 수신개체의 인증서인지, 공인 수신자의 인증서인지에 따라 기밀성이 유지되는 구간이 달라지게 된다.
송신자는 전송메시지에 대해 암호화를 선택한 경우, 획득한 수신자(또는 수신개체)인증서를 바탕으로 암호화를 수행한 후, 수신자에게 메시지를 전송한다. 메시지 전송과정에서 오류가 발생하여 유통 중계허브에 메시지 전송을 의뢰하는 경우에도 암호화된 내용은 변경 없이 그대로 전달한다.
이하, 암호와 방안에 있어서 EnvelopedData의 구성에 대하여 설명한다.
도 12에는 실제 수신자에게 전달되는 암호화된 본문을 나타내고 있으며, 실제 값들의 연계 관계에 대해 보다 정확하게 파악할 수 있을 것이다.
- ContentInfo : RFC 3852에 표현된 것으로 RFC 3852의 구성 데이터인 SignedData, EnvelopedData, EncryptedData 등을 넣어주는 일종의 컨테이너이다. 구조체의 contentType은 content가 어떤 정보인지를 가리킨다. 본 지침에서는 id-envelopedData 라는 구분자(Object Identifier)를 넣어주어야 한다.
- EnvelopedData : 암호화 정보를 전달하기 위한 구조체(앞 절의 설명 참조)
- EncryptedContentInfo : 암호화된 정보를 보관하는 구조체이다. 구조체의 contentType은 encryptedContent가 어떤 정보인지를 가리킨다. 본 지침에서는 id-data 라는 구분자(Object Identifier)를 넣어주어야 한다. contentEncryptionAlgorithm은 SEED, ARIA, 3DES 중의 하나에 대한 구분자(OID)를 넣어주어야 하며 encryptedContent에 랜덤하게 생성된 비밀키를 이용하여 해당 알고리즘으로 암호화한 데이터를 OCTET STRING(바이너리 데이터)으로 넣어준다.
- RecipientInfo : 어떤 방법을 이용하여 수신자가 복호화할 지를 선택하는 구조체이다. 본 지침에서는 KeyTransRecipientInfo를 이용해야 한다.
- KeyTransRecipientInfo : 수신자가 복호화할 수 있도록 위에서 서술한 encryptedContent를 암호화한 랜덤한 비밀키를 수신자의 공개키를 이용하여 암호화하여 전달하는 데 이용하는 구조체이다. 암호화한 비밀키는 encryptedKey에 넣어 주며, 누구의 공개키를 이용하였는지에 대한 정보인 RecipientIdentifier 및 비밀키를 암호화하는데 이용한 알고리즘 정보인 KeyEncryptionAlgorithmIdentifier 등을 포함한다.
이하, 복호화 방안에 대하여 설명한다.
암호화된 전자문서를 수신한 수신자는 도 12를 통해 설명하는 절차를 따라 암호화된 본문과 첨부문서를 복호화한다. 수신자는 암호화된 본문과 첨부문서를 각각 복호화함으로써, 평문형태의 본문과 첨부문서를 얻을 수 있다.
- 1단계: 암호문에서 EnvelopedData 구조를 추출하고 이를 읽어 들인다.
- 2단계: EnvelopedData 구조체에서 복호용 정보 구조체(RecipientInfo)를 추출한뒤 추출한 복호용 정보 구조체로부터 암호화된 대칭키 정보(KeyTransRecipientInfo)를 얻는다.
- 3단계: 수신자는 암호화된 대칭키 정보로부터 추출한 encryptedKey를 수신자의 개인키(인증서의 공개키와 맵핑되는)를 통해 복호화함으로써 본문 및 첨부문서를 암호화 할 때 사용한 대칭키를 얻는다.
- 4단계: 1단계에서 추출한 EnvelopedData 구조체에서 본문 또는 첨부문서의 암호화된 구조체를 얻는다.
- 5단계: 3단계를 통해 획득한 대칭키를 이용하여 4단계에서 추출한 암호화된 본문 또는 첨부문서를 복호화 한다.
- 6단계: 최종적으로 복호화된 본문과 첨부문서를 획득한다.
[네트워크 보안]
송신자와 수신자간 유통되는 메시지의 기밀성을 위해 전자문서 유통의 전 구간(메시징송신자의 유통 클라이언트와 유통 메시징서버 간, 송신자와 수신자의 유통 메시징서버 간, 수신자의 유통 메시징서버와 유통 클라이언트 간)에서 네트워크 보안을 위해 SSL(Secure Sockets Layer)을 적용한다.
[메시지 송수신 프로세스]
유통체계 내 관계자들 간, 시스템들 간에는 다양한 업무 프로세스가 존재한다. 유통체계 내 가장 기본적인 메시지 송수신 프로세스가 있으며, 이를 지원하기 위한 여러 프로세스가 존재한다.
메시지 송수신 프로세스는 송신자와 수신자 간에 메시지를 직접 주고 받는 형태로 우편이나 e-메일과 같이 상대방에게 문서가 교환되는 프로세스이다.
송신자와 수신자간 메시지를 송수신하기 위해, ①수신자에 대한 물리적 주소 및 보안정보 획득, ②메시지 전송 및 전송확인, ③업무수신자의 수신확인, ④유통증명서 발급 및 보관의 4단계 프로세스로 이루어진다. 이때, 유통증명서에 대한 프로세스는 증빙을 받고자 하는 내용에 따라 상세 프로세스의 흐름이 달라질 수 있는데, 이에 대한 기본적인 흐름을 도 14에서 제시하고 있으며, 상세한 설명은 아래 표 22와 같다.
표 22
번호 프로세스 명 설 명
1 수신자에 대한 물리적 주소 및 보안정보 획득 ◆ 송신 개체는 상대방에 대한 주소정보를 바탕으로 실제 메시지가 전달되어야 할 물리적 주소정보 및 보안정보(송신메시지에 대한 수신암호를 필요로 하는 경우)를 주소 디렉터리 서버에 요청함으로써 이를 획득◆ 이 과정에서 주소 디렉터리 서버는 요청한 수신 개체의 공인전자주소가 블랙리스트 또는 화이트리스트에 있는 지를 확인(블랙리스트에 있을 경우, 메시지 전송 오류를 송신 개체에 통보)◆ 송신 개체의 유통 메시징서버가 주소 디렉터리 서버에 수신자에 대한 물리적 주소 및 보안정보를 요청한 후, 이를 수신
2 메시지 송수신 및 전송 확인 ◆ 송신 개체는 메시지를 기술 규격에 맞게 패키징 한 후, 유통 메시징서버의 공인인증서를 기반으로 전자서명을 수행◆ 유통 메시징서버는 앞서 획득한 물리적 주소에 패키징하고 전자서명된 메시지를 전송함◆ 메시지를 수신한 수신 개체의 유통 메시징서버는 메시지의 기본 패키징 구조, 전자서명에 대한 유효성, 송신자에 대한 적합성을 검증한 후, 수신확인을 위한 수신증명서 또는 오류메시지를 생성함◆ 수신 개체의 유통 메시징서버는 생성한 수신증명서를 송신 개체에게 전송함◆ 송신 개체의 유통 메시징서버는 수신증명서를 수신하여, 1)수신증명서의 적합성을 검증, 2)검증된 정보를 수신증명서에 첨부, 3)수신증명서를 자체 보관 및 제3자 보관기관에 보관 요청 ◆ 전송과 전송확인 과정은 동기식 메시지 처리로 이루어짐
3 업무수신자의 수신확인 ◆ 송신자가 메시지 전송시점에 수신 개체의 열람증명서를 요청한 경우, 수신 개체는 메시지 열람 시점에 송신 개체에게 열람확인을 증빙할 수 있는 열람증명서를 생성하여 이를 전송◆ 수신 개체가 송신 개체에게 열람증명서를 전송하면, 이를 수신한 송신 개체는 1)열람증명서의 적합성을 검증하고, 2)검증된 정보를 열람증명서에 첨부, 3)열람증명서를 자체 보관 및 제3자 보관기관에 보관 요청, 4)수신 개체에게 수신확인 메시지를 동기식으로 전송
4 유통증명서 발급 및 보관 ◆ 각 단계별로 유통에 대한 증빙을 받고자 하는 경우 송신 개체는 각 단계에 따라 수신, 열람, 송신에 대한 증명서를 수신 개체 또는 유통 중계서버로부터 발급받아 이를 제3자 보관기관에 보관함으로써 유통에 대한 법적증빙의 근거를 확보
메시지 송수신 프로세스는 전송 프로세스와 수신 프로세스로 구분할 수 있으며, 전송 프로세스는 유통 클라이언트와 유통 메시징서버 간의 연계 방식에 의해 동기식 전송과 비동기식 전송으로 세분화된다.
이하, 도 15 및 표 23을 참조하여 동기식 메시지 송수신프로세스에 대하여 설명하면 다음과 같다.
동기식 메시지 송수신 프로세스는 송신 개체의 유통 클라이언트가 유통 메시징서버에 전송을 요청하면 이를 수신 개체의 유통 메시징서버에 실시간 전송을 하고 이에 대한 응답을 송신자의 유통 메시징서버를 통해 동기식으로 돌려받는 프로세스이다. 동기식 프로세스는 전송에 대한 결과를 즉각적으로 유통 클라이언트가 확인할 수 있으므로 업무 프로세스에 대한 정의가 단순해질 수 있다.
이러한 동기식 메시지 송수신 프로세스에 대한 상세한 설명은 아래 표 23과 같다.
표 23
번호 프 로 세 스 명 설 명
1 수신자에 대한 물리적 주소 및 보안정보 획득 ◆ 상술한 메시지 송수신 프로세스와 동일하며, 세부 프로세스는 후술하는 물리적 주소 획득 프로세스 참조
2 메시지 전송 및 전송 확인 ◆ 송신 개체의 유통 클라이언트는 문서를 작성하여 첨부한 후 전송대상 및 방식(암호화 여부, 열람증명서 수신 여부 등)을 설정하여 송신 개체의 유통 메시징서버에 전송 요청을 하고 이에 대한 응답을 받기 위해 통신을 끊지 않고 기다림◆ 송신 개체의 유통 메시징서버는 이를 받아서 바로 수신 개체의 유통메시징서버에 전송함◆ 송신 개체의 유통 메시징서버는 수신 개체로부터 전송에 대한 응답메시지를 수신함(이에 대한 절차는 상술한 메시지 송수신 프로세스의 메시지 전송 및 전송확인 프로세스를 참조)◆ 송신 개체의 유통 메시징서버는 수신한 응답메시지를 유통 클라이언트와 연결된 통신구간을 통해 동기식으로 돌려줌
3 업무수신자의 수신확인 ◆ 상술한 메시지 송수신 프로세스와 동일
4 유통증명서 발급 및 보관 ◆ 상술한 메시지 송수신 프로세스와 동일
이하, 도 16 및 표 24를 참조하여 비동기식 메시지 송수신프로세스에 대하여 설명하면 다음과 같다.
비동기식 전송 프로세스는 송신 개체의 유통 클라이언트가 유통 메시징서버에 전송을 요청하면 유통 메시징서버에 전송요청에 유효성 여부만을 검증한 후 요청에 대한 수신확인 메시지를 유통 클라이언트에 돌려준다. 이를 수신 개체의 유통 메시징서버에 실시간 전송을 하고 이에 대한 응답을 송신 개체의 유통 메시징서버를 통해 동기식으로 돌려받는 프로세스이다.
비동기식 프로세스는 전송하고자 하는 메시지의 용량이 크거나 하나의 메시지에 대해 복수의 수신자를 지정한 경우처럼 메시지 전송에 대한 시간이 많이 걸려서 클라이언트가 응답을 기다리기 힘든 상황에서 사용한다.
이러한 동기식 메시지 송수신 프로세스에 대한 상세한 설명은 아래 표 24와 같다.
표 24
번호 프 로 세 스 명 설 명
1 수신자에 대한 물리적 주소 및 보안정보 획득 ◆ 상술한 메시지 송수신 프로세스와 동일하며, 세부 프로세스는 후술하는 물리적 주소 획득 프로세스 참조
2 메시지 전송 요청 ◆ 송신 개체의 유통 클라이언트는 문서를 작성하여 첨부한 후 전송대상 및 방식(암호화 여부, 열람증명서 수신 여부 등)을 설정하여 송신자의 유통 메시징서버에 전송 요청을 함◆ 송신 개체의 유통 메시징서버는 이를 받아서 전송요청에 대한 유효성을 검증한 후, 전송요청에 대한 수신확인을 동기식으로 유통 클라이언트에 돌려주고 통신을 종료함
3 수신자에게 메시지 전송 ◆ 송신 개체의 유통 메시징서버는 유통 클라이언트로부터 받은 전송요청 메시지를 찾아, 수신자에게 전송함◆ 송신 개체의 유통 메시징서버는 수신자로부터 동기식으로 전송에 대한 응답메시지(수신증명서 또는 오류 메시지)를 받은 후, 이를 최초에 전송요청했던 유통 클라이언트의 수신함에 넣어 둠
4 전송결과 수신 ◆ 유통 클라이언트는 유통 메시징서버에 접속하여 자신에게 수신된 메시지를 가져오기 위해 수신 메시지 Get 요청을 함◆ 수신 개체로부터 전송된 응답메시지가 있으면 유통 클라이언트는 이를 응답메시지로 수신함
5 업무수신자의 수신확인 ◆ 상술한 메시지 송수신 프로세스와 동일
6 유통증명서 발급 및 보관 ◆ 상술한 메시지 송수신 프로세스와 동일
이하, 메시지 수신 프로세스에 대하여 상세히 설명하면 다음과 같다.
문서 수신자가 유통 클라이언트를 통해 메시지를 수신하는 프로세스는 도 17과 같으며, 프로세스에 대한 설명은 아래 표 25와 같다. 수신자의 유통 메시징서버가 송신자로부터 메시지를 수신하면 이에 대한 응답으로 수신증명서를 전송하고 최종 수신자의 메시지함에 문서를 넣어 둔다.
유통 클라이언트는 수시로 유통 메시징서버에 수신된 메시지에 대한 목록을 요청하고, 새로 수신된 메시지가 있으면 수신메시지 목록을 응답 메시지로 받게 되며, 이 중 상세정보를 요청하는 메시지를 통해 수신문서를 Get한다.
표 25
번호 프 로 세 스 명 설 명
1 메시지 수신 ◆ 수신 개체는 메시지를 수신하면, 수신한 메시지에 대한 수신 응답메시지를 송신 개체에게 돌려주고, 수신 메시지를 해당 사용자의 사서함에 보관
2 수신메시지 목록 Get ◆ 수신 개체의 유통 클라이언트는 연계된 유통 메시징서버 시스템에 인증을 거친 후 수신문서를 요청◆ 수신 개체의 유통 메시징서버는 수신문서를 요청한 사용자의 사서함에 보관된 수신 문서목록을 동기식 응답으로 유통 클라이언트에 전달
3 수신문서 Get ◆ 수신자가 수신메시지의 목록에서 메시지에 대한 상세정보 보기를 요청하면, 유통 클라이언트는 유통 메시징서버 시스템에 해당 메시지의 첨부문서를 포함한 상세정보 전달을 요청◆ 수신 개체의 유통 메시징서버는 사서함에 보관된 수신 문서의 상세정보 및 첨부문서 원본을 유통 클라이언트에 동기식 응답으로 전달
4 열람증명서 전송(선택적 프로세스) ◆ 최초 송신자가 수신 담당자의 열람확인을 요청한 경우, 수신자의 유통 메시징서버 시스템은 사용자가 수신문서에 대한 상세정보요청을 한 시점에 해당 메시지의 송신자에게 열람증명서를 포함한 메시지를 전송◆ 단 첨부문서에 암호화가 된 경우에는 상세정보를 가져간 시점이 아니라, 사용자가 첨부문서를 복호화한 후 열람상태를 유통메시징서버에 전달한 시점에 열람증명서를 생성하여 전송자의 유통 메시징서버로 전달하여야 함. 이때 복호화과정에서 오류가 발생하면 오류에 대한 상태정보를 전달하고 수신 유통 메시징서버는 열람증명서 대신에 복호화 오류메시지를 전송자에게 전달함◆ 수신 개체의 유통 메시징서버는 송신 개체의 유통 메시징서버로 부터 전송한 열람증명서 메시지(또는 오류메시지)에 대한 수신 응답메시지를 수신
[물리적 주소 획득 프로세스]
유통체계에 참여하는 송신 개체는 상대방에게 메시지를 전송하기 전에 공인전자주소 정보를 바탕으로 물리적인 실 주소 정보를 반드시 알아야 하며, 부가적으로 첨부하는 문서를 암호화하기 위해서는 주소 디렉터리 서버에 있는 수신자의 공개키 정보를 획득하여야 한다.
공인전자주소의 물리적 주소를 획득하는 절차는 필수 단계로서 아래 1) 내지 4)가 있다.
1) 송신 개체는 수신 개체의 주소정보를 기준으로 수신 개체에 대한 물리적 주소정보 및 보안정보 획득을 위해 주소 디렉터리 서버에 질의
2) 주소 디렉터리 서버는 송신 개체의 질의를 수신/검증한 이후, 이를 처리
3) 송신 개체는 수신받은 물리적 주소를 기준으로 경로설정을 하여 수신 개체에 메시지 전송
4) 수신 개체의 유통 메시징서버는 이를 받아서 사용자 계정 또는 내부 구분자에 따라 메시지를 내부적으로 분배
또한, 유통체계에서 공인전자주소의 물리적 주소를 획득하는 방식은 2가지로 구분할 수 있으며, 아래 ① 및 ②와 같다.
① 유통 클라이언트가 수신자의 주소정보를 입력하는 시점에 주소 디렉터리 서버에 검색 요청을 하여 물리적 주소와 수신자 공개키를 가져오는 방식 : 1)공인전자주소의 유효성을 사전에 체크하기 위함, 2)유통 클라이언트와 유통 메시징서버(송신 개체) 간 메시지 암호화가 필요할 때
② 유통 클라이언트가 유통 메시징서버에게 메시지 송신을 요청한 이후, 유통 메시징서버가 주소 디렉터리 서버로부터 물리적 주소를 가져오는 방식
공인전자주소의 물리적 주소 및 보안정보 획득의 프로세스는 도 19와 같다.
[유통 중계 지원 프로세스]
유통체계는 송신개체와 수신개체 간 직접 통신(P2P)을 기본으로 한다. 그러나 부가적으로 네트워크, 수신 개체의 유통 메시징서버의 오류 등에 의해 메시지 유통이 장애가 발생하였을 경우, 사용자의 편의 및 유통의 원활한 지원을 위해 유통을 중계/대행하는 중계 프로세스를 제공한다.
송신 개체가 메시지를 수신 개체에게 전송하는 과정에서 오류가 발생하여 전송이 실패하는 경우에 전자문서 유통허브 내 유통 중계서버는 송신 개체를 대행해서 메시지를 위탁/전송함으로써 송신 개체의 전송 사실을 입증하고 송신 개체의 시스템적인 부담을 덜어주는 역할을 수행한다.
도 23은 이에 대한 기본적인 흐름을 제시하고 있으며, 도 24는 유통 중계서버가 메시지를 중계하는 프로세스를 보여주고 있다.
아래 표 26은 유통 중계 프로세스를 단계적으로 설명하고 있다.
표 26
번호 프 로 세 스 명 설 명
1 메시지 송신 대행 요청 ◆ 송신개체는 메시지 패키징 및 보안처리 후 수신개체에게 메시지 전송 ◆ 전송과정에서 오류가 발생하여 전송이 최종적으로 실패되었을 때 송신개체는 유통 중계서버에 메시지를 대행해서 전송해 줄 것을 의뢰◆ 전송의뢰를 접수한 유통 중계서버는 송신개체에게 송신증명서를 동기식으로 발급,전송
2 메시지 위탁 중계 ◆ 유통 중계서버는 중계의뢰를 받은 메시지를 전송. 전송 실패 시 일정 간격으로 재 시도를 함(재시도 횟수 및 간격은 유통 중계서버의 정책에 따라 결정)◆ 유통 중계서버가 전송에 최종적으로 실패할 경우, 메시지 중계를 의뢰한 송신개체에 전송실패 메시지를 전달
3 수신 및 열람 증명서 발급 ◆ 수신개체가 메시지를 정상적으로 수신한 이후, 수신증명서를 유통 중계서버에 전송 ◆ 수신자가 전자문서를 열람한 이후, 수신개체는 열람증명서를 유통 증계서버를 경유하지 않고 송신개체에 직접 전송
[유통증명서 등 보관 프로세스]
유통체계 내에서 이루어지는 모든 유통행위와 관련하여 그 결과로써, 유통증명서는 반드시 생성되어 제3자 보관기관에 보관되어져야 한다. 이는 유통증적을 담은 유통증명서를 법적으로 인정받은 제3자 보관기관에 보관함으로써, 유통사실에 대한 법적 추정력을 확보받을 수 있기 때문이다.
유통증명서를 보관하는 프로세스는 전자문서 유통과는 별개의 프로세스로서, 유통행위 사실을 증명하기 위한 지원 프로세스이다. 이를 위해서, 모든 유통 메시징서버는 사전에 유통증명서를 수신, 보관할 수 있는 기능을 갖춘 특정 제3자 보관기관에 가입되어 있어야 한다.
아울러, 송신 개체가 전자문서 내용증명을 원할 경우, 유통증명서 이외에 메시지 전체를 제3자 보관기관에 보관할 수도 있다.
제3자 보관기관이 유통증명서를 수신하여 보관하기 위해서는 다음 ① 및 ②와 같은 2개의 부가적인 시스템을 구비하여야 한다.
① 제3자 보관기관 사업자의 유통 메시징서버 : 유통체계 내의 유통 메시징서버와 유통증명서를 송수신 하기 위해 필요한 시스템
② 제3자 보관기관 연계 클라이언트 모듈 : 제3자 보관기관 사업자의 유통 메시징서버를 통해 수신한 유통증명서를 제3자 보관기관에 보관하기 위해 제3자 보관기관 연계인터페이스와 통신하기 위한 모듈
단, 제3자 보관기관 사업자가 전자문서 중계자를 겸할 경우, 유통 메시징서버는 추가적으로 필요하지 않을 수 있다.
도 28은 송수신 개체와 제3자 보관기관 사업자 간 유통증명서를 보관하는 프로세스를 보여주고 있으며, 유통증명서 보관 프로세스를 단계적으로 살펴보면 아래 표 27과 같다.
표 27
번호 프 로 세 스 명
1 송신자의 유통 메시징서버는 수신자의 유통 메시징서버로부터 유통증명서 수신◆ 수신 유통 메시징서버로부터 수신증명서를 받거나 중계허브로부터 송신증명서를 받는 경우는 응답메시지로 유통증명서를 수신◆ 수신 유통 메시징서버로부터 열람증명서를 받거나 중계허브를 통해 수신증명서를 받는 경우는 요청메시지로 유통증명서를 수신
2 - 수신받은 유통증명서를 검증하여 유효성이 확인되면, 유통증명서와 증명서 검증정보를 사전에 설정된 제3자 보관기관의 유통 메시징서버로 전송 - 유통증명서가 유효하지 않으면, 수신자의 유통 메시징서버에게 유통증명서 검증오류 메시지를 통지하여 재전송 요청 ◆ 요청메시지로 유통증명서를 받은 경우는 이에 대한 응답메시지로 검증오류 메시지를 전송(동기식)◆ 응답메시지로 유통증명서를 받은 경우는 새로운 요청메시지로 검증오류 메시지를 전송(비동기식)◆ 유통증명서 검증오류 메시지를 받은 경우에는 새로운 요청 메시지로 유통증명서를 재전송하거나 증명발급 실패 메시지를 전송(비동기식)◆ 유효한 유통증명서를 받지 못한 경우에는 전자문서 전송에 실패한 것으로 보고 전자문서를 다시 전송하여야 함
3 제3자 보관기관의 유통 메시징서버는 제3자 보관기관 보관요청 메시지를 수신하면, 유통증명서 및 검증정보 보관을 위한 보관요청 Client를 호출(제3자 보관기관이 전자문서 중계자를 겸하고 있을 경우, 유통 메시징서버가 제3자 보관기관 보관요청 Client를 직접 호출함(로컬 보관요청))
4 유통증명서 보관요청 Client는 제3자 보관기관의 연계인터페이스 규격에 따라 유통증명서와 검증정보를 제3자 보관기관에 보관 요청
[공인전자주소 등록 등 관리 프로세스]
송수신 개체들이 유통체계에 참여하기 위해서는 공인전자주소를 신청하여 등록받아야하며, 등록대행기관 및 관리기관은 공인전자주소와 관련된 정보를 등록 등 관리하여야 한다. 공인전자주소정보 관리 프로세스에는 공인전자주소와 관련된 등록, 변경, 삭제 등에 대한 관리 프로세스와 블랙리스트/화이트리스트 관리 프로세스가 있다.
관리기관은 공인전자주소의 효율적인 관리를 위해 공인전자주소 등록대행기관을 두어 공인전자주소를 관리한다.
등록대행기관은 다음 ① 내지 ④와 같은 업무를 수행한다.
① 공인전자주소 신청자의 신원확인 등 심사 업무
② 공인전자주소 등록자의 등록정보 변경 업무
③ 공인전자주소 등록 말소 등 업무 지원
④ 기타 공인전자주소 관리와 관련된 업무
관리기관은 등록대행기관으로 제3자 보관기관 및 전자문서 중계자 중에서 요건을 만족하는 자를 선정할 수 있다.
이하, 공인전자주소 등록 프로세스에 대하여 설명하면 다음과 같다.
유통체계에 참여하고자 하는 기업/기관/개인 등은 공인전자주소를 신청해야 하며, 등록대행기관은 신청된 정보를 심사, 처리하여 결과를 통보하여야 한다. 이와 관련된 프로세스는 도 22와 같다.
이하, 공인전자주소 등록정보의 변경 프로세스에 대하여 설명하면 다음과 같다.
기 등록된 공인전자주소와 관련된 정보는 여러 가지 사정으로 변경할 수 있으나, 다만 공인전자주소와 소유자 정보는 동일성을 유지하여야 하기 때문에 변경할 수 없다.
공인전자주소와 관련된 정보 변경에 대한 권한은 등록대행기관에 위임하여 처리하도록 한다. 단, 정보 변경에 대한 이력정보를 관리기관과 등록대행기관 간 서비스 레벨협약(SLA)에 따라 보관하여야 한다.
이와 관련된 프로세스는 도 23과 같으며, 도 23을 참조하면, 공인전자주소의 변경은 본인만이 가능하다. 개인의 경우, 공인전자주소, 등록번호, 이름은 변경불가하기 때문에 공인전자주소를 탈퇴하고 신규로 생성하여야 한다. 그리고, 기업의 경우, 공인전자주소는 변경 불가하며, 등록번호(사업자 등록번호) 및 상호명은 변경시, 반드시 해당 정보로 변경되어 받은 신규 공인인증서와 같이 변경하여야 한다.
도 24에는 등록대행기관 변경 프로세스를 나타내고 있으며, 이와 같은 도 24를 참조하면, 등록대행기관을 변경하고자 하는 경우에는 1)기존 등록대행기관으로부터 탈퇴, 2)신규 등록대행기관을 통한 신규 등록과정을 거쳐야 한다. 이 경우, 주소 디렉터리 서버에 공인전자주소 일시 유보를 요청할 수 있어야 한다. 주소 디렉터리 서버는 모든 공인전자주소 탈퇴 시, 공인전자주소 일시 유보를 선택할 수 있도록 함으로써 등록대행기관 변경 시 일정기간 동안 공인전자주소를 유지할 수 있도록 한다.
이하, 공인전자주소 갱신 및 사용정지, 삭제 프로세스에 대하여 설명하면 다음과 같다.
기 등록된 공인전자주소는 설정한 사용연한에 맞춰 갱신하여야 한다. 공인전자주소 등록 이후, 서비스 정책에 기반하여 설정해 놓은 사용연한이 지나기 전에 소유자가 갱신하여야 한다. 만약 소유자가 갱신하지 않으면, 공인전자주소에 대한 소유권을 잃게 되고 공인전자주소는 자동 말소된다.
아울러, 공인전자주소의 만료기간이 되지 않더라도 신청자가 사용정지나 말소를 원할 경우, 이에 대한 기능을 제공해주어야 한다.
[전자문서 서식 적용 프로세스]
이 프로세스는 메시지 유통 이후 단계의 활용도를 높이기 위한 프로세스이다. 메시지 내에 포함되어 있는 전자문서를 기업 내부 시스템에서 자동 또는 반자동화된 방식으로 처리하기 위함이다. 유통 메시징서버는 당사자간 메시지 송수신 기능을 전담하며, 유통 클라이언트는 송수신하기 위한 메시지를 송수신자가 이용하기 쉽도록 인터페이스를 제공해준다. 그 이후 단계는 메시지 내에 있는 전자문서를 활용하는 단계이다. 전자문서 서식등록기나 전자문서 서식은 전자문서 활용단계를 보다 효율적으로 운용하기 위한 방법 등을 제공한다.
유통체계를 따라 유통되는 문서의 양식에는 제한이 없다. 이미지, 오피스 문서, 동영상 등이 가능하나, 사용자의 편의성을 높이기 위해 유통체계에서는 서식형태의 문서 작성 기능을 부가적으로 제시한다.
이와 같은 부가기능은 전자문서교환(EDI) 기능을 도입한 것으로, 송수신 개체 간에 약속된 전자문서 포맷을 기반으로 문서 데이터를 송수신하여 수신 개체 내부시스템에서 수신한 전자문서를 자동으로 변환처리할 수 있도록 하였다.
전자문서의 서식은 다음 ① 및 ②와 같은 2가지 방식으로 활용 가능하다.
① 전자문서 유통허브에 있는 전자문서 서식등록기를 활용하는 방식으로 전자세금계산서와 같이 표준화된 전자문서 서식을 주로 사용
② 송수신 개체 간 합의된 전자문서 서식을 공유하여 활용하는 방식으로 특정 기업에 특화된 비표준화된 전자문서 서식을 주로 사용
이하, 전자문서 서식등록기 활용에 대하여 상세히 설명하면 다음과 같다.
기업, 기관이나 개인사용자는 전자문서 서식등록기에 등록된 전자문서 서식을 검색한 후, 유통 클라이언트에 등록해서 사용할 수 있다. 전자문서 서식등록기를 활용하는 방식은 다음 ① 및 ②와 같은 2가지 방식이 있다.
① 유통 클라이언트에서 직접 전자문서 서식등록기에 있는 전자문서를 검색하여 가져오는 방식
② 전자문서 서식등록기 사이트에서 전자문서를 검색하여 로컬 PC에 다운로드 후, 유통 클라이언트에 등록하여 사용하는 방식
전자문서 서식등록기는 표준화된 전자문서 서식을 등록/활용하기 때문에, 관리기관이 체계적으로 운영/관리하여야 하여 다음 ① 내지 ③과 같은 기준을 가질 수 있다.
① 사용자는 전자문서 서식등록기 사이트를 통해서 신청하여야 한다. 신청은 사이트에서 제공하는 포맷과 절차에 따라야 한다.
② 등록/신청한 전자문서는 관리기관의 심사를 거쳐 등록되어야 한다.
③ 각각의 전자문서는 체계적인 컨텍스트(문맥) 기반에서 분류되어야 한다.
표 28
구 분 설 명 비 고
지 역 해당 전자문서가 국제적으로 유통될 수 있는지, 특정 지역에서 유통될 수 있는지, 특정 국가에서만 유통될 수 있는 지 구분
구 문 해당 전자문서에 적용된 구문이 EDIFACT 기반인지, XML 기반인지, 사설 포맷인지 구분
산 업 해당 전자문서가 특정 산업에만 적용될 때 사용. 예를 들어 구매주문서가 무역부문에서 사용되는 지, 아니면 제조 또는 유통, 물류부문에서 사용되는 지 구분
제 품 해당 전자문서가 특정 회사 제품 포맷을 사용할 경우. PDF 포맷인지, 특정 회사 e-Form 포맷인지 등 구분
기 업 해당 전자문서가 특정 기업에만 사용할 수 있는 경우 구분
기 타 위의 구분이외에 다른 컨텍스트(문맥)로 구분할 수 있을 경우
도 25에는 전자문서 서식등록기를 활용하는 프로세스에 대한 기본적인 흐름을 제시하고 있으며, 구체적으로는 도 25a에는 전자문서 서식등록기와 유통 클라이언트가 직접 연계되는 경우를 나타내고 있고, 도 25b에는 전자문서 서식등록기 사이트를 이용하는 경우를 나타내고 있다.
아래 표 29에는 유통 클라이언트와 직접 연계되어 서식을 활용하는 프로세스에 대하여 나타내었다.
표 29
번 호 구 분 설 명
1 전자문서 서식 검색 유통 클라이언트에서 바로 전자문서 서식등록기에 있는 전자문서 서식을 검색
2 서식 가져오기 서식을 찾았을 경우, 이를 유통 클라이언트로 가져옴
3 서식 등록 유통 클라이언트로 가져온 서식을 유통 클라이언트에 등록
4 전자문서 서식 불러오기/작성 유통 클라이언트에 등록되어 있는 전자문서 서식을 불러와서 전자문서를 작성하고 이를 메시지에 첨부
아래 표 30은 전자문서 서식등록기 사이트를 활용하는 프로세스에 대하여 나타내었다.
표 30
번 호 구 분 설 명
1 전자문서 서식 검색 전자문서 서식등록기 사이트에 접속하여 필요로 하는 전자문서 서식을 검색
2 서식을 로컬PC에 저장 검색된 서식을 다운로드하여 로컬PC에 저장
3 서식 등록 로컬 PC에 저장된 서식을 유통 클라이언트에 등록
4 전자문서 서식 불러오기/작성 유통 클라이언트에 등록되어 있는 전자문서 서식을 불러와서 전자문서를 작성하고 이를 메시지에 첨부
이하, 합의된 전자문서 서식 활용에 대하여 설명하면 다음과 같다.
특정 기업에 한정된 서식을 기업이 운영하는 사이트 등에서 시식을 배포하여 특정 기업과 관련된 당사자들과 거래를 하기 위한 목적으로 사용하기 위함이다.
도 26은 합의된 전자문서 서식을 이용하는 절차를 나타내고 있으며, 도 26과 관련된 프로세스에 대한 설명은 아래 표 31과 같다.
표 31
번 호 구 분 설 명
1 전자문서 서식 배포 기업 A는 자신의 시스템에서 처리할 수 있는 전자문서 서식을 자신이 운영하는 웹사이트에 배포하여 거래하는 기업에서 이를 활용할 수 있도록 지원
2 서식을 로컬PC에 저장 기업 B2는 웹사이트에서 서식을 다운로드하여 로컬PC에 저장
3 서식 등록 로컬 PC에 저장된 서식을 기업B의 유통 클라이언트에 등록
4 전자문서 서식 불러오기/작성 유통 클라이언트에 등록되어 있는 전자문서 서식을 불러와서 전자문서를 작성하고 이를 메시지에 첨부
5 메시지 전송 유통 메시징서버를 통하여 메시지를 전송
6 첨부된 전자문서의 자동/ 반 자동 처리 수신받은 메시지에 첨부되어 있는 전자문서를 변환 등의 처리를 통하여 기업A의 내부 시스템에 자동 또는 반자동으로 등록
[스팸 메시지 처리 프로세스]
유통체계에서 송신자는 인증된 유통 메시징서버를 통해 전송을 하고, 수신자 역시 이를 통해 수신하므로 스팸이 발송되었을 때 송신자에게 책임을 물을 수 있는 기반구조를 가지고 있다.
그러나, 특정 송신자가 전자문서 중계자에 사용자 계정을 개설하고 이를 이용해서 상업적인 목적을 위한 메시지 등을 전송하는 경우가 있을 수 있다. 현재의 인증방식이 시스템의 기술적 내용에 대한 인증만을 대상으로 하고 있어서 스팸 메시지 등을 초기에 원천적으로 봉쇄하기가 쉽지 않은 상황이다.
이러한 스팸 메시지 등의 유통을 차단하기 위해서, 유통체계에서는 인증목록 관리 기반의 화이트리스트, 스팸이나 악의적인 의도를 가진 블랙리스트를 관리할 수 있는 체계를 제공하여 유통체계의 안전성과 신뢰성을 제고하도록 한다.
스팸메시지 신고 및 송신 상대방에 대한 확인을 위한 기능은 필수기능으로 모든 유통 메시징서버는 이 기능을 반드시 구축하여야 한다.
이하, 스팸 메시지 신고방안에 대하여 설명하면 다음과 같다.
스팸 메시지 신고절차를 단계적으로 살펴보면 아래 표 32와 같다.
표 32
번호 프 로 세 스 명
1 수신자가 메시지를 수신한 시점에서 스팸메시지라고 판단되면, 수신자는 유통 메시징 서버를 통해 주소 디렉터리 서버에 해당 메시지를 수신 메시지로 신고함
2 유통 메시징서버로부터 스팸메시지 신고를 접수한 주소 디렉터리 서버는 접수되었음에 대한 확인메시지를 되돌려 줌
3 주소 디렉터리 서버를 관리하는 주체인 관리기관은 해당 메시지를 분석하고, 송신자에 대한 조사를 통해 송신자의 공인전자주소에 대해 블랙리스트 추가 여부를 심사하고 판단함
4 최종적으로 블랙리스트 대상자로 확정이 되면, 주소 디렉터리 서버는 해당 공인전자주소를 블랙리스트에 추가한 후, 송신자에게 블랙리스트 추가에 대한 내용을 통지함
5 주소 디렉터리 서버는 스팸메시지 요청에 대한 처리 결과를 스팸신고자(수신자)에게 전달함
수신자는 수신한 메시지가 스팸메시지라고 판단이 되면 도 27과 같은 프로세스에 의해 스팸메시지를 주소디렉터리 서버에 신고한다.
화이트리스트와 블랙리스트의 역할은 다음과 같다.
① 화이트리스트 : 송신 유통 메시징서버가 인증을 받고 정식으로 등록된 메시징서버에 대한 정보만 기록됨
② 블랙리스트 : 전송자의 주소가 스팸발송자로 등록된 경우 블랙리스트로 등록됨
※ 동일한 유통 메시징서버를 통해 블랙리스트에 등록되는 스팸 주소가 중복 발생되는 경우, 관리기관은 유통 메시지서버에 대한 인증취소 여부를 판단한 후, 인증을 취소하고 화이트리스트에서 삭제할 수 있음.
이하, 스팸메시지 수신 시 처리 방안에 대하여 설명하면 다음과 같다.
수신 개체는 메시지 수신 시, 송신 상대방이 신뢰할만한 정당한 사용자인지 여부를 확인하기 위해 주소디렉터리 서버의 화이트리스트와 블랙리스트를 확인한 후, 수신거부를 할지 여부를 결정한다.
송신자에 대한 확인은 수신시점에 ①실시간 확인을 하거나, 수신자의 유통 메시징서버 시스템에 Cache형태로 관리하고 있는 목록을 통해 확인하는 ②주기적 확인 방법이 있다.
①실시간 확인 프로세스 : 수신 개체는 메시지를 수신하는 시점에 주소 디렉터리 서버에 송신 개체의 주소가 화이트리스트, 블랙리스트에 등록되었는지 여부를 판단한 후 메시지에 대한 수신거부 여부를 결정한다.
표 33
번호 프 로 세 스 명
1 수신자의 유통 메시징서버는 메시지를 수신하면 주소 디렉터리 서버에 정당한 사용자인지 여부를 확인하기 위해 확인요청 메시지를 전달
2 주소 디렉터리 서버는 요청 받은 사용자의 주소정보가 화이트리스트에 포함되어 있는지 여부를 확인
3 해당 주소가 화이트리스트에 없으면 주소 디렉터리 서버는 바로 확인 요청자에게 등록되지 않은 사용자임을 결과메시지로 돌려주고, 화이트리스트에 있으면 다시 해당주소가 블랙리스트에 등록된 주소인지 여부를 확인
4 주소 디렉터리 서버는 확인 요청자에게 블랙리스트 등록여부에 대한 결과 메시지를 리턴
5 수신자는 주소 디렉터리 서버로부터 송신자가 정당한 사용자가 아님(화이트리스트에 없거나 블랙리스트에 등록된 경우)으로 결과메시지를 받은 경우 수신메시지를 자체적으로 스팸메시지로 처리한 후, 주소디렉터리 서버로부터 받은 처리결과 메시지와 스팸메시지 수신이력을 기록하고 보관
6 스팸메시지에 대한 처리 이력은 반드시 한달 이상 보관함으로써, 해당 송신자에 대한 수신거부의 정당성을 확인
도 28은 스팸메시지를 실시간으로 확인하는 프로세스를 보여준다.
②주기적 확인 프로세스: 수신자는 주소 디렉터리 서버로부터 화이트리스트와 블랙리스트를 주기적으로 받아서 자체 관리하고 이를 기반으로 송신자의 주소가 화이트리스트, 블랙리스트에 등록되었는지 여부를 판단한 후 메시지에 대한 수신거부 여부를 결정
표 34
번호 프 로 세 스 명
1 수신 개체의 유통 메시징서버는 미리 주소 디렉터리 서버로부터 최신의 화이트리스트와 블랙리스트를 요청한 후 자체적으로 관리. 이때, 리스트의 변동사항 발생 시 자동 통지 요청여부를 같이 전달함(변동사항 발생 자동통지를 요청한 경우에도 주소 디렉터리 서버에 최신 리스트를 가져오기 위한 요청은 주기적으로 함으로써 리스트 정보가 최대한 1일 이상 차이나지 않도록 함)
2 주소 디렉터리 서버는 화이트리스트 및 블랙리스트에 변동사항이 발생하면 변동 통지요청을 한 사용자에게 변동내역을 broadcasting함
3 리스트에 대한 변동사항을 받은 유통 메시징서버는 자체 관리하는 리스트의 정보를 수정함으로써 동기화를 시켜줌
4 수신자는 메시지를 수신하면 주소 디렉터리 서버에 정당한 사용자인지 여부를 확인하기 위해 자체 관리하는 리스트를 확인
5 수신자는 자체 관리하는 리스트 점검결과 송신자가 정당한 사용자가 아님(화이트리스트에 없거나 블랙리스트에 등록된 경우)으로 판단한 경우 수신메시지를 자체적으로 스팸메시지로 처리한 후, 스팸메시지 수신이력을 기록하고 보관함
6 스팸메시지에 대한 처리 이력은 반드시 한달 이상 보관함으로써, 해당 송신자에 대한 수신거부의 정당성을 확인할 수 있도록 함
도 29는 유통 메시징서버와 주소 디렉터리 서버 간 스팸메시지 관리를 위해 주기적으로 확인하는 프로세스를 보여준다.
[오류 처리 프로세스]
유통체계에서 오류 발생 유형은 아래 ①과 ②를 포함하는 2가지로 구분된다.
① 동기식 응답에 대한 오류 발생 : 동기식 응답에 대한 오류의 경우는 요청메시지에 대한 처리결과를 받을 때까지 요청자는 대기하고 있는 상태이므로 오류를 즉각 인지 가능
② 비동기식 응답에 대한 오류 발생 : 요청자는 요청 내용만 전달한 후 그에 대한 처리결과를 차후에 받게 되므로 추가적인 오류처리가 이루어져야 함
이하, 동기식 오류처리 방안에 대하여 설명하면 다음과 같다.
동기식 전송에 대한 모든 오류는 전송자가 즉각 확인 가능하므로 재전송하는 것을 기본으로 한다. 재전송 방식에 대해서는 유통체계에 참여하는 기업이나 기관의 시스템 정책에 따라 결정되나, 동일한 메시지 전송에 대해서는 동일한 MessageId 값을 설정하여 다시 보내는 것을 기본으로 한다.
동기식 오류처리와 관련한 유형은 다음 ① 내지 ④와 같다.
① 요청메시지 송신실패 : 송신자가 메시지를 전송하는 과정에서 전송오류가 발생하여 수신자에게 요청메시지가 전달되지 못하는 경우로서, 송신자는 전송시도에 대한 timeout 또는 네트워크 오류 메시지 등을 통해 송신 실패를 인지하게 된다.
② 응답메시지 수신실패 : 송신자가 메시지를 정상적으로 전송하였으나 수신자로부터 응답메시지를 받는 과정에서 오류가 발생한 경우이다. "①요청메시지 송신실패"와 구분이 되지 않으므로 오류에 대해서 동일한 방식으로 처리하나, 수신자는 요청메시지를 정상적으로 받았기 때문에 처리 방식이 다르다.
③ 오류메시지 수신 : 송신자가 메시지를 정상적으로 전송하였으나 수신자가 메시지를 처리하는 과정에서 오류가 발생한 경우이다. 이 경우 송신자의 처리방식은 오류메시지의 유형에 따라 다르다.
④ 3단계 동기식 오류 : 유통 클라이언트가 유통 메시징서버를 통해 타 유통 메시징서버, 주소 디렉터리 서버, 유통 중계허브와 연계되는 3개의 개체 간 메시지 유통은 연계 유형 중 최종적 결과를 즉각적으로 확인하기 위해 동기식으로 연계하는 방안을 지원한다. 이 과정에서 유통 메시징서버와 수신자 간 연계단계에서 오류가 발생하면 유통 메시징서버는 즉각적으로 오류를 발생시킨 후, 이를 유통 메시징서버에 응답메시지로 전달하여야 한다.
이하, 비동기식 오류처리 방안에 대하여 설명하면 다음과 같다.
유통 클라이언트가 유통 메시징서버를 통해 타 유통 메시징서버, 주소 디렉터리 서버, 유통 중계서버와 연계되는 3개체 간 메시지 유통은 유통 클라이언트가 최종 수신자의 상황에 독립적으로 운영할 수 있도록 비동기식 방식의 연계를 지원하기도 한다.
비동기식 전송에 대한 최종 오류는 동기식 전송과 달리, 전송자가 즉각 확인할 수가 없으므로 유통 메시징서버가 최종적으로 오류를 확인한 시점에 유통클라이언트를 위한 오류 메시지를 발생시키고, 이를 유통 클라이언트가 수신할 수 있도록 하여야 한다.
[전자문서 열람서비스]
전자문서 열람서비스는 송신자와 수신자 간에 전자문서를 직접 주고 받는 교환의 형태가 아닌, 송신자의 시스템 또는 제3자 보관기관에 보관되어 있는 전자문서를 열람할 수 있도록 제공하는 서비스이다.
전자문서 열람서비스는 기존 유통체계를 그대로 이용한다. 단, 송신자는 수신자에게 전자문서를 담은 메시지를 전송하는 것이 아니라, 송신자 시스템 또는 제3자 보관기관에 보관되어 있는 전자문서를 열람할 수 있는 열람권한을 담은 메시지를 전송하는 것이 특징이다.
이와 관련된 절차는 다음과 같다.
①수신자의 공개키 획득
②전자문서의 보관
③열람권한 및 DRM 등 보안이 적용된 증서 생성
④열람권한 등 증서의 전송 및 전송확인
⑤수신자에 의한 전자문서 열람
⑥유통(열람)증명서 또는 열람증적 발급 및 보관
전자문서 열람서비스는 송신자가 자체 시스템을 사용하는 방법과 제3자를 이용하는 방법으로 구분할 수 있다.
도 30은 송신자가 자체 시스템을 활용하여 전자문서 열람서비스를 이용하는 흐름을 제시하고 있으며, 도 30에서 명시하고 있는 절차에 대하여 설명하면 아래 표 35와 같다.
표 35
번호 프 로 세 스 명 설 명
1 수신 개체 인증서의 공개키 획득 전자문서 열람 권한을 생성할 때 필요한 수신 개체 인증서의 공개키를 주소 디렉터리 서버로부터 획득
2 전자문서 보관 및 열람권한 생성 전자문서를 송신 개체의 자체 시스템에 보관
3 열람권한 및 DRM 등 보안 적용한 증서 생성 보관된 전자문서를 열람할 수 있는 권한 및 DRM 등 보안을 적용한 열람권한 증서를 생성
3 열람권한 전송 열람권한을 포함한 증명서를 수신 개체에게 전송
4 전자문서 열람 수신 개체의 수신자는 열람권한을 가지고 송신 개체의 전자문서 열람시스템에 접속하여 전자문서를 열람
5 유통(열람)증명서 보관 수신 개체의 수신자가 전자문서를 열람하였을 경우, 송신 개체는 유통(열람)증명서를 생성하고 이를 제3자 보관기관에 보관
위와 같은 서비스를 제공하기 위해서 송신자는 유통체계 이외에 전자문서 열람서비스를 제공할 수 있는 시스템을 구비하여야 한다.
도 31에는 송신 개체가 제3자를 활용하여 전자문서 열람 서비스를 이용하는 흐름을 나타내었으며, 도 31에서 제시하고 있는 절차에 대하여 설명하면 아래 표 36과 같다.
표 36
번호 프 로 세 스 명 설 명
1 수신 개체 인증서의 공개키 획득 전자문서 열람 권한을 생성할 때 필요한 수신 개체 인증서의 공개키를 주소 디렉터리 서버로부터 획득
2 전자문서 보관 및 열람서비스 의뢰 송신 개체는 전자문서를 제3자 보관기관에 보관,의뢰하고, 이에 대한 열람서비스를 의뢰(수신 개체의 공인전자주소 기재)
3 열람권한 및 DRM 등 보안이 적용된 증서 생성 제3자 보관기관 보관 의뢰받은 전자문서를 열람할 수 있는 권한증서와 DRM 등 보안이 적용된 증서를 생성
4 열람권한 증서 전송 제3자 보관기관 열람권한을 포함한 증서를 수신 개체에게 전송
5 전자문서 열람 수신 개체의 수신자는 열람권한을 가지고 제3자 보관기관에 접속하여 전자문서를 열람
6 유통(열람)증명서 보관 제3자 보관기관 수신 개체의 수신자가 전자문서를 열람하였을 경우, 유통(열람)증명서를 생성하고 이를 보관
7 유통(열람)증명서 전송 아울러, 제3자 보관기관 열람서비스를 의뢰한 송신 개체에게 유통(열람)증명서를 전송
[기업 내 시스템과의 연계 방법]
기업/기관은 내부적으로 다양한 전자문서를 생산하고 보관하기도 하고, 외부 기업/기관 등과 다양한 방식으로 전자문서를 주고받는다.
우편 등과 같은 오프라인으로 교환하기도 하고, 이메일이나 업무관련 시스템으로 교환하기도 한다. 이들 각각의 유통 체계는 기업/기관 내부로 연계될 때 아래 표 37과 같은 방식으로 연계된다.
[규칙 제91조에 의한 정정 08.09.2011]　
표 37
Figure WO-DOC-TABLE-37
Figure WO-DOC-TABLE-37a
공인전자주소 기반 전자문서 유통체계는 다음과 같은 방식으로 기업/기관 내부와 연계될 수 있다.
이하, 내부 시스템과 연동하는 방식에 대하여 설명하면 다음과 같다.
내부 시스템과 연동하는 방식은 주로 기업이나 기관에서 유통 메시징서버를 설치할 때 사용하는 형태로, 유통 클라이언트를 내부 시스템에 시스템 통합(SI) 형태로 개발하는 방식이며, 상세한 설명은 아래 표 38과 같다.
[규칙 제91조에 의한 정정 08.09.2011]　
표 38
Figure WO-DOC-TABLE-38
이하, 내부 시스템과 연동하지 않는 방식에 대하여 설명하면 다음과 같다.
내부 시스템과 연동하지 않는 방식은 주로 전자문서 중계자에게 사용자 계정을 발급받아 이용하는 공인 송수신자에 적합한 형태로서, 전자문서 중계자가 제공하는 웹 형태의 유통 클라이언트를 이용하거나 전자문서 중계자가 배포하는 유통 클라이언트 어플리케이션을 로컬 PC에 설치하여 이용하는 방식이며, 상세한 설명은 아래 표 39와 같다.
[규칙 제91조에 의한 정정 08.09.2011]　
표 39
Figure WO-DOC-TABLE-39
※웹방식은 웹방식으로 사용자가 접속, 처리하는 방식으로, 개별 사용자가 로컬PC에 프로그램을 설치할 필요 없음.
※어플리케이션방식은 개별 사용자가 설치 프로그램을 다운받아, 로컬PC에 프로그램을 설치한 다음, 유통 메시징서버에 접속하여 사용.
[외부 시스템과의 연계 방안]
유통체계는 자체 시스템과 인터넷을 기반으로 유통 네트워크를 가진다. 전자문서 유통은 유통체계 내에서만 이루어지기 때문에 제약이 있을 수 있다. 유통체계는 직접 연결되지 않은 시스템과의 전자문서 유통을 위해 외부 연계 게이트웨이 서버를 두고 있다.
외부 연계 게이트웨이 서버의 기본 개념도는 도 32와 같다.
외부 연계 게이트웨이 서버는 중간 경유지 역할을 수행한다. 한쪽은 유통체계를 위한 유통 메시징서버 등을 가지고 있으며, 다른 한쪽은 외부 시스템과의 연계를 위한 각각의 어댑터들을 가지고 있다.
이와 같이, 외부 시스템과 연계하기 위해서는 업무적인 요소와 기술적인 요소를 고려하여야 한다.
업무적인 요소는 연계와 관련한 업무절차, 방법 등에 대한 당사자 간 합의로, 관리기관과 외부 연계 시스템 관리기관은 상호간에 서비스 레벨 협약(SLA)을 맺어야 한다.
기술적인 요소는 연계와 관련해 필요한 이용자 인증, 메시징, 메시지 포맷 등과 관련한 기술 요소를 말한다.
외부 시스템과 연계를 하기 위한 기술적인 원칙을 정리하면 다음 ① 내지 ⑥과 같다.
① (주소) 송신자는 중간경유지 주소와 최종 목적지 주소를 기재하여야 한다.
② (이용자 인증) 송신자는 외부 시스템이 송신자를 인증할 수 있도록 이용자 정보를 제공하여야 한다. 사전에 외부 시스템에 가입되어 있을 경우, 외부 시스템의 인증 식별자를 사용할 수 있다.
③ (메시지 분해 & 조립) 수신한 메시지를 분해해서 외부 시스템에 맞는 메시지로 조립하여야 한다.
④ (메시지 보안 등) 메시지에 적용된 암호화, DRM 등에 대한 보안 등을 검증/변환하여야 한다.
⑤ (메타데이터 정보) 메시지 내에 포함되어 메시지 및 전자문서 관련 정보들을 검증/변환하여야 한다.
⑥ (외부 연계 시스템에 대한 식별) 유통체계와 연계되는 외부 시스템은 추가나 변경될 수 있다. 외부 시스템에 대한 정보는 주소 디렉터리 서버에서 관리하며, 유통 메시징서버에서는 필요한 경우에 주소 디렉터리 서버에 질의하여 처리하여야 한다.
외부 시스템과 연계하여 전자문서가 유통되는 절차는 도 33과 같다.
상술한 바와 같은 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템 및 이를 이용한 전자문서 유통 방법에 있어서, 전자문서 유통이 이루어지기 위해서는 주소 디렉터리서버, 유통 메시징서버, 유통 클라이언트, 유통 중계서버와 같은 구성 요소들이 필요하며, 이들 구성요소들은 전자문서유통의 전체적인 흐름 속에서 서로 연계되어야만 한다. 이처럼 각 구성요소들 간에 서로 연계되어 동작하기 위해서는 연계를 위한 통신 프로토콜, 메시지 교환방식, 연계 메시지 구조 등이 정의되어야 한다.
이하에서는 각 구성요소들 간의 연계를 위해 먼저 공통적인 기반 통신 프로토콜 및 메시지 교환방식을 정의하고 각 연계유형별 메시지 구조를 표준으로 정의하여 제시하며, 이로써 본 발명은 서로 다른 환경 및 개발방법에 의해 구축된 구성요소들 간의 연계가 원활하게 이루어지고 상호운용이 가능하도록 할 수 있다.
[연계를 위한 기반 통신 프로토콜]
공인전자주소 기반 전자문서 유통체계 하에서 각 구성요소들 간의 정보 및 전자문서를 유통하기 위해 필요한 전자문서 유통 연계 인터페이스에 있어서, 유통 연계 메시지는 "ebXML Message Services v2.0 규격"(이하 ebMS)을 기반으로 하며, 이를 계층적으로 확장하여 보다 일반화된 형태로 정의된다. ebXML 기반 구조는 SOAP, SOAP with Attachment, Security 그리고 Reliability 등 독립적이지만 서로 밀접한 관계가 있는 요소들로 구성되어 있다. "연계를 위한 기반 통신 프로토콜"(이하 기반 통신 프로토콜)은 이러한 기본 요소들을 기반으로 유통체계에서 필요한 요소들을 정의하고 이를 유기적으로 재조합한 형태로 구성된다.
기반 통신 프로토콜은 전송하고자 하는 메시지를 구성하는 패키징, 메시지 봉투 구성, 메시지 보안 그리고 최종적으로 메시지를 전송하고 수신하는 메시지 송수신으로 구성된다.
이하, 기반 프로토콜 구성에 있어서 메시지 패키징 에 대하여 설명하면 다음과 같다.
유통 연계 메시지의 전체 메시지 구조는 ebMS v2.0 규격을 준용한다. 본 기반 통신 프로토콜에서 정의하는 메시지는 두 개의 논리적인 MIME Part를 가진다.
첫 번째 MIME Part는 헤더 컨테이너라고 불리는데, SOAP 메시지를 포함하고 있으며, SOAP 메시지는 다시 Header와 Body로 구성된다.
두 번째 MIME Part부터는 페이로드 컨테이너라고 불리는데, 어플리케이션 레벨의 메시지 및 첨부 문서를 포함한다.
첫 번째 MIME Part에 대한 상세 설명은 아래에서 하도록 한다. 이 영역에는 메시지 유통을 위한 공통적인 정보(메시지의 라우팅 관련 정보, SOAP 메시지 교환패턴, 전자서명, 오류 정보 및 두 번째 첨부되는 데이터에 대한 위치 정보 등)가 기술된다.
두 번째 MIME Part는 각 연계 인터페이스 별 요청 및 응답메시지를 첨부하게 되며, 이 연계 인터페이스의 유형에 따라 세 번째 이후 MIME Part의 존재여부가 결정된다. 유통체계를 이용하여 전자문서나 증명서를 전달할 때 세 번째 MIME Part에 포함된다.
유통 연계 메시지의 기본적인 구조는 도 34와 같으며, 도 34에서 ① "SOAP-ENV: Header"는 유통 프로토콜 규격에 따라 구성되며 MesageHeader 및 Signature 정보로 구성되고, ② "SOAP-ENV: BODY"는 유통 프로토콜 규격에서 정의한 Mainfest 요소 정보 및 사용자 로그인 정보가 들어가며, ③ "전송 컨테이터 #1(페이로드 컨테이너 #1)"은 요청메시지 및 응답메시지를 포함하는 부분이며, 연계 인터페이스의 유형 및 요청, 응답, 오류 메시지 여부에 따라 비즈니스 문서의 상세 내용이 정의되고, ④ "전송 컨테이너 #2(페이로드 컨테이너 #2)"는 연계인터페이스의 유형에 따라 첨부되어야 하는 문서가 페이로드 컨테이너 #2부터 순차적으로 들어간다.
이러한 유통 연계 메시지는 Simple Object Access Protocol(SOAP) 1.1 및 SOAP Messages with Attachment 와 같은 표준 규격을 준수해야 한다.
도 34에서, 유통 연계 메시지의 모든 MIME Header 요소들은 SOAP Messages with Attachments 규격을 준수해야 한다. 추가로, 메시지 내의 Content-Type MIME Header는 반드시 SOAP 메시지 문서를 포함하는 MIME Body 부분의 MIME 미디어 유형과 동일한 type 속성을 가지고 있어야 한다. SOAP 규격에 따른 SOAP 메시지의 MIME 유형은 "text/xml" 값을 가져야 한다고 되어 있다. 루트 부분은 [RFC2045]에 준하는 구조를 가지는 Content-ID MIME Header를 포함할 것과 Multipart/Related 미디어 유형에 대한 필수적인 파라미터에 추가하여, start 파라미터([RFC2387]에서는 선택사항)가 항상 존재해야 한다. multipart/related 메시지 패키지의 MIME Header 예제는 아래 표 40과 같다.
표 40
Content-Type: multipart/related; type="text/xml"; boundary="boundaryValue";start=messagepackage-123@example.com--boundaryValueContent-ID: <messagepackage-123@example.com>
도 34에서, 첫번째 MIME Part 헤더 컨테이너는 반드시 SOAP 메시지를 포함하고 있어야 한다. 헤더 컨테이너의 MIME Content-Type header는 SOAP 규격에 따라 "text/xml" 값을 가져야 한다. Content-Type 헤더는 "charset" 속성을 포함해야 하며, 예제는 아래 표 41과 같다. 그리고, MIME charset 속성은 SOAP 메시지를 생성하는데 사용되는 문자 군을 식별하기 위해 사용된다. MIME charset 속성 값과 헤더 컨테이너에 위치하는 SOAP 메시지의 인코딩 선언부는 반드시 일치해야 하며 그 값은 UTF-8이어야 한다. 헤더 컨테이너의 예제는 아래 표 42와 같다.
표 41
Content-Type: text/xml; charset="UTF-8"
표 42
Ctent-ID: <messagepackage-123@example.com> ---| HeaderContent-Type: text/xml; charset="UTF-8" . | |<SOAP:Envelope --|SOAP Message | xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"> | | <SOAP:Header> | | … | | </SOAP:Header> | | <SOAP:Body> | | … | | </SOAP:Body> | |</SOAP:Envelope> --| | |
도 34에서, 페이로드 컨테이너의 개수는 연계 인터페이스 종류에 따라 달라질 수 있다. 각 페이로드 컨테이너는 ebMS 규격에 따라 SOAP Body 내의 Manifest 요소에 의해 참조가 되어야 한다. 예제는 아래 표 43과 같다.
표 43
Content-ID: <domainname.example.com> -------------| ebXML MIME |Content-Type: application/xml -------------| | | Payload<Invoice> -------------| | Container<Invoicedata> | Payload | … | |</Invoicedata> | |</Invoice> -------------| |
도 34에서, 본 발명에서 필수 요소로 지정한 MIME Header 외에 구현 편의상 MIME Header들을 추가하는 것도 가능하다. 이때, 추가되는 MIME Header는 반드시 [RFC2045]에 명시된 항목이어야 한다. 그러나, 추가적인 MIME Header에 대해서는 이를 추가하지 않은 측에서 이를 인지하고 해석할 필요는 없다.
이하, 기반 프로토콜 구성에 있어서 메시지 봉투 구성 에 대하여 설명하면 다음과 같다.
SOAP 규격에 준하여 모든 확장 요소 내용은 유효한 네임스페이스로 한정되어야 한다. 본 발명에서 정의된 모든 ebXML SOAP 확장 요소 내용은 ebXML SOAP Envelope 확장 네임스페이스로 한정되어야 한다. 네임스페이스 선언부들은 SOAP Envelop, Header 또는 Body 요소들에 포함되어 있거나, 각 SOAP 확장 요소들에 직접 포함되어 있을 수 있다.
SOAP Envelop은 SOAP 메시지의 Root 항목으로 SOAP 메시지 내의 각종 Namespace들은 선언한다. 선언해야 할 Namespace는 다음과 같다.
표 44
항목 Namespace URL
SOAP http://schemas.xmlsoap.org/soap/envelope/
Digital Signature http://www.w3.org/2000/09/xmldsig#
Xlink http://www.w3.org/1999/xlink
Xsi http://www.w3.org/2001/XMLSchema-instance
메시지 봉투 스키마 구조는 도 35와 같으며, 메시지 봉투 예제는 아래 표 45와 같다.
표 45
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/ http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd"> <SOAP:Headerxmlns:eb="http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd"xsi:schemaLocation="http://www.oasis-open.org/committees/ebxml-msg/schema/msg- header-2_0.xsd http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd"> <eb:MessageHeader ...> ... </eb:MessageHeader> </SOAP:Header> <SOAP:Bodyxmlns:eb="http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd"xsi:schemaLocation="http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd"> <eb:Manifest eb:version="2.0"> ... </eb:Manifest> </SOAP:Body></SOAP:Envelope>
SOAP Header 요소는 SOAP Envelop 요소의 첫번째 자식 요소로서 다음 ① 내지 ④와 같은 확장 요소를 포함한다.
① MessageHeader: 메시지의 라우팅 정보(To/From, 등)와 메시지에 관한 다른 문맥정보를 포함한 필수 요소
② SyncReply: 메시지를 송수신하는 방식이 동기식임을 나타내는 요소
③ Signature: SOAP 메시지 및 첨부 문서에 대한 전자서명 값을 나타내는 요소
④ ErrorList: 메시지 구문 검증, 메시지 전자서명 검증 등 메시지를 처리하는 과정에서 오류가 발생하여 오류 메시지를 반환할 때 해당 오류 내역을 담는 요소
SOAP Body 요소는 SOAP Envelope 요소의 두 번째 자식 요소로서 Manifest와 같은 확장 요소를 포함한다. Manifest는 페이로드 컨테이너 또는 웹과 같이 다른 장소에 위치한 데이터를 가리키는 요소이다.
Manifest 요소는 페이로드 컨테이너를 참조하기 위해 반드시 존재해야 한다. Manifest 요소는 한 개 이상의 Reference 요소들로 구성된 복합 요소이다. 각 Reference요소는 페이로드 컨테이너에 담긴 페이로드 문서(들)의 일부로 포함되거나 URL로 접근 가능한 원거리의 자원인 메시지에 관련된 데이터를 식별한다. SOAP Body에는 페이로드 데이터를 싣지 않도록 권고하고 있다. Manifest의 목적은 다음① 및 ②과 같다.
① ebXML 메시지와 관련된 특정한 페이로드를 쉽게 직접적으로 접근할 수 있게 함
② 파싱 작업 없이도 어플리케이션이 페이로드를 처리할 수 있는지 판단할 수 있도록 함
Manifest 요소는 다음 ① 내지 ③과 같은 속성과 요소들로 구성되어 있다.
① 한 개의 id 속성
② 한 개의 version 속성
③ 한 개 이상의 Reference 요소
Reference 요소는 다음 ① 내지 ②와 같은 하위 요소들로 구성된 복합 요소이다.
① 0개 이상의 Schema 요소: 부모 Reference 요소에서 식별된 인스턴스 문서를 정의하는 스키마(들)에 대한 정보
② 0개 이상의 Description 요소: 부모 참조 요소에 의해 Reference된 페이로드 객체에 대한 설명
Reference 요소는 그 자체가 [XLINK]의 단순 링크이다. XLINK는 현재 W3C의 후보 권고안(CR)이다. 여기에서 XLINK가 사용된 것은 연관관계의 설명을 명확하게 하기 위한 용어로 제공되어 있음을 알린다. XLINK 프로세서 또는 엔진의 사용이 필수적이지는 않지만 구현 요구 사항에 따라 유용할 수 있다. Reference 요소는 위에서 제공된 요소의 내용과 더불어 다음 ① 내지 ⑤와 같은 속성 내용을 포함하고 있다.
① id: Reference 요소에 대한 XML ID
② xlink-type: 이 속성은 XLINK 단순 링크로 요소를 정의. 이는 "simple"이라는 고정된 값을 가짐
③ xlink:href: 이 필수 속성은 참조된 페이로드 객체의 URI 값. 이는 [XLINK] 명세의 단순 링크에 준하는 것이어야 함
④ xlink:role: 이 속성은 페이로드 객체나 그의 목적을 설명하는 자원을 식별. 존재한다면 [XLINK] 명세에 준하는 유효한 URI 값을 가져야 함
⑤ 이 외에 다른 유효 네임스페이스인 속성들이 존재할 수 있음. 수신 MSH는 위에서 정의한 것 외에 외부의 네임스페이스 속성들은 무시할 수 있음
Schema 요소는 참조하는 항목이 그 것을 기술하는 스키마(들)를 가지고 있다면 (예, XML Schema, DTD, 또는 Database Schema), 그 Schema 요소는 Reference 요소의 자식 요소로 존재해야 한다. 이는 스키마와 버전을 식별하는 방법으로 사용되며, 부모 Reference 요소에 의해 식별되는 페이로드 객체를 정의한다. Schema 요소는 다음 ① 및 ②와 같은 속성을 가지고 있다.
① location: 스키마의 필수 URI
② version: 스키마의 버전 식별자
xlink:href 속성이 content id(URI scheme "cid")인 URI를 포함하고 있으면 그 content-id를 가지는 MIME은 메시지의 페이로드 컨테이너에 표현되어 있어야 한다. 그렇지 않으면 errorCode를 MimeProblem으로, severity를 Error로 하는 오류를 발신당사자에게 전달해야 한다. xml:href 속성이 content id(URI scheme "cid")인 URI를 포함하고 있지 않으면 URI는 해석되지 못하고, 구현에 따라 오류를 전달해야 할지 말아야 할지 결정해야 한다. 오류가 전달되어야 한다고 결정되면 errorCode를 MimeProblem으로, severity를 Error로 하는 오류를 발신당사자에게 전달해야 한다.
아래 표 46은 전형적인 한 개의 페이로드 MIME Body 부분을 가지는 메시지의 Mainfest를 나타낸다.
표 46
<eb:Manifest eb:id="Manifest" eb:version="2.0"> <eb:Reference eb:id="pay01" xlink:href="cid:payload-1" xlink:role="http://regrep.org/gci/purchaseOrder"> <eb:Schema eb:location="http://regrep.org/gci/purchaseOrder/po.xsd" eb:version="2.0"/> <eb:Description xml:lang="en-US">Purchase Order for 100,000 widgets</eb:Description> </eb:Reference></eb:Manifest>
이하, 기반 프로토콜 구성에 있어서 메시지의 세부 구성 요소 에 대하여 설명하면 다음과 같다.
MessageHeader 요소는 모든 ebXML 메시지에 표현되어야 하는 필수 요소로서 반드시 SOAP Header 요소의 자식 요소로 표현되어야 한다. MessageHeader 요소는 다음과 같은 하위 요소들로 구성된 복합 요소이다.
MessageHeader의 Element 구조는 아래 표 47과 같다.
표 47
항목 명 설명 반복회수 유형 길이
From ■ 메시지 송신 송수신 개체 정보 1..1
PartyId type ■ 'ecf_cd'로 고정
■ 송신자를 식별하는 코드■ 유통 메시징 서버의 경우 인증번호 ■ 유통 클라이언트의 경우 자체 관리 번호 설정■ 주소 디렉터리서버, 유통 중계서버 경우는 개체 코드값 설정 1..1 S 13
Role ■ 송신자 역할■ 'sender'로 고정 1..1 S 최대256
To ■ 메시지 수신 송수신 개체 정보 1..1
PartyId ■ type ■ 'ecf_cd'로 고정 1..1 S 13
■ 수신자를 식별하는 코드■ 유통 메시징 서버의 경우 인증번호 ■ 유통 클라이언트의 경우 자체 관리 번호 설정■ 주소 디렉터리 서버, 유통 중계서버 경우는 개체 코드값 설정 1..1 S 13
Role ■ 수신자 역할■ 'receiver'로 고정 1..1 S 최대256
CPAId ■ 거래협업정의서 아이디■ 연계인터페이스 유형에 따라서 코드값 설정 1..1 S 최대256
ConversationId ■ 송수신 트랜잭션 구분자 1..1 S 최대256
Service ■ 거래협업정의서에 정의된 업무 서비스 구분자 1..1 S 최대 256
Action ■ Service 내의 특정 업무 프로세스 구분자■ Service 내에서 유일한 값 1..1 S 최대 256
MessageData ■ 메시지를 식별하기 위한 데이터 1..1
MessageId ■ 하나의 메시지가 가지는 유일한 식별자 1..1 S 최대 256
Timestamp ■ 메시지 생성 시간■ UTC 형식■ ex> 2008-07-31T06:29:39.724Z 1..1 S 24
RefToMessageId ■ 응답메시지에만 존재■ 요청메시지의 MessageId 0..1 S 최대 256
Other ■ 인터페이스 종류에 따른 확장 요소■ 요소 명은 해당 인터페이스에 따라 다른 명칭을 가짐■ 세부 상세 내용은 해당 연계 인터페이스(5장, 6장, 7장, 8장) 참조 0..1
MessageHeader의 스키마 구조는 도 36과 같으며, MessageHeader 항목 코드표는 아래 표 48과 같고, 업무별 Service/Action 항목은 아래 표 49와 같다.
표 48
식별코드항목 코드값 코드값 정의
PartyId ads 주소디렉터리 서버 개체 코드
ech 유통 중계서버 개체 코드
CPAId urn:ads-and-ecm-cpa 유통 메시징서버와 주소디렉터리 서버간 연계인터페이스 사용시
urn:ecm-and-ecm-cpa 유통 메시징서버 상호간 연계인터페이스 사용시
urn:ecm-and-ecc-cpa 유통 클라이언트와 유통 메시징서버 간 연계인터페이스 사용시
urn:ech-and-ecm-cpa 유통 메시징서버와 유통 중계서버간 연계인터페이스 사용시
표 49
항목 Service Action 정의
유통 메시징서버와 주소디렉터리 서버간 연계인터페이스 사용시 urn:ads-service request 요청
response 응답
유통 메시징서버 상호간 연계인터페이스 사용시 urn:ecm-service request 요청
response 응답
유통 클라이언트와 유통 메시징서버 간 연계인터페이스 사용시 urn:ecc-service request 요청
response 응답
유통 메시징서버와 유통 중계서버 간 연계인터페이스 사용시 urn:ech-service request 요청
response 응답
MessageHeader 예시는 아래 표 50과 같다.
표 50
<eb:MessageHeader SOAP:mustUnderstand="1" eb:id="MessageHeader" eb:version="2.0"> <eb:From> <eb:PartyId eb:type="ecf_cd">1234567</eb:PartyId> <eb:Role>sender</eb:Role> </eb:From> <eb:To> <eb:PartyId eb:type="ecf_cd">4567899</eb:PartyId> <eb:Role>receiver</eb:Role> </eb:To> <eb:CPAId>urn:ecm-and-ecm-cpa</eb:CPAId><eb:ConversationId>urn:ecm-and-ecm-cpa:0210050643</eb:ConversationId> <eb:Service>urn:ecm-service</eb:Service> <eb:Action>request</eb:Action> <eb:MessageData><eb:MessageId>20110210-170644Z-00057@127.0.0.18d1f96bf-9cd6-4049-9fdb-a6c0ed9af467</eb:MessageId> <eb:Timestamp>2011-02-10T08:06:44.810Z</eb:Timestamp> </eb:MessageData> <eb:DuplicateElimination></eb:DuplicateElimination></eb:MessageHeader>
SyncReply가 존재한다면 동기식 송신임을 의미하며 다음 ① 내지 ④의 속성을 가진다.
① id 속성
② version 속성
③ SOAP actor 속성(반드시 "http://schemas.xmlsoap.org/soap/actor/next" 값을 가져야 함)
④ SOAP mustUnderstand 속성
SyncReply 요소의 예제는 아래 표 51과 같다.
표 51
<eb:SyncReply eb:id="3833kkj9" eb:version="2.0" SOAP:mustUnderstand="1" SOAP:actor="http://schemas.xmlsoap.org/soap/actor/next"/>
유통 연계 메시지는 송수신 과정에서 발생할 수 있는 다양한 위험 요소에 대응하기 위하여 반드시 전자적으로 서명되어야 한다. 따라서 Signature 요소가 SOAP Header의 자식요소로 반드시 존재해야 한다.
유통 연계 메시지에서 전자서명의 대상이 되는 부분은 SOAP 메시지 전체와 페이로드 컨테이너에 포함된 메시지 및 첨부문서들이다. 각 서명대상 정보는 Digest되어 전자서명 정보 내에 각각 포함된다.
[XMLDSIG] 규격에 따라 전자서명을 수행하는 과정은 다음 ① 내지 ④와 같다.
① SOAP Envelope에 SignatureMethod, CanonicalizationMethod, Reference 요소를 가진 SignedInfo 요소 와 필수 페이로드 객체를 [XMLDSIG]에 규정된 대로 생성
- SignedInfo 하위의 첫 번째 Reference 항목은 SOAP 메시지 전체를 대상으로 하므로 URI 값에 ""을 기술한다.
- 두 번째 Reference 항목부터는 페이로드 컨테이너의 개수만큼 반복하여 기술하도록 하며, 이때 URI 값은 첨부문서의 MIME Header에 정의된 content ID 값을 기술한다. (Digest 대상은 Mime Header를 제외한 Content 부분임)
② 정규화 한 뒤 [XMLDSIG]에 지정된 대로 SignedInfo에 지정된 알고리즘을 기준으로 SignedInfo의 SignatureValue를 산출
③ [XMLDSIG]에 지정된 대로 SignedInfo, KeyInfo, SignatureValue 요소를 포함하는 Signature 요소를 생성
④ SOAP Header의 Signature 요소를 SOAP Header 요소에 포함
전자서명 시 사용되는 알고리즘 정보는 다음과 같다. 알고리즘은 W3C "XML-Signature Syntax and Processing" (RFC3275)의 알고리즘 부분(6.0 Algorithms)을 기본적으로 따른다. 또한 국내 고유 알고리즘을 지원하기 위해 TTAS.IF-RFC3075 "확장성 생성 언어 전자서명 구문과 처리 (XML-Signature Syntax and Processing)" (한국정보통신기술협회, 2004년)에서 정의된 알고리즘을 이용한다.
다음은 유통 프로토콜에서 이용하는 알고리즘 목록이다. 메시지 송수신 시 전자서명의 생성 및 검증 과정에서의 모호성을 최소화 하기 위해서 다음 ① 내지 ⑤ 목록 이외의 알고리즘은 사용을 제한한다.
① 전자서명 Namespace
표 52
<... xmlns:ds="http://www.w3.org/2000/09/xmldsig#" ... >
② 해쉬 (Digest)
;데이터를 축약하는 데 사용되는 알고리즘은 공인인증체계의 관련 규정을 준수하도록 한다.
표 53
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>또는<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256/>
③ 전자서명(Signature)
;메시지 전자서명 시 사용되는 알고리즘은 공인인증체계의 관련 규정을 준수하도록 한다.
표 54
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>또는<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
④ 정규화(Canonicalization)
;논리적으로 동일한 문서에 대해 물리적으로 여러 가지 표현이 가능 방식한 XML의 특성으로 인해 같은 문서에 대해 전자서명 값이 다르게 나올 수 있다. 이러한 현상을 방지하기 위해 반드시 정규화 과정을 거쳐야 한다. 정규화는 주석 없는 정규 XML(Canonical XML, omits comments)을 사용하도록 한다.
표 55
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
⑤ 변환(Transform)
;전체 XML 데이터 중에서 실제 서명 대상이 되는 데이터를 가공하고 선택하는 과정을 거치는 알고리즘으로 다양한 변환 알고리즘이 존재하나 그 중에서 3가지만을 이용하도록 한다. 첫 번째는 전자서명이 서명 대상 내에 포함되는 형식을 따르므로 Enveloped Signature 변환이고, 두 번째는 상기 설명한 정규화(Canonicalization) 그리고 세 번째는 서명 대상 정보를 선택하는 XPath 필터링(XPath Filtering)이다.
표 56
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>및<ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>및<ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"><ds:XPath>not(ancestor-or-self::node()[@SOAP:actor=&quot;urn:oasis:names:tc:ebxml-msg:actor:nextMSH&quot;] | ancestor-or-self::node()[@SOAP:actor= &quot;http://schemas.xmlsoap.org/soap/actor/next&quot;]) </ds:XPath></ds:Transform>
전자서명 구문의 구조는 도 37과 같으며, 전자서명된 메시지 예제는 아래 표 57과 같다.
표 57
<?xml version="1.0" encoding="utf-8"?><SOAP:Envelope xmlns:xlink="http://www.w3.org/1999/xlink"xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"xmlns:eb="http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsdhttp://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsdhttp://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd"> <SOAP:Header> <eb:MessageHeader eb:id="..." eb:version="2.0" SOAP:mustUnderstand="1"> ... </eb:MessageHeader> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> <Reference URI=""> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"> <XPath> not(ancestor-or-self::node()[@SOAP:actor= &quot;urn:oasis:names:tc:ebxml-msg:actor:nextMSH&quot;] | ancestor-or-self::node()[@SOAP:actor= "http://schemas.xmlsoap.org/soap/actor/next"]) </XPath> </Transform> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>...</DigestValue> </Reference> <Reference URI="cid://blahblahblah/"> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>...</DigestValue> </Reference> </SignedInfo> <SignatureValue>...</SignatureValue> <KeyInfo>...</KeyInfo> </Signature> </SOAP:Header> <SOAP:Body> <eb:Manifest eb:id="Mani01" eb:version="2.0"> <eb:Reference xlink:href="cid://blahblahblah/" xlink:role="http://ebxml.org/gci/invoice"> <eb:Schema eb:version="2.0" eb:location="http://ebxml.org/gci/busdocs/invoice.dtd"/> </eb:Reference> </eb:Manifest> </SOAP:Body></SOAP:Envelope>
ErrorList 요소는 메시지 구문 검증, 메시지 전자서명 검증 등 통신 프로토콜 처리 과정에서 오류가 발생하는 경우에 Header 하위에 생성하여 송신자에게 동기식으로 반환해야 한다. ErrorList 요소가 생성되는 경우에는 반드시 MessageHeader 요소 내에 RefToMessageId가 존재해야 하며 RefToMessageId는 오류가 발생한 메시지의 MessageId를 지칭해야 한다.
ErrorList 요소는 다음 ① 내지 ⑤와 같은 속성들을 가진다.
① id 속성
② SOAP mustUnderstand 속성
③ version 속성
④ highestSeverity 속성
⑤ 한 개 이상의 Error 요소
보고될 오류가 없으면 ErrorList 요소는 존재해서는 안 된다. ErrorList의 구조는 도 38과 같다.
highestSeverity 속성은 모든 Error 요소들의 가장 심각한 상태를 표시한다. 특히, 어떤 Error 요소가 severity를 Error 라고 설정되어 있으면, highestSeverity는 Error로 설정되어야 하며, 그렇지 않은 경우에는 highestSeverity를 Warning으로 설정해야 한다.
Error 요소는 다음 ① 내지 ⑥과 같은 속성들을 가진다.
① id 속성
; id 속성은 문서 내에서 ErrorList 요소를 유일하게 식별하는 역할을 한다.
② codeContext 속성
; codeContext 속성은 errorCodes의 네임스페이스 또는 스키마를 나타낸다. 이는 반드시 URI이어야 한다. 이 속성의 기본값은 urn:oasis:names:tc:ebxml-msg:service:errors이다. 이 속성에 기본 값이 없으면, 그 명세의 구현은 errorCodes를 사용한다는 것을 가리킨다.
③ errorCode 속성
; 필수 errorCode 속성은 오류를 가지고 있는 메시지의 오류가 지닌 본질을 지시한다.
④ severity 속성
; 필수 속성인 severity 속성은 오류의 심각성을 나타냅니다. 유효한 값들은 Warning 및 Error와 같다. Warning는 오류가 존재하지만 대화 중의 다른 메시지들은 정상적으로 생성되고 있다는 것을 가리키며, Error는 복구 불가능한 오류가 메시지에 존재하고 대화 중 더 이상 다른 메시지들은 생성되지 않는다는 것을 가리킨다.
⑤ location 속성
; location 속성은 오류가 존재하는 메시지 부분을 가리킨다. 만약에 오류가 ebXML 요소 내에 존재하고 요소가 "well-formed"라면 location 속성의 내용은 [Xpointer]이어야 한다.
⑥ Description 속성
; Description 요소의 내용은 xml:lang 속성에서 정의된 언어로 오류의 서술적인 설명을 제공한다. 보통, 이것은 XML 파서나 메시지를 검증하는 소프트웨어가 생성한 메시지가 된다. 이 의미는 이 내용은 Error 요소를 생성했던 소프트웨어의 판매자나 개발자에 의해 정의된다는 것을 의미한다.
ErrorList의 예제는 아래 표 58과 같다.
표 58
<eb:ErrorList eb:id="3490sdo", eb:highestSeverity="error" eb:version="2.0" SOAP:mustUnderstand="1"> <eb:Error eb:errorCode="SecurityFailure" eb:severity="Error"eb:location="URI_of_ds:Signature"> <eb:Description xml:lang="en-US">Validation of signature failed<eb:Description> </eb:Error> <eb:Error ...> ... </eb:Error></eb:ErrorList>
유통 프로토콜을 기반으로 메시지를 송수신하는 과정에서 오류가 발생하면, 오류를 인지한 송수신 개체는 상대방에게 오류 내용을 보고해야 한다. 보고해야 할 오류는 메시지 구조 오류, 메시징 오류 및 보안 오류와 같다.
본 발명에서 정의하는 유통 프로토콜보다 하위 레이어에 속하는 HTTP 및 Socket과 같은 데이터 통신 프로토콜과 관련된 오류들은 데이터 통신 프로토콜에서 지원하는 표준 메커니즘에 의해 발견되고 보고되어야 하며, 본 발명에서 정의하는 오류 보고 메커니즘을 사용하지 않는다.
오류코드는 오류 대상 및 유형별로 구분되며 자세한 내용은 아래 표 59와 같다.
표 59
오류 코드 내용 상세 설명
ValueNotRecognized 요소 내용이나 속성 값이 인식되지 않는다. 비록 문서가 well formed이고 유효하지만 요소/속성의 값이 인식할 수 없는 값이고 그러므로 ebXML 메시지 서비스에 의해 사용되어질 수 없는 값을 포함한다.
NotSupported 요소나 속성이 지원되지 않는다. 비록 문서가 well formed이고 유효하고 요소나 속성이 이 명세의 규칙이나 제약을 따르고 있지만 메시지를 처리할 수 있는 ebXML 메시지 서비스에 의해 지원되지 않는다.
Inconsistent 요소 내용이나 속성 값이 또 다른 요소나 속성에 불일치 한다. 비록 문서가 well formed이고 유효하고 이 명세의 규칙과 제약을 따르지만 요소와 속성의 내용이 다른 요소나 그들의 속성에 일치하지 않는다.
OtherXml 요소 내용이나 속성 값 속에서의 또 다른 오류 비록 문서가 well formed이고 유효하지만 그 요소 내용이나 속성 값이 이 명세 내의 규칙과 제약에 따르지 않고 다른 오류 코드에 속하지 않는다.Error 요소의 내용은 문제의 본질을 가리키는데 사용되어야 한다.
DeliveryFailure 메시지 전송 실패 수신된 메시지가 대개 혹은 확실히 다음 목적지에 보내지지 못했다. 만약에 severity가 Warning으로 설정되어 있으면 메시지가 배달될 가능성은 적다.
TimeToLiveExpired 메시지가 존재 할 수 있는 시간이 초과됨 메시지가 수신되었으나 MessageHeader 요소의 TimeToLive 요소가 제약한 시간을 초과한 시각에 수신되었다.
SecurityFailure 메시지의 보안 검사에 실패 메시지를 보낸 당사자의 서명의 검증 또는 권한 또는 실명 검사에 실패했다.
Unknown 알 수 없는 오류 어떤 오류 종류에도 속하지 않는 오류가 발생함을 뜻한다. Error 요소의 내용이 문제의 본질을 가리키는데 사용되어야 한다.
이하, HTTP 바인딩 방안에 있어서 HTTP를 통한 메시지 전송 방안 에 대하여 설명하면 다음과 같다.
HTTP 바인딩 예제는 아래 표 60과 같다.
표 60
POST /servlet/ebXMLhandler HTTP/1.1Host: www.example2.comSOAPAction: "ebXML"Content-type: multipart/related; boundary="BoundarY"; type="text/xml";start="<ebxhmheader111@example.com>"--BoundarYContent-ID: <ebxhmheader111@example.com>Content-Type: text/xml<?xml version="1.0" encoding="UTF-8"?><SOAP:Envelope xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"xmlns:eb="http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd" xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/ http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd"> <SOAP:Header> <eb:MessageHeader SOAP:mustUnderstand="1" eb:version="2.0"> <eb:From> <eb:PartyId eb:type="ecf_cd">123456789</eb:PartyId> <eb:Role>sender</eb:Role> </eb:From> <eb:To> <eb:PartyId eb:type="ecf_cd">912345678</eb:PartyId> <eb:Role>receiver</eb:Role> </eb:To> <eb:CPAId>urn:ecm-and-ecm-cpa</eb:CPAId> <eb:ConversationId>20001209-133003-28572</eb:ConversationId> <eb:Service>>urn:ecm-service</eb:Service> <eb:Action>request</eb:Action> <eb:MessageData> <eb:MessageId>20001209-133003-28572@example.com</eb:MessageId> <eb:Timestamp>2001-02-15T11:12:12.724Z</eb:Timestamp> </eb:MessageData> </eb:MessageHeader> </SOAP:Header> <SOAP:Body> <eb:Manifest eb:version="2.0"> <eb:Reference xlink:href="cid:ebxmlpayload111@example.com" xlink:role="XLinkRole" xlink:type="simple"> <eb:Description xml:lang="en-US">Purchase Order 1</eb:Description> </eb:Reference> </eb:Manifest> </SOAP:Body></SOAP:Envelope>--BoundarYContent-ID: <ebxmlpayload111@example.com>Content-Type: text/xml<?xml version="1.0" encoding="UTF-8"?><purchase_order> <po_number>1</po_number> <part_number>123</part_number> <price currency="USD">500.00</price></purchase_order>--BoundarY--
이하, HTTP 바인딩 방안에 있어서 HTTP Response 코드 에 대하여 설명하면 다음과 같다.
본 발명에서 HTTP 레벨의 응답 코드를 반환하기 위해서 [RFC2616]에 정의된 HTTP 응답 코드를 이용해야 한다. 주요 응답 코드는 아래 표 61과 같다.
표 61
상태 코드 연관 메시지 의미
200 OK 요청이 성공적으로 처리됨
400 Bad Request 요청에 문법적으로 잘못된 부분이 있음
401 Unauthorized 클라이언트가 올바른 허가를 받지 않고 허가가 필요한 페이지에 접근하려 함
404 Not Found 이 주소에서는 어떤 내용도 발견할 수 없음
500 Internal Server Error 서버 내부의 오류로 인해 요청을 정상적으로 처리할 수 없음
503 Service Unavailable 처리할 수 있는 한계를 벗어나 과도하게 요청이 들어와서 서버가 현재 해당 요청을 처리할 수 없음
이하, HTTP 바인딩 방안에 있어서 HTTP 전송 보안 방안 에 대하여 설명하면 다음과 같다.
유통체계 내의 모든 유통 메시징서버와 유통메시지 서버 간 전송이나 유통 메시징 서버와 유통 클라이언트 간 전송은 네트워크 전송 보안을 위해서 반드시 SSL(Secure Socket Layer) V3.0을 이용한 HTTP/S(Secure Hypertext Transfer Protocol)를 사용하여 처리하여야 한다.
본 발명에 따른 유통체계에서 오류 발생 유형은 크게 동기식 응답에 대한 오류 발생의 경우와 비동기식 응답에 대한 오류 발생 경우로 구분된다.
동기식 응답에 대한 오류의 경우는 요청메시지에 대한 처리결과를 받을 때까지 처음 요청자는 대기하고 있는 상태이므로 오류를 즉각 인지할 수 있으나, 비동기식 응답에 대한 오류는 요청자는 요청 내용만 전달한 후 그에 대한 처리결과를 차후에 받게 되므로 추가적인 오류처리가 이루어져야 한다.
이하, 오류 처리 방안에 있어서 동기식 오류처리 방안 에 대하여 설명하면 다음과 같다.
유통 메시징서버와 타 유통 메시징서버, 주소 디렉터리 서버, 유통 클라이언트, 유통 중계서버 간의 두 개체 간 모든 메시지 유통은 동기식 방식의 유통이다. 이 외에도, 유통 클라이언트가 유통 메시징서버를 통해 타 유통 메시징서버, 주소 디렉터리 서버, 유통 중계서버와 연계되는 3 개체 간 메시지 유통은 연계 유형에 따라 동기식 또는 비동기식 방식으로 연계된다.
동기식 전송에 대한 모든 오류는 전송자가 즉각 확인 가능하므로 재전송하는 것을 기본으로 한다. 재전송 방식에 대해서는 유통체계에 참여하는 기업이나 기관의 시스템의 정책에 따라 결정되나, 동일한 메시지 전송에 대해서는 동일한 MessageId 값을 설정하여 다시 보내는 것을 기본으로 한다.
동일한 MessageId 값으로 메시지를 보냄으로써 메시지 전송과정의 오류가 전송시점의 오류가 아니라 수신자가 수신 성공 후 동기식으로 응답메시지를 전송하는 과정에서의 오류에 발행한 경우에 대해서도 중복메시지 수신을 감지함으로써 동일한 요청을 중복해서 처리하는 것을 방지한다.
동기식 오류의 송신자와 수신자는 각각 연계유형에 따라 유통 메시징서버, 주소 디렉터리 서버, 유통 클라이언트, 유통 중계서버가 될 수 있다.
① 요청메시지 송신실패 : 송신자가 메시지를 전송하는 과정에서 전송오류가 발생하여 수신자에게 요청메시지가 전달되지 못하는 경우로서, 송신자는 전송시도에 대한 timeout 또는 네트워크 오류 메시지 등을 통해 송신 실패를 인지하게 된다. 도 39에는 요청메시지 송신 실패 시의 프로세스를 도시하였으며, 처리 절차는 아래 1) 내지 3)과 같다.
1) 메시지 송신자가 전송하는 과정에서 전송오류가 발생하는 경우로서 많은 경우가 네트워크 오류에 의해 발생됨
2) 송신자는 HTTP 오류와 같은 오류 메시지를 받게 되면 동일한 메시지를 다시 재전송 요청하여야 함
3) 송신자는 수신자에게 수신확인 메시지를 받은 경우에만 전송성공으로 인식함
② 응답메시지 수신실패 : 송신자가 메시지를 정상적으로 전송하였으나 수신자로부터 응답메시지를 받는 과정에서 오류가 발생한 경우이다. 송신자 입장에서는"①요청메시지 송신실패"와 구분이 되지 않으므로 오류에 대해서 동일한 방식으로 처리하나, 수신자는 요청메시지를 정상적으로 받았기 때문에 처리방식이 다르다. 도 40에는 응답메시지 수신실패와 관련한 프로세스를 도시하였으며, 처리 절차는 아래 1) 내지 3)와 같다.
1) 메시지가 수신자에게 정상적으로 전달되었으나, 송신자가 수신자로부터 수신확인 메시지를 받지 못한 경우
2) 이 경우 송신자는 송신실패 오류로 인식하고 수신자게에 동일한 메시지를 동일한 MessageId로 재전송하게 됨
3) 수신자는 수신한 문서의 MessageId가 이전 수신 메시지와 동일한 경우에는 중복수신으로 수신확인 메시지를 보낸 후 내부처리
③ 오류메시지 수신 : 송신자가 메시지를 정상적으로 전송하였으나 전송한 메시지를 수신한 수신자가 메시지를 처리하는 과정에서 오류가 발생한 경우이다. 이 경우 송신자의 처리 방식은 오류메시지의 유형에 따라 다르다. 통신 프로토콜 상의 오류유형은 상술한 “ErrorList” 항목을, 각 연계 인터페이스 별로 요청메시지에 대한 내부 처리과정에서 발생한 오류에 대해서는 각 연계 인터페이스의 메시지구조를 참조한다. 도 41에는 오류메시지 수신과 관련한 프로세스에 대하여 도시하였으며, 처리 절차는 아래 1) 내지 3)과 같다.
1) 송신자가 수신자에게 전송한 메시지가 정확히 전달되었으나 전송메시지 자체에 오류가 있어서 오류메시지를 응답받은 경우
2) 이 경우 송신자는 요청 메시지를 재생성한 후 메시지를 재전송하는 것이 일반적이나 오류유형에 따라 메시지 처리를 달리할 수 있음
3) 송신자가 요청메시지를 재전송할 때, 전송하는 메시지의 MessageId는 동일할 필요는 없으며, 업무 상황에 따라 다르게 처리할 수 있음
④ 3단계 동기식 오류 : 유통 클라이언트가 유통 메시징서버를 통해 타 유통 메시징서버, 주소 디렉터리서버, 유통 중계서버와 연계되는 3 개체 간 메시지 유통은 연계 유형 중 최종적 결과를 즉각적으로 확인하기 위해 동기식으로 연계하는 방안을 지원한다. 이 과정 중 유통 메시징서버와 수신자 간 연계단계에서 오류가 발생하면 유통 메시징서버는 즉각적으로 오류를 발생시킨 후 이를 유통 메시징서버에 응답메시지로 전달하여야 한다. 도 42에는 3단계 동기식 오류와 관련한 프로세스에 대하여 도시하였으며, 처리 절차는 아래 1) 내지 3)과 같다.
1) 유통 클라이언트가 유통 메시징서버와 연계하여 메시지 전송을 하는 단계에서는 전송성공을 하였으나, 유통 메시징서버 다음 수신자(주소 디렉터리서버, 타 유통 메시징서버, 유통 중계서버 등)에게 전송하는 과정에서 오류가 발생함
2) 이 때 오류는 유통 메시징서버와 수신자간 동기식 전송에서 발생되는 모든 오류인 경우를 지칭함
3) 유통 메시징서버는 오류를 인지한 시점에 유통 클라이언트를 위한 오류 메시지를 발생시키고 이를 유통 클라이언트에 응답메시지로 전달함
유통 메시징서버가 생성하는 오류 메시지는 아래 표 62와 같은 구조로 구성된다.
표 62
항목 명 설명 반복회수 유형 길이
Content ■ Root 엘리먼트
DocType ■ 유통메시지 유형 - 오류: 9 1..1 Integer 1
Sender ■ 요청메시지의 수신자 공인전자주소 1..1 String 최대 128
Receiver ■ 요청메시지의 송신자 공인전자주소 1..1 String 최대 128
RefIdentifier ■ 요청메시지의 고유 식별값 1..1 String 36
Identifier ■ UUID 형식으로 생성한 오류 메시지의 고유 식별 값 1..1 String 36
ErrorCode ■ 해당 오류 코드 1..1 Integer 4
이하, 오류 처리 방안에 있어서 비동기식 오류처리 방안 에 대하여 설명하면 다음과 같다.
유통 클라이언트가 유통 메시징서버를 통해 타 유통 메시징서버, 주소 디렉터리서버, 유통 중계서버와 연계되는 3 개체 간 메시지 유통은 연계 유형 중 유통 클라이언트 사용자가 최종 수신자의 상황에 독립적으로 운영할 수 있도록 비동기식 방식의 연계를 지원하기도 한다.
비동기식 전송에 대한 최종 오류는 동기식 전송과 달리, 전송자가 즉각 확인할 수가 없으므로 유통 메시징서버가 최종적으로 오류를 확인한 시점에 유통클라이언트를 위한 오류 메시지를 발생시키고, 이를 유통 클라이언트가 수신할 수 있도록 한다.
도 43에는 비동기식 오류처리 방안과 관련한 프로세스를 도시하였으며, 처리 방안은 아래 1) 내지 4)와 같다.
1) 유통 클라이언트가 유통 메시징서버와 연계하여 메시지 전송을 하는 단계에서는 전송성공을 하였으나, 유통 메시징서버 다음 수신자(주소 디렉터리서버, 타 유통 메시징서버, 유통 중계서버 등)에게 전송하는 과정에서 오류가 발생함
2) 이때 오류는 유통 메시징서버와 수신자간 동기식 전송에서 발생되는 모든 오류인 경우를 지칭함
3) 유통 메시징서버는 재시도 이후, 최종적으로 오류를 인지한 시점에 유통 클라이언트를 위한 오류 메시지를 발생시킨 후 유통 클라이언트의 수신함에 전달함
4) 유통 클라이언트가 유통 메시징서버에 수신메시지를 요청하는 단계에서 자신의 수신함에 수신된 오류메시지를 통해 이전 요청메시지에 대한 오류를 인지함
유통 메시징서버가 생성하는 오류 메시지는 아래 표63과 같은 구조로 구성된다.
표 63
항목 명 설명 반복회수 유형 길이
Content ■ Root 엘리먼트
DocType ■ 유통메시지 유형 - 오류: 9 1..1 Integer 1
Sender ■ 요청메시지의 수신자 공인전자주소 1..1 String 최대 128
Receiver ■ 요청메시지의 송신자 공인전자주소 1..1 String 최대 128
RefIdentifier ■ 요청메시지의 고유 식별값 1..1 String 36
Identifier ■ UUID 형식으로 생성한 오류 메시지의 고유 식별 값 1..1 String 36
ErrorCode ■ 해당 오류 코드 1..1 Integer 4
[유통 메시징서버와 주소 디렉터리 서버 간 연계 인터페이스]
주소 디렉터리 서버는 유통체계에서 가장 기본이 되는 공인전자주소정보를 관리하고 있는 시스템으로 전자문서유통에서 반드시 필요한 시스템이다.
유통 메시징서버와 주소 디렉터리서버 간 연계 인터페이스는 크게 2가지로 기능이 구분된다. 첫번째는 등록대행기관과의 공인전자주소 등록 등 업무에 관한 인터페이스이며, 두번째는 유통 메시징서버와의 물리적 주소 질의/응답, 스팸 신고 등 업무에 관한 인터페이스이다.
위 등록대행기관과의 공인전자주소 등록 등 업무에 관한 인터페이스는 따로 구분할 수 있지만, 등록대행기관을 전자문서 중계자 또는 제3자 보관기관 사업자가 하기 때문에 유통 메시징서버 내에 인터페이스 기능을 삽입하였다.
단, 송수신 개체에 설치되는 유통 메시징서버에는 공인전자주소 등록 등과 관련된 연계 인터페이스는 들어가지 않는다.
유통 메시징서버와 주소 디렉터리 서버 간 인터페이스 기능은 아래 표 64와 같다.
표 64
인터페이스 구분 인터페이스 설명 비고
주소 관리 공인전자주소 등록(공인 송수신자의 주소를 등록하는 경우) □ 전자문서 중계자를 통해 문서를 송수신하는 공인 송·수신자의 공인전자주소 정보를 주소 디렉터리서버에 등록하기 위한 인터페이스□ 요청한 공인전자주소가 주소 디렉터리서버에서 unique하지 않은 경우에는 등록에 실패함 요청자는 전자문서 중계자임
공인전자주소 정보 변경 □ 공인전자주소에 대한 관련정보들(ex: 보안정보, ID에 대해 변경이 발생한 경우 주소 디렉터리서버에 변경요청한 후 그 결과를 받는 인터페이스
공인전자주소 삭제 □ 주소 디렉터리서버에 등록된 공인전자주소를 더 이상 사용하지 않는 경우 주소 디렉터리서버에 삭제요청을 한 후 그 결과를 받는 인터페이스
주소 검색 물리적 주소정보 검색 □ 주소 디렉터리서버에 공인전자주소 정보에 해당하는 사용자의 보안정보(공인인증서)와 물리적 주소정보를 검색요청한 후 그 결과를 받는 인터페이스 요청자는 전자문서 중계자와 송수신 개체임
블랙리스트 관리 스팸메시지 신고 □ 주소 디렉터리서버에 스팸메시지를 신고하고 접수여부를 결과로 받는 인터페이스□ 주소 디렉터리서버는 스팸 신고된 메시지에 대한 최종 처리결과(스팸메시지로 확정되었는지 여부)를 신고자 및 스팸발송자에게 "메시지 전송 인터페이스"를 사용하여 통지함
통보 화이트 리스트 통보 □ 주소 디렉터리서버에서 송수신 개체로 화이트리스트 전달하는 인터페이스
블랙 리스트 통보 □ 주소 디렉터리서버에서 송수신 개체로 블랙리스트 전달하는 인터페이스
이와 같은 유통 메시징서버와 주소 디렉터리 서버 간 인터페이스의 상세 내용에 대하여 설명하면 다음과 같다.
먼저, 유통 메시징서버와 주소 디렉터리 서버 간 인터페이스에 있어서 공통 사항 에 대하여 설명하면 다음 ① 및 ②와 같다.
① 요청메시지의 MessageHeader 확장
송신 개체의 유통 메시징서버가 주소 디렉터리서버에 송신하는 요청메시지의 첫 번째 MIME Part의 SOAP 메시지 내에는 송신 개체의 전자서명정보가 포함되어 전달되어야 하며, 주소 디렉터리서버가 SOAP 메시지의 전자서명에 사용된 인증서의 소유자가 해당 송신 개체와 일치하는지를 검증(VID 검증)하는데 필요한 추가적인 송신 개체의 정보(CorpNum, RValue) 또한 포함되어 전달되어야 한다.
추가적인 송신 개체의 정보는 요청메시지의 SOAP 메시지 내 MessageHeader 요소 하위에 확장 요소(any ##other 위치)로서 위치해야 한다.
확장 요소 구조는 아래 표 65와 같으며, 확장 요소 예시는 아래 표 66과 같다.
표 65
항목 명 설명 반복회수 유형 길이
Extension ■ 확장 요소 엘리먼트 1..1
CorpNum ■ 중계자 혹은 송수신개체 사업자등록번호 1..1 String 10
RValue ■ 중계자 혹은 송수신개체 공인인증서 개인키에서 추출한 RValue■ RValue를 Base64로 인코딩 하여 입력해야 함 1..1 String 28
표 66
<eb:MessageHeader SOAP:mustUnderstand="1" eb:id="MessageHeader" eb:version="2.0"> <eb:From> <eb:PartyId eb:type="ecf_cd">123456789</eb:PartyId> <eb:Role>sender</eb:Role> </eb:From> <eb:To> <eb:PartyId eb:type="ecf_cd">ads</eb:PartyId> <eb:Role>receiver</eb:Role> </eb:To> <eb:CPAId>urn:ads-and-ecm-cpa</eb:CPAId> <eb:ConversationId>20001209-133003-28572</eb:ConversationId> <eb:Service>>urn:ads-service</eb:Service> <eb:Action>request</eb:Action> <eb:MessageData><eb:MessageId>20110210-170644Z-00057@127.0.0.18d1f96bf-9cd6-4049-9fdb-a6c0ed9af46 7</eb:MessageId> <eb:Timestamp>2011-02-10T08:06:44.810Z</eb:Timestamp> </eb:MessageData> <eb:DuplicateElimination></eb:DuplicateElimination> <Extention> <CorpNum>2208203228</CorpNum> <RValue>asdfasdf</RValue> </Extention></eb:MessageHeader>
② 전체 메시지 구조
유통 메시징서버와 주소 디렉터리서버 간 연계 인터페이스는 메시지의 첫 번째 MIME Part에는 SOAP 메시지가 위치하고, 두 번째 MIME Part에는 해당 요청 및 응답에 대한 유통메시지가 위치한다.
유통 메세징서버와 주소 디렉터리서버 간 SOAP 구조는 도 44와 같다.
이하, 유통 메시징서버와 주소 디렉터리 서버 간 인터페이스에 있어서 공인전자주소 등록 에 대하여 설명하면 다음과 같다.
공인전자주소 등록처리와 관련한 메시지 교환 흐름은 도 45와 같다.
요청 유통메시지 구조는 아래 표 67과 같으며, 메시지 예제는 아래 표 68과 같다.
표 67
항목 명 설명 반복회수 유형 길이
Request ■ 요청 Root 엘리먼트
RegAddrReq ■ 공인 송수신자 공인전자주소 등록 요청 엘리먼트
PeerCorpNum ■ 송수신 개체의 사업자 등록번호 1..1 String 10
PeerRegNum ■ 송수신 개체의 인증번호 0..1 String 10
Name ■ 회원 명 1..1 String 70
Type ■ 회원 유형 - 개인: U - 사업자: C 1..1 String 1
IDN ■ 회원 식별번호 - 개인: 주민등록번호 - 사업자: 사업자등록번호 1..1 String 최소 10최대 13
RAddress ■ 공인전자주소 1..1 String 최소 1최대 128
Cert ■ 공인인증서 0..1 Base64 -
Representative ■ 사업자인 경우 대표자명 0..1 String 30
Addr ■ 개인 또는 사업자 주소 0..1 String 256
Tel ■ 개인 또는 사업자 전화번호(- 없이 입력) 0..1 Integer 최소 9최대 12
Fax ■ 개인 또는 사업자 팩스 번호 0..1 Integer 최소 9최대 12
Mobile ■ 개인 또는 사업자 휴대폰 번호(- 없이 입력) 0..1 Integer 최소 10최대 12
EMail ■ 개인 또는 사업자 이메일 0..1 String 256
RegDate ■ 공인전자주소 등록일 0..1 Long -
EndDate ■ 공인전자주소 만료일 0..1 Long -
ManagerName ■ 공인전자주소 책임자 명 0..1 String 70
ManagerAddr ■ 공인전자주소 책임자 주소 0..1 String 256
ManagerEMail ■ 공인전자주소 책임자 이메일 0..1 String 256
ManagerTel ■ 공인전자주소 책임자 전화번호 0..1 Integer 최소 9최대 12
ManagerMobile ■ 공인전자주소 책임자 휴대폰 번호 0..1 Integer 최소 10최대 12
표 68
<Request xmlns="http://www.nipa.kr/eDocument_Circulation"> <RegAddReq> <PeerCorpNum>1234567890</PeerCorpNum> <PeerRegNum>5555555555</PeerRegNum> <Name>홍길동</Name> <Type>U</Type> <IDN>1111112222222</IDN> <RAddress>#000-0000-0000</RAddress> <Cert>MIDJAHjhh46dhkfjsjfsj...</Cert> <Addr>서울시</Addr> <Tel>021113333</Tel> <Mobile>0101112222</Mobile> </RegAddReq></Request>
응답 유통메시지 구조는 아래 표 69와 같으며, 메시지 예제는 아래 표 70과 같다.
표 69
항목 명 설명 반복회수 유형 길이
Response ■ 응답 Root 엘리먼트
RegAddrRes ■ 등록대행기관(전자문서 중계자) 회원 등록 응답 엘리먼트
ResultCode ■ 처리 결과 - 성공: 1 - 실패: 0 1..1 Boolean -
ErrorCode ■ 오류 코드(처리 결과가 실패(0)인 경우에만 해당 오류 코드 입력) 0..1 String 256
표 70
<Response xmlns="http://www.nipa.kr/eDocument_Circulation"> <RegAddRes> <ResultCode>1</ResultCode> </RegAddRes></Response>
이하, 유통 메시징서버와 주소 디렉터리 서버 간 인터페이스에 있어서 공인전자주소 정보 변경 인터페이스 에 대하여 설명하면 다음과 같다.
공인전자주소 정보 변경 인터페이스는 전자문서 중계자가 주소 디렉터리서버에 등록된 공인 송수신자의 공인전자주소 정보에 대한 변경을 요청하여 응답을 받는 인터페이스로서, 변경하고자 하는 사용자 정보 및 공인전자주소 정보를 요청메시지에 포함하여 전송한 후, 주소 디렉터리서버의 변경 처리 결과를 응답메시지로 수신받는다.
공인전자주소 정보 변경처리와 관련한 메시지 교환 흐름은 도 46과 같다.
요청 유통메시지 구조는 아래 표 71과 같으며, 메시지 예제는 아래 표 72와 같다.
표 71
항목 명 설명 반복회수 유형 길이
Request ■ 요청 Root 엘리먼트
ModAddrReq ■ 공인 송수신자 공인전자주소 등록 요청 엘리먼트
PeerCorpNum ■ 송수신 개체의 사업자 등록번호 1..1 String 10
PeerRegNum ■ 송수신 개체의 인증번호 0..1 String 10
Name ■ 회원 명 0..1 String 70
Type ■ 회원 유형 - 개인: U - 사업자: C 0..1 String 1
IDN ■ 회원 식별번호 - 개인: 주민등록번호 - 사업자: 사업자등록번호 0..1 String 최소 10최대 13
RAddress ■ 공인전자주소 1..1 String 최소 1최대 128
Cert ■ 공인인증서 0..1 Base64 -
Representative ■ 사업자인 경우 대표자명 0..1 String 30
Addr ■ 개인 또는 사업자 주소 0..1 String 256
Tel ■ 개인 또는 사업자 전화번호(- 없이 입력) 0..1 Integer 최소 9최대 12
Fax ■ 개인 또는 사업자 팩스 번호 0..1 Integer 최소 9최대 12
Mobile ■ 개인 또는 사업자 휴대폰 번호(- 없이 입력) 0..1 Integer 최소 10최대 12
EMail ■ 개인 또는 사업자 이메일 0..1 String 256
RegDate ■ 공인전자주소 등록일 0..1 Long -
EndDate ■ 공인전자주소 만료일 0..1 Long -
ManagerName ■ 공인전자주소 책임자 명 0..1 String 70
ManagerAddr ■ 공인전자주소 책임자 주소 0..1 String 256
ManagerEMail ■ 공인전자주소 책임자 이메일 0..1 String 256
ManagerTel ■ 공인전자주소 책임자 전화번호 0..1 Integer 최소 9최대 12
ManagerMobile ■ 공인전자주소 책임자 휴대폰 번호 0..1 Integer 최소 10최대 12
표 72
<Request xmlns="http://www.nipa.kr/eDocument_Circulation"> <ModAddrReq> <PeerCorpNum>1234567890</PeerCorpNum> <PeerRegNum>5555555555</PeerRegNum> <Name>홍길동</Name> <Type>U</Type> <IDN>1111112222222</IDN> <RAddress>#000-0000-0000</RAddress> <Cert>MIDJAHjhh46dhkfjsjfsj...</Cert> <Addr>서울시</Addr> <Tel>021113333</Tel> <Mobile>0101112222</Mobile> </ModAddrReq></Request>
응답 유통메시지 구조는 아래 표 73과 같으며, 메시지 예제는 아래 표 74와 같다.
표 73
항목 명 설명 반복회수 유형 길이
Response ■ 응답 Root 엘리먼트
ModAddrRes ■ 전자문서 중계자 회원 수정 응답 엘리먼트
ResultCode ■ 처리 결과 - 성공: 1 - 실패: 0 1..1 Boolean -
ErrorCode ■ 오류 코드(처리 결과가 실패(0)인 경우에만 해당 오류 코드 입력) 0..1 String 256
* 도 73에서, ErrorCode는 ResultCode가 실패(0)로 입력된 경우, 오류 원인에 해당하는 오류 코드를 입력
표 74
<Response xmlns="http://www.nipa.kr/eDocument_Circulation"> <ModAddrRes> <ResultCode>1</ResultCode> </ModAddrRes></Response>
이하, 유통 메시징서버와 주소 디렉터리 서버 간 인터페이스에 있어서 공인전자주소 삭제 인터페이스 에 대하여 설명하면 다음과 같다.
공인전자주소 삭제 인터페이스는 전자문서 중계자가 주소 디렉터리서버에 등록된 공인 송수신자의 공인전자주소 정보의 공인전자주소 정보에 대한 삭제를 요청하여 응답을 받는 인터페이스로서, 삭제하고자 하는 사용자 정보 및 공인전자주소 정보를 요청메시지에 포함하여 전송한 후, 주소 디렉터리서버의 삭제 처리 결과를 응답메시지로 수신받는다.
공인전자주소 삭제처리와 관련한 메시지 교환 흐름은 도 47과 같다.
요청 유통메시지 구조는 아래 표 75과 같으며, 메시지 예제는 아래 표 76와 같다.
표 75
항목 명 설명 반복회수 유형 길이
Request ■ 요청 Root 엘리먼트
DelAddrReq ■ 회원 공인전자주소 삭제 요청 엘리먼트
Name ■ 회원 명 1..1 String 최대 70
IDN ■ 회원 식별번호 - 개인: 주민등록번호 - 사업자: 사업자등록번호 1..1 String 최소 10최대 13
RAddress ■ 공인전자주소 1..1 String 최소 1최대 128
표 76
<Request xmlns="http://www.nipa.kr/eDocument_Circulation"> <DelAddrReq> <Name>홍길동</Name> <IDN>1111112222222</IDN> <RAddress>#000-0000-0000</RAddress> </DelAddrReq></Request>
응답 유통메시지 구조는 아래 표 77과 같으며, 메시지 예제는 아래 표 78과 같다.
표 77
항목 명 설명 반복회수 유형 길이
Response ■ 응답 Root 엘리먼트
DelAddrRes ■ 전자문서 중계자 회원 삭제 응답 엘리먼트
ResultCode ■ 처리 결과 - 성공: 1 - 실패: 0 1..1 Boolean -
RAddress ■ 공인전자주소 0..∞ String 최소 1최대 128
ErrorCode ■ 오류 코드(처리 결과가 실패(0)인 경우에만 해당 오류 코드 입력) 0..1 String 256
* 표 77에서, ErrorCode는 ResultCode가 실패(0)로 입력된 경우, 오류 원인에 해당하는 오류 코드를 입력.
표 78
<Response xmlns="http://www.nipa.kr/eDocument_Circulation"> <DelAddrRes> <ResultCode>1</ResultCode> </DelAddrRes></Response>
이하, 유통 메시징서버와 주소 디렉터리 서버 간 인터페이스에 있어서 물리적 주소정보 검색 인터페이스 에 대하여 설명하면 다음과 같다.
물리적 주소정보 검색 인터페이스는 전자문서 중계자 또는 송수신 개체가 주소 디렉터리서버에 전자문서 수신자의 공인전자주소에 해당하는 물리적 주소 정보와 메시지 보안처리를 위한 공인인증서 정보를 요청하여 응답을 받는 인터페이스로서, 전자문서 수신자의 공인전자주소 및 공인인증서 요청 여부를 요청메시지에 포함하여 전송한 후, 주소 디렉터리서버로부터 전자문서 수신자의 물리적 주소 정보(IP 주소 또는 Domain 주소) 및 공인인증서 정보를 응답메시지로 수신받는다.
물리적 주소정보 검색처리와 관련한 메시지 교환 흐름은 도 48과 같다.
요청 유통메시지 구조는 아래 표 79와 같으며, 메시지 예제는 아래 표 80과 같다.
표 79
Figure PCTKR2011005027-appb-T000001
표 80
Figure PCTKR2011005027-appb-T000002
응답 유통메시지 구조는 아래 표 81과 같으며, 메시지 예제는 아래 표 82와 같다.
표 81
Figure PCTKR2011005027-appb-T000003
표 82
Figure PCTKR2011005027-appb-T000004
이하, 유통 메시징서버와 주소 디렉터리 서버 간 인터페이스에 있어서 스팸메시지 신고 접수 인터페이스 에 대하여 설명하면 다음과 같다.
스팸 메시지 신고 접수 인터페이스는 전자문서 중계자 또는 송수신 개체가 주소 디렉터리서버에 스팸메시지를 신고하는 인터페이스로서, 스팸 송신자의 공인전자주소와 스팸 메시지 정보를 요청메시지에 포함하여 전송한 후, 주소 디렉터리서버로부터 스팸신고 접수여부를 응답메시지로 수신 받는다. 주소 디렉터리서버는 신고 접수된 스팸메시지에 대한 스팸 여부 판단이 완료되면, 유통 메시징서버 상호 간 연계 인터페이스의 “메시지 전송” 인터페이스를 사용하여 처리 결과를 통지한다.
스팸메시지 신고 접수처리와 관련한 메시지 교환 흐름은 도 49과 같다.
요청 유통메시지 구조는 아래 표 83과 같으며, 메시지 예제는 아래 표 84와 같다.
표 83
Figure PCTKR2011005027-appb-T000005
표 84
Figure PCTKR2011005027-appb-T000006
응답 유통메시지 구조는 아래 표 85와 같으며, 메시지 예제는 아래 표 86과 같다.
표 85
Figure PCTKR2011005027-appb-T000007
* 표 85에서, ResultCode는 스팸 신고 메시지에 대한 단순 접수 처리 결과임에 주의.
표 86
Figure PCTKR2011005027-appb-T000008
이하, 유통 메시징서버와 주소 디렉터리 서버 간 인터페이스에 있어서 화이트 리스트 통보 인터페이스 에 대하여 설명하면 다음과 같다.
화이트 리스트 통보 인터페이스는 송수신 개체에 화이트 리스트(유통체계에 참여하는 송수신 개체 및 송수신자의 공인전자주소 목록)를 통보해주기 위한 인터페이스이다.
화이트 리스트 통보와 관련한 메시지 교환 흐름은 도 50과 같다.
요청 유통메시지 구조는 아래 표 87과 같으며, 메시지 예제는 아래 표 88와 같다.
표 87
Figure PCTKR2011005027-appb-T000009
표 88
Figure PCTKR2011005027-appb-T000010
응답 유통메시지 구조는 아래 표 89와 같으며, 메시지 예제는 아래 표 90과 같다.
표 89
Figure PCTKR2011005027-appb-T000011
* 표 89에서, ResultCode는 스팸 신고 메시지에 대한 단순 접수 처리 결과임에 주의
표 90
Figure PCTKR2011005027-appb-T000012
이하, 유통 메시징서버와 주소 디렉터리 서버 간 인터페이스에 있어서 블랙 리스트 통보 인터페이스 에 대하여 설명하면 다음과 같다.
블랙리스트 통보 인터페이스는 송수신 개체에 블랙 리스트(수신 거부 리스트)를 통보해주기 위한 인터페이스이다. 통보된 블랙 리스트는 송수신 개체에 의해 블랙리스트 관리로 쓰인다.
블랙 리스트 통보와 관련한 메시지 교환 흐름은 도 51과 같다.
요청 유통메시지 구조는 아래 표 91과 같으며, 메시지 예제는 아래 표 92와 같다.
표 91
Figure PCTKR2011005027-appb-T000013
표 92
Figure PCTKR2011005027-appb-T000014
응답 유통메시지 구조는 아래 표 93과 같으며, 메시지 예제는 아래 표 94와 같다.
표 93
Figure PCTKR2011005027-appb-T000015
표 94
Figure PCTKR2011005027-appb-T000016
[유통 메시징서버 상호 간 연계 인터페이스]
유통 메시징서버는 기본적으로 다른 송수신 개체 또는 전자문서 중계자가 구축한 유통 메시징서버와 메시지 송수신을 위해 연계를 하여야 한다.
이러한 기본 기능 외에, 유통증명서를 제3자 보관기관에 보관하기 위하여 제3자 보관기관 사업자의 유통 메시징서버와 타 메시징서버 간에는 유통증명서 전달 연계 기능도 추가적으로 제공되어야 한다.
유통 메시징서버 상호 간 연계 인터페이스는 메시징서버 상호 간 메시지 및 유통증명서를 송수신하기 위한 프로토콜로서, 아래 표 95와 같은 인터페이스로 구분된다.
표 95
Figure PCTKR2011005027-appb-T000017
이와 같은 유통 메시징서버 상호 간 인터페이스의 상세 내용에 대하여 설명하면 다음과 같다.
먼저, 유통 메시징서버 상호 간 인터페이스에 있어서 공통 사항 에 대하여 설명하면 다음 ①과 같다.
① 요청 및 응답메시지의 MessageHeader 확장
유통 메시징서버 상호 간 연계 인터페이스 메시지의 첫 번째 MIME Part인 SOAP 메시지 내에는 송신자의 전자서명정보가 포함되어 전달되어야 하며, 수신자가 SOAP 메시지의 전자서명에 사용된 인증서의 소유자가 해당 송신자와 일치하는지를 검증(VID 검증)하는데 필요한 추가적인 송신자의 정보(CorpNum, RValue) 또한 포함되어 전달되어야 한다.
추가적인 송신자의 정보는 요청 및 응답메시지의 SOAP 메시지 내 MessageHeader 요소 하위에 확장 요소(any ##other 위치)로서 위치해야 한다.
확장 요소 구조는 아래 표 96과 같으며, 스키마 구조는 아래 표 97과 같다.
표 96
Figure PCTKR2011005027-appb-T000018
표 97
Figure PCTKR2011005027-appb-T000019
이하, 유통 메시징서버 상호 간 인터페이스에 있어서 메시지 전송 인터페이스 에 대하여 설명하면 다음과 같다.
메시지 전송 인터페이스는 유통 메시징서버가 타 유통 메시징버서에 메시지를 전송할 시에 사용된다.
메시지 전송에 있어서 메시지 교환 흐름은 도 52와 같다.
메시지 교환 시에 요청 포맷은 도 53과 같으며, 도 53과 같은 전체 메시지 구조에 있어서 첫번째 MIME Part에는 SOAP 메시지, 두번째 MIME Part에는 요청 유통메시지, 그리고 사용자가 첨부한 문서가 있는 경우에는 세번째 MIME Part부터 위치한다.
요청 유통메시지의 구조는 아래 표 98과 같으며, 실제 예시는 다음과 같다.
표 98
Figure PCTKR2011005027-appb-T000020
* 표 98에 있어서, 문서 전달 목적으로 본문이 필요 없는 경우 Text 생략 가능
표 99
Figure PCTKR2011005027-appb-T000021
메시지 교환 시에 응답 포맷은 도 54와 같으며, 도 54와 같은 전체 메시지 구조에 있어서 첫 번째 MIME Part에는 SOAP 메시지, 두 번째 MIME Part에는 응답 유통메시지, 그리고 세 번째 MIME Part에는 수신증명서가 위치한다. 만약 요청메시지에 대한 처리과정에서 오류가 발생하였다면, 세 번째 MIME Part는 생성하지 않는다.
응답 유통메시지의 구조는 아래 표 100과 같으며, 실제 예시는 아래 표 101과 같다.
표 100
Figure PCTKR2011005027-appb-T000022
* 표 100에서, DocType이 오류(9)인 경우는 수신증명서가 위치하게 되는 MIME PArt3을 생성하지 않음.
표 101
Figure PCTKR2011005027-appb-T000023
이하, 유통 메시징서버 상호 간 인터페이스에 있어서 유통증명서 전달 인터페이스 에 대하여 설명하면 다음과 같다.
유통증명서 전달 인터페이스는 유통 메시징서버가 타 유통 메시징서버에 열람증명서를 전송할 때 사용된다. 또한 유통 중계서버가 전자문서 전송을 의뢰받아 수신 유통 메시징서버에 송신한 후 응답메시지로 수신한 수신증명서를 전송의뢰 유통 메시징서버에 전송할 때도 사용된다.
유통증명서 전달 처리와 관련한 메시지 교환 흐름은 도 55와 같다.
유통증명서 전달 요청 포맷은 도 56과 같으며, 도 56과 같은 전체 메시지 구조에 있어서 첫 번째 MIME Part에는 SOAP 메시지, 두 번째 MIME Part에는 요청 유통메시지, 그리고 세 번째 MIME Part에는 유통증명서가 위치한다.
요청 유통메시지 구조는 아래 표 102와 같으며, 실제 예시는 아래 표 103과 같다.
표 102
Figure PCTKR2011005027-appb-T000024
표 103
Figure PCTKR2011005027-appb-T000025
유통증명서 전달 응답 포맷은 도 57(57a는 성공인 경우, 57b는 오류인 경우)과 같으며, 도 57과 같은 전체 메시지 구조에 있어서, 요청메시지에 대한 처리가 성공인 경우 첫 번째 MIME Part에 수신확인 Acknowledgement SOAP 메시지만 위치하며, 오류인 경우는 첫 번째 MIME Part에는 SOAP 메시지, 두 번째 MIME Part에는 오류 응답 유통메시지가 위치한다.
응답 유통메시지 구조는 아래 표 104와 같으며, 표 104는 처리 결과가 오류인 경우에만 해당된다.
표 104
Figure PCTKR2011005027-appb-T000026
이하, 유통 메시징서버 상호 간 인터페이스에 있어서 유통증명서 보관요청 인터페이스 에 대하여 설명하면 다음과 같다.
유통증명서 보관요청 인터페이스는 송수신 개체의 유통 메시징서버가 유통증명서를 제3자 보관기관에 보관하기 위하여, 제3자 보관기관 사업자의 유통 메시징 서버에 유통증명서에 대한 보관 요청을 할 때 사용된다. 본 인터페이스 상의 응답메시지에는 수신확인 정보만 포함되며, 유통증명서를 제3자 보관기관에 보관한 결과로서 발급받은 최초등록증명서는 후술하는 "제3자 보관기관 보관결과 전달 인터페이스"를 사용하여 보관요청 유통 메시징서버에 전달한다.
유통증명서 보관요청 처리와 관련한 메시지 교환 흐름은 도 58과 같다.
유통증명서 보관 요청 포맷은 도 59와 같으며, 도 59와 같은 전체 메시지 구조에 있어서, 첫 번째 MIME Part에는 SOAP 메시지, 두 번째 MIME Part에는 요청 유통메시지, 그리고 세 번째 MIME Part에는 유통증명서가 위치한다.
요청 유통메시지 구조는 아래 표 105와 같으며, 실제 예시는 아래 표 106과 같다.
표 105
Figure PCTKR2011005027-appb-T000027
표 106
Figure PCTKR2011005027-appb-T000028
유통증명서 보관 응답 포맷은 도 60(60a는 성공인 경우, 60b는 오류인 경우)과 같으며, 도 60과 같은 전체 메시지 구조에 있어서, 요청메시지에 대한 처리가 성공인 경우 첫 번째 MIME Part에 수신확인 Acknowledgement SOAP 메시지만 위치하며, 오류인 경우는 첫 번째 MIME Part에는 SOAP 메시지, 두 번째 MIME Part에는 오류 응답 유통메시지가 위치한다.
응답 유통메시지 구조는 아래 표 107과 같으며, 표 107은 처리 결과가 오류인 경우만 해당된다.
표 107
Figure PCTKR2011005027-appb-T000029
이하, 유통 메시징서버 상호 간 인터페이스에 있어서 제3자 보관기관 보관결과 전달 인터페이스 에 대하여 설명하면 다음과 같다.
제3자 보관기관 보관결과 전달 인터페이스는 제3자 보관기관 사업자의 유통 메시징서버가 제3자 보관기관에 유통증명서를 보관한 후 해당 결과로서 수신한 최초등록증명서를 유통증명서 보관을 요청한 유통 메시징서버에 송신할 때 사용된다.
제3자 보관기관 보관결과 전달 처리와 관련한 메시지 교환 흐름은 도 61과 같다.
제3자 보관기관 보관결과 전달 포맷은 도 62와 같으며, 도 62와 같은 전체 메시지 구조에 있어서 첫 번째 MIME Part에는 SOAP 메시지, 두 번째 MIME Part에는 요청 유통메시지 그리고 세 번째 MIME Part에는 최초등록증명서가 위치한다. 만약 유통증명서를 제3자 보관기관에 보관하는 과정에서 오류가 발생하였다면, 세 번째 MIME Part 는 생성하지 않는다.
요청 유통메시지 구조는 아래 표 108과 같으며, 실제 예시는 아래 표 109와 같다.
표 108
Figure PCTKR2011005027-appb-T000030
* 표 108에 있어서, DocType이 오류(9) 인 경우는 최초등록증명서가 위치하게 되는 MIME Part 3을 생성하지 않음
표 109
Figure PCTKR2011005027-appb-T000031
제3자 보관기관 보관결과 응답 포맷은 도 63(63a는 성공인 경우, 63b는 오류인 경우)과 같으며, 도 63과 같은 전체 메시지 구조에 있어서, 요청메시지에 대한 처리가 성공인 경우는 첫 번째 MIME Part에 수신확인 Acknowledgement SOAP 메시지만 위치하며, 오류인 경우는 첫 번째 MIME Part에는 SOAP 메시지, 두 번째 MIME Part에는 오류 응답 유통메시지가 위치한다.
응답 유통메시지 구조는 아래 표 110과 같으며, 표 110은 처리 결과가 오류인 경우만 해당된다.
표 110
Figure PCTKR2011005027-appb-T000032
[유통 클라이언트와 유통 메시징서버 간 연계 인터페이스]
유통 메시징서버는 실제 전자문서 유통을 요청하는 사용자(내부 송수신자 또는 공인 송수신자)를 위한 시스템(유통 클라이언트)과 연계하여 사용자에게 문서 송수신 기본 기능을 제공하여야 한다.
유통 클라이언트와 유통 메시징서버 간 연계 인터페이스는 유통 클라이언트가 전자문서를 송신하고 수신하기 위하여 일차적으로 유통 메시징 서버와 통신하기 위한 프로토콜로서 아래 표 111과 같은 인터페이스로 구분된다.
표 111
Figure PCTKR2011005027-appb-T000033
유통클라이언트와 유통 메시징서버 간 연계 인터페이스의 상세 내용을 설명하면 다음과 같다.
먼저, 유통클라이언트와 유통 메시징서버 간 연계 인터페이스의 공통 사항 에 대하여 설명하면 다음 ①과 같다.
① 요청메시지의 MessageHeader 확장
유통 클라이언트가 유통 메시징 서버에 송신하는 요청메시지의 첫 번째 MIME Part인 SOAP 메시지 내에는 사용자의 전자서명 정보가 포함되어 전달되어야 하며, 유통 메시징 서버가 SOAP 메시지의 전자서명에 사용된 인증서의 소유자가 해당 사용자와 일치하는지를 검증(VID 검증)하는데 필요한 추가적인 사용자의 정보(IDN, RValue) 또한 포함되어 전달되어야 한다.
해당 정보는 요청메시지의 SOAP 메시지 내 MessageHeader 요소 하위에 확장 요소(any ##other 위치)로서 위치해야 한다.
또한 동일 인증서를 사용하는 복수의 내부 사용자들에 대한 개별인증정보가 추가될 수 있다.
확장 요소 구조는 아래 표 112와 같으며, 확장 요소 예시는 아래 표113과 같다.
표 112
Figure PCTKR2011005027-appb-T000034
표 113
Figure PCTKR2011005027-appb-T000035
이하, 유통 클라이언트와 유통 메시징서버 간 연계 인터페이스에 있어서 메시 전송 요청 인터페이스 에 대하여 설명하면 다음과 같다.
메시지 전송 요청 인터페이스는 유통 클라이언트가 유통 메시징 서버를 통해 메시지를 전송하기 위하여 유통 메시징서버에 메시지를 전송할 때 사용된다.
유통 클라이언트의 메시지 전송 처리 흐름은 도 64와 같다.
유통 클라이언트의 메시지 전송 요청 포맷은 도 65와 같으며, 도 65와 같은 전체 메시지 구조에 있어서 첫 번째 MIME Part에는 SOAP 메시지, 두 번째 MIME Part에는 요청 유통메시지가 위치한다. 그리고 사용자가 첨부한 문서가 있는 경우 세 번째 MIME Part부터 위치한다.
요청 유통메시지 구조는 아래 표 114와 같으며, 실제 예시는 아래 표 115와 같다.
표 114
Figure PCTKR2011005027-appb-T000036
* 표 114에 있어서, 문서 전달 목적으로 본문이 필요없는 경우 Text 생략 가능함.
표 115
Figure PCTKR2011005027-appb-T000037
유통 클라이언트 메시지 전송 응답 포맷은 도 66(66a는 성공인 경우, 66b는 오류인 경우)과 같으며, 도 66과 같은 전체 메시지 구조에 있어서, 요청메시지에 대한 처리가 성공인 경우는 첫 번째 MIME Part에 수신확인 Acknowledgement SOAP 메시지만 위치하며, 오류인 경우는 첫 번째 MIME Part에는 SOAP 메시지, 두 번째 MIME Part에는 오류 응답 유통메시지가 위치한다.
응답 유통메시지 구조는 표 116과 같으며, 표 116은 처리 결과가 오류인 경우만 해당된다.
표 116
Figure PCTKR2011005027-appb-T000038
이하, 유통 클라이언트와 유통 메시징서버 간 연계 인터페이스에 있어서 메시 목록 요청 인터페이스 에 대하여 설명하면 다음과 같다.
메시지 목록 요청 인터페이스는 유통 클라이언트가 유통 메시징서버에 수신된 메시지의 목록을 요청할 때 사용된다.
유통 클라이언트의 메시지 목록 처리 흐름은 도 67과 같다.
유통 클라이언트의 메시지 목록 요청 포맷은 도 68과 같으며, 도 68과 같은 전체 메시지 구조에 있어서 첫 번째 MIME Part에는 SOAP 메시지, 두 번째 MIME Part에는 요청 유통메시지가 위치한다.
요청 유통메시지 구조는 아래 표 117과 같으며, 실제 예시는 아래 표 118과 같다.
표 117
Figure PCTKR2011005027-appb-T000039
표 118
Figure PCTKR2011005027-appb-T000040
유통 클라이언트의 메시지 목록 응답 포맷은 표 67과 같으며, 표 67과 같은 전체 메시지 구조에 있어서 첫 번째 MIME Part에는 SOAP 메시지, 두 번째 MIME Part에는 응답 유통메시지(유통 메시징서버에 수신된 유통메시지 목록)이 위치한다.
응답 유통메시지 구조는 아래 표 119와 같으며, 실제 예시는 아래 표 120과 같다.
표 119
Figure PCTKR2011005027-appb-T000041
표 120
Figure PCTKR2011005027-appb-T000042
이하, 유통 클라이언트와 유통 메시징서버 간 연계 인터페이스에 있어서 메시지 상세정보 요청 인터페이스 에 대하여 설명하면 다음과 같다.
메시지 상세정보 요청 인터페이스는 유통 클라이언트가 유통 메시징서버에 수신된 특정 메시지와 첨부문서를 요청할 때 사용된다.
유통 클라이언트의 상세정보 요청 처리 흐름은 도 69와 같다.
유통 클라이언트의 메시지 상세정보 요청 포맷은 도 70과 같으며, 도 70과 같은 전체 메시지 구조에 있어서 첫 번째 MIME Part에는 SOAP 메시지, 두 번째 MIME Part에는 요청 유통메시지 본문이 위치한다.
요청 유통메시지 구조는 아래 표 121과 같으며, 실제 예시는 아래 표 122와 같다.
표 121
Figure PCTKR2011005027-appb-T000043
표 122
Figure PCTKR2011005027-appb-T000044
유통 클라이언트의 메시지 상세정보 응답 포맷은 도 72와 같으며, 도 72와 같은 전체 메시지 구조에 있어서 첫 번째 MIME Part에는 SOAP 메시지, 두 번째 MIME Part에는 응답 유통메시지(유통메시지 상세 정보) 그리고 첨부 문서가 있는 경우 세 번째 MIME Part부터 순서대로 위치한다.
응답 유통메시지 구조는 아래 표 123과 같으며, 실제 예시는 아래 표 124와 같다.
표 123
Figure PCTKR2011005027-appb-T000045
표 124
Figure PCTKR2011005027-appb-T000046
이하, 유통 클라이언트와 유통 메시징서버 간 연계 인터페이스에 있어서 스팸 메시지 신고 인터페이스 에 대하여 설명하면 다음과 같다.
스팸 메시지 신고 인터페이스는 유통 클라이언트가 유통 메시징 서버에 스팸 메시지를 신고할 때 사용된다. 유통 메시징 서버는 주소 디렉터리 서버로 스팸 메시지를 신고 후 결과를 유통 클라이언트로 전달해 준다.
유통 클라이언트의 스팸 메시지 신고 처리 흐름은 도 73과 같다.
유통 클라이언트의 스팸 메시지 신고 포맷은 도 74와 같으며, 도 74와 같은 전체 메시지 구조에 있어서 첫 번째 MIME Part에는 SOAP 메시지, 두 번째 MIME Part에는 요청 유통메시지가 위치한다.
요청 유통메시지의 구조는 아래 표 125와 같으며, 메시지 예제는 아래 표 126과 같다.
표 125
Figure PCTKR2011005027-appb-T000047
표 126
Figure PCTKR2011005027-appb-T000048
유통 클라이언트의 스팸 메시지 응답 포맷은 도 75와 같으며, 도 75와 같은 전체 메시지 구조에 있어서 첫 번째 MIME Part에는 SOAP 메시지, 두 번째 MIME Part에는 응답 유통메시지(유통 메시징서버에 수신된 유통메시지 목록)이 위치한다.
응답 유통메시지 구조는 아래 표 127과 같으며, 메시지 예제는 아래 표 128과 같다.
표 127
Figure PCTKR2011005027-appb-T000049
* 표 127에 있어서, ResultCode는 스팸 신고 메시지에 대한 단순 접수 처리 결과임에 주의
표 128
Figure PCTKR2011005027-appb-T000050
이하, 유통 클라이언트와 유통 메시징서버 간 연계 인터페이스에 있어서 물리적 주소 검색 인터페이스 에 대하여 설명하면 다음과 같다.
물리적 주소 검색 인터페이스는 유통 클라이언트가 유통 메시징 서버에 물리적 주소 검색을 요청할 때 사용한다. 유통 메시징 서버는 주소 디렉터리 서버로 물리적 주소를 검색후 결과를 전달해 준다.
물리적 주소 검색 처리와 관련하여 메시지 교환 흐름은 도 76과 같다.
물리적 주소 검색 요청 메시지 포맷은 도 77과 같으며, 도 77과 같은 전체 메시지 구조에 있어서 첫 번째 MIME Part에는 SOAP 메시지, 두 번째 MIME Part에는 요청 유통메시지가 위치한다.
요청 유통메시지 구조는 아래 표 129와 같으며, 메시지 예제는 아래 표 130과 같다.
표 129
Figure PCTKR2011005027-appb-T000051
표 130
Figure PCTKR2011005027-appb-T000052
물리적 주소 검색 응답 메시지 포맷은 도 78과 같으며, 도 78과 같은 전체 메시지 구조에 있어서 첫 번째 MIME Part에는 SOAP 메시지, 두 번째 MIME Part에는 응답 유통메시지(유통 메시징서버에 수신된 유통메시지 목록)이 위치한다.
응답 유통메시지 구조는 아래 표 131과 같으며, 실제 예시는 아래 표 132와 같다.
표 131
Figure PCTKR2011005027-appb-T000053
* 복수개의 RAddress 중 일부 또는 전체 주소에 대하여 검색은 정상적으로 수행되었으나 주소 부재의 오류가 발생하는 경우, 다른 인터페이스와는 달리 ResultCode를 성공(1)으로 입력함에 주의
* RAddress는 ResultCode의 성공(1)/실패(0) 여부에 상관없이 기술하도록 하며, 속성정보인 IsExist에 각 RAddress에 대한 존재여부를 입력
* Endpoint와 Cert는 IsExist의 값이 존재(1) 인 경우에 입력
* 요청메시지의 오류로 RAddress를 파싱하지 못한 경우, RAddress는 생략가능함(Endpoint 및 Cert도 결과적으로 생략됨)
* ErrorCode는 ResultCode가 실패(0)로 입력된 경우, 즉 주소 부재의 오류를 제외한 타 오류가 발생한 경우, 오류 원인에 해당하는 오류 코드를 입력
표 132
Figure PCTKR2011005027-appb-T000054
[유통 메시징서버와 유통 중계서버 간 연계 인터페이스]
유통 중계서버는 전자문서유통 체계에서 유통 메시징서버 간 직접 전자문서를 전송하는 과정에서 오류가 발생하여 전송이 실패한 경우, 송신 유통 메시징서버를 대행하여 전자문서 전송을 수행하는 시스템이다.
유통 중계서버는 정보통신산업진흥원이 관리하고 있으며, 모든 유통 메시징서버는 유통 중계서버와 연계하여 P2P 유통과정에서의 오류 시 지원을 받을 수 있다.
유통 메시징서버와 유통 중계서버 간 연계 인터페이스는 유통 메시징서버가 유통 중계서버에게 전자문서 전송을 의뢰하기 위한 프로토콜로서, 아래 표 133과 같은 인터페이스로 구분된다.
표 133
Figure PCTKR2011005027-appb-T000055
먼저, 유통 메시징서버와 유통 중계서버 간 연계 인터페이스의 공통 사항 에 대하여 설명하면 다음 ①과 같다.
① 요청메시지의 MessageHeader 확장
유통 메시징 서버와 유통 중계서버 간 연계 인터페이스 메시지의 첫 번째 MIME Part인 SOAP 메시지 내에는 유통 메시징 서버의 전자서명정보가 포함되어 전달되어야 하며, 유통 중계서버가 SOAP 메시지의 전자서명에 사용된 인증서의 소유자가 해당 유통 메시징서버와 일치하는지를 검증(VID 검증)하는데 필요한 추가적인 유통 메시징서버의 정보(CorpNum, RValue) 또한 포함되어 전달되어야 한다.
추가적인 유통 메시징서버의 정보는 SOAP 메시지 내 MessageHeader 요소 하위에 확장 요소(any ##other 위치)로서 위치해야 한다.
확장 요소 구조는 아래 표 134와 같으며, 확장 요소 예시는 아래 표 135와 같다.
표 134
Figure PCTKR2011005027-appb-T000056
표 135
Figure PCTKR2011005027-appb-T000057
이하, 유통 메시징서버와 유통 중계서버 간 연계 인터페이스의 메시지 전송의뢰 인터페이스 에 대하여 설명하면 다음과 같다.
메시지 전송의뢰 인터페이스는 유통 메시징서버가 타 유통 메시징서버에 메시지를 전송하는 과정에서 타 유통 메시징서버 측의 수신 오류가 발생한 경우, 유통 중계서버에 메시지 전송을 의뢰하고 송신 증명서를 발급받을 때 사용된다. 유통 중계서버는 유통 메시징서버의 메시지 전송의뢰에 대한 접수결과만을 즉시 리턴하며, 수신 유통 메시징서버에 메시지를 전송한 후 수신한 수신증명서는 상술한 “유통증명서 전달 인터페이스”를 사용하여 전송의뢰 유통 메시징서버에 전송한다.
메시지 중계 처리 흐름은 도 79와 같다.
메시지 중계 요청 메시지 포맷은 도 80과 같으며, 도 80과 같은 전체 메시지 구조에 있어서 첫 번째 MIME Part에는 SOAP 메시지, 두 번째 MIME Part에는 요청 유통메시지가 위치한다. 그리고 사용자가 첨부한 문서가 있는 경우 세 번째 MIME Part부터 위치한다.
요청 유통메시지 구조는 아래 표 136과 같으며, 실제 예시는 아래 표 137과 같다.
표 136
Figure PCTKR2011005027-appb-T000058
* 표 136에 있어서, 문서 전달 목적으로 본문이 필요없는 경우 Text 생략 가능함.
표 137
Figure PCTKR2011005027-appb-T000059
메시지 중계 응답 메시지 포맷은 도 81과 같으며, 도 81과 같은 전체 메시지 구조에 있어서 첫 번째 MIME Part에는 SOAP 메시지, 두 번째 MIME Part에는 응답 유통메시지, 그리고 세 번째 MIME Part에는 송신증명서가 위치한다. 만약 요청메시지에 대한 처리과정에서 오류가 발생하였다면, 세 번째 MIME Part는 생성하지 않는다.
응답 유통메시지 구조는 아래 표 138과 같으며, 실제 예시는 아래 표 139와 같다.
표 138
Figure PCTKR2011005027-appb-T000060
* 표 138에 있어서, DocType이 오류(9) 인 경우는 송신증명서가 위치하게 되는 MIME Part 3을 생성하지 않음
표 139
Figure PCTKR2011005027-appb-T000061
이하, 상술한 바와 같은 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템 및 이를 이용한 전자문서 유통 방법의 다른 실시예에 대하여 상세히 설명하면 다음과 같다.
[전자문서 유통 시스템의 구조 및 전자문서 유통 프로세스]
전자문서 유통은 신뢰유통을 위한 규격을 준수하는 기업/기관이 직접적으로 서로 전자문서를 주고받는 P2P 통신을 기본으로 한다. 이러한 P2P 통신을 수행하기 위한 본 발명에 따른 전자문서 유통 시스템의 기본 요소는 주소정보를 관리하고 있는 주소 디렉터리 서버와 각 송수신 개체들 간 유통을 할 수 있도록 지원하는 표준규격 기반의 유통 메시징서버 시스템이다. 이와 같은 주소 디렉터리 서버와 유통 메시징서버 시스템만 있으면 기업이나 기관이 전자문서를 유통할 수 있는 기본구조는 갖춰진 상태이며, 여기에 송수신자 간 문서유통을 증빙하기 위해 유통증명서를 발급하고, 동시에 이를 제3자 보관기관(공전소, 공인전자문서보관소)에 보관함으로써 유통에 대한 법적 근거를 확보할 수 있다.
본 발명에 따른 전자문서 유통 시스템은 상기 기본 요소 외에도, 일반 사용자(기업/기관, 개인)들이 쉽게 전자문서를 유통할 수 있도록 하기 위해서는 문서 송수신 기능에 대한 사용자 인터페이스를 제공하는 유통 클라이언트 어플리케이션(APP), 문서 작성의 편의성을 향상시키기 위해 표준문서양식을 제공하는 전자문서 서식 등록기, 행정기관과 전자문서를 중계하기 위한 공공부문 연계게이트웨이 등이 추가 구성 요소로서 구비된다.
상기와 같은 전자문서 유통 시스템에서 발생하는 기본적인 프로세스는 아래의 표 140과 같다.
표 140
Figure PCTKR2011005027-appb-T000062
[전자문서 유통 시스템의 각 구성 요소]
전자문서유통 시스템을 구성하는 요소를 좀 더 체계적으로 살펴보면 다음과 같다.
전자문서유통이 이루어지기 위해서는 먼저 유통의 주체가 되는 “① 송수신 개체”가 존재하여야 하며, 각 송수신 개체는 문서를 유통하기 위해 유통 메시징서버 규격을 준수하는 “② 유통 메시징서버 시스템”을 보유하여야 한다. 또한, 전자문서유통의 기본구성요소로 각 송수신 개체 및 사용자의 공인전자주소를 등록, 관리하는 “③ 주소디렉터리 서버”가 존재하여야 한다.
이러한 기본 구성요소를 바탕으로 사용자에게 유통의 편의성을 제공하기 위해 “④ 유통 클라이언트 APP”가 제공되어야 하며, 행정/공공기관 연계를 지원하는 “⑤ 공공부문 연계 게이트웨이”와 문서의 서식을 관리하는 “⑥ 전자문서 서식 등록기”가 부가적으로 제공되어야 한다.
상기와 같은 각 구성 요소에 대하여 차례로 상세히 설명하면 다음과 같다.
① 송수신 개체
전자문서유통의 기반 인프라 구성요소 중 유통의 기준이 되는 단위가 송수신 개체인데, 송수신 개체는 유통에 참여하는 역할에 따라 송신자(Sender) 또는 수신자(Receiver)을 같이 수행하게 되며, 이 개체들은 유통 메시징서버 시스템을 통해 유통 프로토콜 규격에 따라 문서(정보)를 유통한다.
유통에 참여하는 모든 송수신 개체는 유통메시징 규격에 따라 문서를 송수신할 수 있는 유통 메시징서버 시스템을 구축한 후, 유통 메시징서버 시스템의 물리적 주소정보를 주소디렉터리 서버에 등록함으로써 전자문서유통에 참여할 수 있는 기반을 만들게 된다. 이 때, 각 송수신 개체들은 하위에 1개 이상의 공인전자주소를 갖는 실 유통 사용자를 갖게 된다.
전자문서유통에서 송수신 개체로서 인정받을 수 있는 개체는 메시징서버 규격을 준수한 시스템을 구축한 후, 정보통신산업진흥원에 의해 표준적합성과 상호운용성을 인증받은 개체로 한정되며, 유통을 증명하기 위해서는 ① 인증 받은 송수신 개체를 통해 전자문서가 유통된 후, ② 표준규격에 맞게 유통증명서를 발급하여 제3자 보관기관에 보관하여야 한다.
이때, 송수신 개체는 전자문서에 대한 법적 소유자 및 책임자로서 직접 전자문서 전송을 책임지는 개체와, 유통되는 전자문서의 실 소유자이며 책임자인 사용자를 위해 전자문서를 대행해 주는 개체로 구분된다. 전자문서의 소유자가 직접 전자문서를 전송하는 송수신 개체인 경우에는 유통 메시징서버 시스템의 표준적합성과 상호운용성을 인증받고, 유통증명서를 안전하게 제3자 보관기관에 보관하는 것만으로도 송수신 개체에 참여할 수 있다.
그러나 전자문서 소유자(사용자)를 대행해서 3자 전송을 책임져야 하는 송수신 개체인 경우에는 송수신 개체가 안전하고 신뢰성 있는 방법으로 전송메시지를 관리하고, 사용자 정보를 관리하고 인증하는지에 대한 부분까지 입증하여야 한다. 3자 유통의 안전성 및 신뢰성을 보장하기 위해 한시적으로 이러한 3자 유통이 가능한 송수신 개체로는 제3자 보관기관 사업자만으로 한정한다.
② 유통 메시징서버 시스템
유통 메시징서버 시스템은 유통 메시징서버 규격을 바탕으로 전자문서(정보)를 유통하기 위해 메시지 송수신기능과 주소 디렉터리 서버와 연계하여 수신자에 대한 주소정보 및 보안 관련한 정보를 검색하는 기능을 반드시 구축하여야 한다. 유통 메시징서버 시스템은 물리적으로 하나의 전자주소(IP Address)를 가지나 하위의 사용자를 위해 복수의 사용자 계정을 발급하고 관리할 수 있으며, 사용자 계정은 각각 하나의 공인전자주소를 갖게 된다.
유통 메시징서버 시스템은 각 사용자 계정을 관리하기 위해 사용자 계정별 전자문서 사서함을 관리하여야 하며, 유통 메시징서버 시스템은 이 사용자 계정을 대표하여 안전하고 신뢰성 있는 전자문서유통 책임을 갖게 된다.
이와 같은 유통 메시징서버 시스템이 전자문서유통 내에 송수신 개체로서 참여하기 위해서는 본 발명에 따른 요건에 적합하게 구현이 되어 있는지, 타 솔루션과 상호 운용에는 문제가 없는지를 인증 받는 과정을 거쳐야 한다.
유통 메시징서버 시스템에 대한 표준 적합성 및 상호 운용성을 인증해 주는 인증 시스템은 인증된 송수신 개체를 관리하여야 하며, 주소 디렉터리 서버가 공인전자주소를 등록하는 과정에 인증 통과 여부 확인을 요청하면 그 결과를 돌려주어야 한다.
유통 메시징서버 시스템이 인증을 받아 공인전자주소로서 등록을 하기 위해서는 도 82 및 아래와 같은 절차를 따라야 한다.
먼저, 송수신 개체가 되고자 하는 기업/기관 또는 개인사용자는 본 기술규격에 적합하게 유통 메시징서버 시스템을 구축한다.
다음으로, 인증 테스트 베드가 제공하는 자동화된 검증도구를 통해 구축된 유통 메시징서버 시스템의 표준적합성 및 상호운용성을 검증한다.
다음으로, 자체 검증을 모두 완료한 송수신 개체는 인증테스트베드에 인증시험을 요청한다.
다음으로, 인증 테스트 베드의 테스트 절차에 따라 시스템에 대한 인증을 마친 후 결과가 “통과”로 나오면 송수신 개체는 공인전자주소 등록을 위한 다음 절차를 준비한다.
다음으로, 인증 테스트 베드는 인증심사를 통과한 송수신 개체에 대한 정보를 주소 디렉터리 서버에 전달하고, 주소 디렉터리 서버는 이 정보를 주소 등록의 조건으로 활용한다.
다음으로, 송수신 개체는 인증 통과된 유통 메시징서버 시스템을 등록하기 위해 주소 디렉터리 서버에 고유의 ID 발급을 신청한다.
다음으로, 유통 메시징서버 시스템이 주소디렉터리 서버에 등록이 완료되면, 유통 메시징서버 시스템은 전자문서유통에 참여할 수 있게 된다.
다음으로, 유통 메시징서버 시스템의 인증이 완료되면 사용자 계정을 개설하고 대표 공인전자주소인 경우에 사용자 계정은 공인전자주소에 등록요청을 한다.
③ 주소디렉터리 서버
신뢰할 수 있는 전자문서유통에 참여하기 위해서 모든 사용자는 고유의 전자주소를 발급받아야 한다.
④ 유통 클라이언트 APP
유통 클라이언트 APP는 문서유통에 참여하는 사용자들을 위해 문서 송신 및 수신, 수신문서 열람 및 관리 등의 UI를 제공하는 어플리케이션을 지칭한다. 유통 클라이언트 APP는 독자적으로 문서를 송수신할 수 없으며 반드시 유통 메시징서버 시스템과 연계되어야 한다.
유통 클라이언트 APP에서 작성되거나 첨부된 문서는 유통 메시징서버 시스템에 전달되어 전송을 요청하게 되며, 유통 메시징서버 시스템을 통해 수신된 문서를 조회하게 된다. 유통 메시징서버 시스템이 사용자 계정을 통해 송수신 사서함을 관리하는 경우라면 유통 클라이언트 APP는 수신문서 중 사용자 계정정보 확인을 통해 해당 문서에만 접근이 가능하다.
유통 클라이언트 APP는 사용자의 요구에 의해 C/S 형태의 어플리케이션으로 구현될 수도, 웹 형태의 화면으로 구현될 수도 있다.
⑤ 공공부문 연계 게이트웨이
전자문서유통을 수용하기 어려운 행정 및 공공기관의 경우 공공부문 연계 게이트웨이를 통해 행정, 공공기관과 전자문서유통 체계 하의 민간기업, 기관, 개인들 간 문서를 중계하는 역할을 수행한다.
⑥ 전자문서 서식 등록기
전자문서 서식 등록기는 유통 메시징서버 시스템을 이용해서 전자문서를 전송하고자 하는 사용자들이 Office 도구를 이용해서 직접 전송문서를 작성할 수도 있으나, 사용자가 좀 더 쉽게 전자문서 생성할 수 있도록 지원하기 위해 표준문서 양식을 등록하고 관리하면서 유통 클라이언트 APP와 같은 사용자용 어플리케이션이 이용할 수 있도록 문서 양식 등록 및 관리, 문서 양식 검색, 열람 및 다운로드, 문서 양식 삭제 등의 관리를 지원하는 시스템이다.
전자문서 서식 등록기는 문서표준양식을 관리하는 서버 엔진과 클라이언트 어플리케이션(APP)이 이를 검색하고, 다운로드 받은 후에 내부 프로그램에 플러그인(Plug-In)하여 사용할 수 있도록 하는 표준인터페이스를 제공한다.
[전자문서 유통 방법]
전자문서유통에서 전자문서를 유통하기 위한 전체 프로세스는 “① 유통 전 사전 준비단계”, “② 전자문서 유통 단계”, “③ 유통을 위한 증빙 단계”의 3단계로 크게 구분해서 볼 수 있다. 이하에서는 상기 세 단계에 대한 상세한 설명과 함께, "문서 송수신 방안"과 "유통증명 방안"과 "스팸 메시지 처리 방안"에 대하여 상세히 설명하도록 한다.
① 유통 전 사전 준비단계
- 전자문서 서식 등록기 관리자는 전자문서 시식 등록기를 이용해서 사용할 표준문서 서식을 등록한다.
- 송수신 참여자는 자체적으로 신뢰유통을 위한 유통 메시징서버 시스템을 구축할 지, 기 구축된 유통 메시징서버 시스템에 사용자 계정을 개설하고 사용할 지 여부를 결정한다. 자체적으로 신뢰유통을 위한 유통 메시징서버 시스템을 구축하는 경우에는, 전자문서 송수신을 위한 유통 메시징서버 시스템을 구축한 후에, 인증기관을 통해 유통 메시징서버 시스템의 표준적합성, 상호운용성에 대한 인증테스트를 수행한 후에, 주소 디렉터리 서버에 접속한 후 인증된 유통 메시징서버 시스템을 위한 송수신 개체 ID를 신청하고 발급받은 후에, 내부의 실 사용자를 위해 자체적으로 내부 구분자를 등록하고 관리하며, 표준문서 서식 기반의 문서 작성 기능을 이용하기 위해 일반사용자를 위한 클라이언트 어플리케이션에 표준문서 서식 작성기능을 플러그인(Plug-In)한다(선택적 사항). 반대로, 3자 유통이 가능한 유통 메시징서버 시스템을 보유한 송수신 개체를 이용하는 경우에는, 유통 메시징서버 시스템을 통해 기업/기관/개인을 위한 사용자 계정 개설을 요청한 후에, 사용자 계정에 대한 공인전자주소 정보를 주소 디렉터리 서버에 등록한 후에, 표준문서 서식 기반의 문서 작성기능을 이용하기 위해 일반사용자를 위한 클라이언트 어플리케이션에 표준문서양식 작성기능을 플러그인(Plug-In)한다(선택적 사항).
② 전자문서 유통 단계
○ 문서 송신자
- 문서 송신자는 유통할 문서를 선택하거나 문서작성기를 통해 전송할 문서를 작성한다.
- 문서 수신 상대방 주소정보 및 전달 문서, 문서 암호화여부 및 전자서명 여부를 선택한다. (암호화 및 전자 서명은 전송 메시지가 아닌 첨부하는 전달 문서를 대상으로 하며, 이 절차는 선택적 사항임)
- 유통 클라이언트 APP는 주소 디렉터리 서버에 연계하여 수신 상대방의 공인 전자주소를 기반으로 물리적 주소정보 및 암호화를 위한 공개키 정보를 획득한다. (선택적 사항으로, 유통 클라이언트 APP가 물리주소 획득을 하지 않은 경우 유통 메시징서버가 이 작업을 수행함)
- 유통 클라이언트 APP는 유통 메시징서버에 수신자의 주소정보를 기반으로 전송요청을 한다. (물리적 주소정보 또는 공인 전자주소 모두 가능)
○ 송신자의 유통 메시징 서버
- 유통 클라이언트 APP에서 요청한 전송요청 메시지가 수신자에 대한 물리적 주소정보가 아닌 경우, 유통 메시징서버는 공인전자주소를 기반으로 수신자의 송수신 개체에 대한 물리적 주소정보를 주소 디렉터리 서버에 질의한다.
- 전자문서를 유통 프로토콜 규격에서 정의한 메시지 구조체로 패키징한다.
- 송신자 유통 메시징서버의 공인인증서 기반으로 메시지에 전자서명을 한다.
- 수신자의 물리적 주소정보로 메시지를 전송한다.
○ 수신자의 유통 메시징 서버
- 메시지 수신 후, 수신메시지 검증하고 메시지에서 문서를 추출한다.
- 동기식 응답으로 수신증명서를 포함한 메시지를 송신자에게 전송한다.
③ 유통을 위한 증빙 단계
- 수신자는 문서 수신사실 확인을 위한 문서 수신시점에 “수신증명서”를 생성한 후 송신자에게 전달하여야 하며, 이를 수신한 문서 송신자는 “수신증명서”를 제3자 보관기관에 보관한다.
- 송신자가 요구할 경우, 수신자는 수신문서를 실 문서 담당자(사용자)에게 전달한 후, 담당자가 수신문서를 확인한 시점에 “열람증명서”를 생성하여 송신자에게 전달하며, "열람증명서"를 수신한 문서 송신자는 “열람증명서”를 제3자 보관기관에 보관한다.(열람증명서의 발급은 송신자의 요청이 있을 경우에만 적용됨)
- 송신자가 수신자에게 문서전달을 시도하였으나 실패한 경우에는 송신 시도에 대해 증빙을 하고자 객관적 3자인 전자문서 유통허브에 문서 전송을 의뢰하며, 전송의뢰를 받은 전자문서 유통허브는 전송의뢰를 받았음을 입증하고자 “송신증명서”를 발급하여 송신의뢰자에게 전달하고 이를 수신한 송신의뢰자는 “송신증명서”를 제3자 보관기관에 보관한다.
○ 문서 송수신 방안
유통 메시징서버 시스템을 통해 송신자와 수신자는 문서를 전자적으로 유통합니다. 유통 메시징서버 시스템은 유통 프로토콜에 따라 전자문서를 송수신하며, 신뢰메시지 유통을 위해서 모든 메시지는 전송과 수신확인(또는 수신증명서) 메시지의 조합으로 이루어지며, 수신자에 대한 물리적 주소정보는 주소 디렉터리 서버를 통해 획득하게 된다.
○ 유통증명 방안
"유통증명"이라 함은 전자문서 유통과 관련된 송신, 수신, 열람에 대하여 해당 사실을 신뢰성 있는 방법으로 증명하는 것을 말하는 것으로, 이때 전자문서 유통과 관련된 행위에 대하여 발급하는 증명서를 통칭하여 "유통증명서"라고 한다.
유통 메시징서버 시스템은 송신, 수신에 대한 행위 입증을 위해 송신 및 수신 시점에 유통증명서를 발급하고, 발급한 유통증명서를 공인 전자문서 제3자 보관기관에 보관함으로써 유통 행위에 대한 증빙 자료로서 활용할 수 있도록 한다.
유통 메시징서버 시스템은 전자문서 송신, 수신, 열람에 대한 사실을 증명하며 각 사실에 대한 유통증명서를 생성하며, 유통증명서는 유통증명서 식별정보, 유통증명서 생성시각 및 만료시각, 유통증명서 정책 및 유통증명 대상을 포함한다.
전자문서 송신에 대한 유통증명서는 전자문서 유통허브가 생성하며 유통증명 대상에 발신자 식별정보, 수신자 식별정보, 유통 식별정보, 문서 식별정보, 전자문서 송신의뢰 시각을 포함한다.
전자문서 수신에 대한 유통증명서는 전자문서를 수신한 수신자가 생성하며 유통증명 대상에 발신자 식별정보, 수신자 식별정보, 유통 식별정보, 문서 식별정보, 전자문서 송신 시각, 전자문서 수신 시각을 포함한다.
전자문서 열람에 대한 유통증명서는 전자문서를 수신 확인한 사용자가 생성하며 유통증명 대상에 발신자 식별정보, 수신자 식별정보, 유통 식별정보, 문서 식별정보, 전자문서 송신 시각, 전자문서 수신 시각, 전자문서 수신확인 시각를 포함하여야 한다.
이와 같이 생성된 유통증명서는 NPKI 또는 GPKI 인증서로 전자서명 되어야 하고, 생성된 유통증명서는 전자문서 송신자에게 전달되어야 하며, 모든 유통증명서는 제3자 보관기관에 보관되는 것이 바람직하다.
○ 스팸 메시지 처리 방안
전자문서유통은 기본적으로 송신자가 인증된 유통 메시징서버 시스템을 통해 전송을 하고, 수신자 역시 이를 기본으로 수신하므로 스팸을 발송하였을 때 전송자에게 책임을 물을 수 있는 기반구조를 가진다. 그러나, 스팸 발송자가 유통 메시징서버 시스템에 사용자 계정을 개설하고 이를 이용해서 전송을 하는 경우가 있을 수 있다. 또한, 현재의 인증방식이 시스템의 기술적 내용에 대한 인증만을 대상으로 하고 있어서, 스팸발송자가 유통 메시징서버 시스템을 구축하고 이를 기술적으로 인증한 후 스팸 발송수단으로 사용하였을 때, 초기에 원천적으로 봉쇄하기가 쉽지 않은 상황이다.
따라서, 이와 같은 문제점을 해결하기 위해 본 발명에 따른 표준문서 유통 인프라에서는 인증목록 관리 기반의 화이트리스트, 사용자 신고방식에 의한 스팸대상 목록 관리 기반의 블랙리스트를 체계를 제공하며, 이러한 체계에 의해 수신자가 수신거부를 할 수 있는 프로세스를 적용하여 스팸메시지를 방지할 수 있도록 한다.
스팸메시지 신고 및 송신 상대방에 대한 확인을 위한 기능은 필수 기능으로 모든 유통 메시징서버는 이 기능을 반드시 구축하여야 한다.
수신자는 수신한 메시지가 스팸 메시지라고 판단이 되면, 도 83에 도시한 바와 같은 프로세스에 의해 스팸메시지를 전자문서 유통허브의 주소 디렉터리 서버에 신고하며, 이와 관련한 처리 절차는 다음과 같다.
먼저, 수신자가 메시지를 수신한 시점에서 스팸메시지라고 판단되면, 수신자는 유통 메시징서버 시스템을 통해 주소 디렉터리 서버에 해당 메시지를 수신 메시지로 신고한다.
다음으로, 유통 메시징서버 시스템으로부터 스팸메시지 신고를 접수한 주소 디렉터리 서버는 접수되었음에 대한 확인메시지를 되돌려준다.
다음으로, 주소 디렉터리 서버를 관리하는 주체인 정보통신산업진흥원은 해당 메시지를 분석하고, 송신자에 대한 조사를 통해 송신자의 공인전자주소에 대해 블랙리스트 추가 여부를 심사하고 판단한다.
다음으로, 최종적으로 블랙리스트 대상자로 확정이 되면, 주소 디렉터리 서버는 해당 공인전자주소를 블랙리스트에 추가한 후, 송신자에게 블랙리스트 추가에 대한 내용을 통지한다.
다음으로, 주소 디렉터리 서버는 스팸메시지 요청에 대한 처리 결과를 스팸신고자(수신자)에게 전달한다.
상기와 같은 처리 절차에 있어서 화이트리스트는 송신 유통 메시징서버 시스템이 인증을 받고 정식으로 등록된 메시징서버 시스템에 대한 정보만 기록되고, 블랙리스트는 전송자의 주소가 스팸발송자로 등록된 경우에 등록되며, 동일한 유통 메시징서버 시스템을 통해 블랙리스트에 등록되는 스팸 주소가 중복 발생되는 경우에는 전자문서 유통허브에서 해당 유통 메시징서버 시스템에 대한 인증취소 여부를 판단한 후, 인증을 취소하고 화이트리스트에서 삭제할 수 있다.
수신자는 메시지 수신 시, 송신 상대방이 신뢰할만한 정당한 사용자인지 여부를 확인하기 위해 주소디렉터리 서버의 화이트리스트와 블랙리스트를 확인한 후, 수신거부를 할지의 여부를 결정한다. 송신자에 대한 확인은 수신시점에 실시간 확인을 하거나, 수신자의 유통 메시징서버 시스템에 Cache 형태로 관리하고 있는 목록을 통해 확인하는 주기적 확인 방법이 있다.
실시간으로 송신자에 대한 확인을 수행하는 프로세스는, 도 84에 도시한 바와 같이 수신자가 메시지를 수신하는 시점에 주소 디렉터리 서버에 송신자의 주소가 화이트리스트, 블랙리스트에 등록되었는지의 여부를 판단한 후에 메시지에 대한 수신거부 여부를 결정하며, 이와 같이 실시간으로 송신자에 대한 확인을 수행하는 프로세스의 상세한 처리절차는 다음과 같다.
먼저, 수신자의 유통 메시징서버 시스템은 메시지를 수신하면 주소 디렉터리 서버에 정당한 사용자인지 여부를 확인하기 위해 확인요청 메시지를 전달한다.
다음으로, 주소 디렉터리 서버는 요청받은 사용자의 주소정보가 화이트리스트에 포함되어 있는지 여부를 확인한다.
다음으로, 해당 주소가 화이트리스트에 없으면 주소 디렉터리 서버는 바로 확인 요청자에게 등록되지 않은 사용자임을 결과메시지로 돌려주고, 화이트리스트에 있으면 다시 해당주소가 블랙리스트에 등록된 주소인지 여부를 확인한다.
다음으로, 주소 디렉터리 서버는 확인 요청자에게 블랙리스트 등록 여부에 대한 결과 메시지를 돌려준다.
다음으로, 수신자는 주소 디렉터리 서버로부터 송신자가 정당한 사용자가 아니라는(화이트리스트에 없거나 블랙리스트에 등록된 경우) 결과메시지를 받은 경우에는 수신메시지를 자체적으로 스팸메시지로 처리한 후, 주소디렉터리 서버로부터 받은 처리결과 메시지와 스팸메시지 수신이력을 기록하고 보관한다.
다음으로, 스팸메시지에 대한 처리 이력은 반드시 한 달 이상 보관함으로써, 해당 송신자에 대한 수신거부의 정당성을 확인할 수 있도록 한다.
그리고, 주기적으로 송신자에 대한 확인을 수행하는 프로세스는 도 85에 도시한 바와 같이 수신자는 사전에 주소 디렉터리 서버로부터 화이트리스트와 블랙리스트를 받아서 자체적으로 관리하고 이를 기반으로 송신자의 주소가 화이트리스트, 블랙리스트에 등록되었는지 여부를 판단한 후 메시지에 대한 수신거부 여부를 결정하며, 이와 같이 주기적으로 송신자에 대한 확인을 수행하는 프로세스의 상세한 처리절차는 다음과 같다.
먼저, 수신자의 유통 메시징서버 시스템은 미리 주소 디렉터리 서버로부터 최신의 화이트리스트와 블랙리스트를 요청한 후 자체적으로 관리한다. 이때, 리스트의 변동사항 발생 시 자동 통지 요청 여부를 같이 전달한다. 이와 같은 변동사항 발생 자동통지를 요청한 경우에도 주소 디렉터리 서버에 최신 리스트를 가져오기 위한 요청은 주기적으로 함으로써 리스트 정보가 최대한 1일 이상 차이가 나지 않도록 한다.
다음으로, 주소 디렉터리 서버는 화이트리스트 및 블랙리스트에 변동사항이 발생하면 변동 통지요청을 한 사용자에게 변동내역을 브로드캐스팅(broadcasting)한다.
다음으로, 리스트에 대한 변동사항을 받은 사용자 유통 메시징서버 시스템은 자체 관리하는 리스트의 정보를 수정함으로써 동기화를 시켜준다.
다음으로, 수신자는 메시지를 수신하면 주소 디렉터리 서버에 정당한 사용자인지 여부를 확인하기 위해 자체 관리하는 리스트를 확인한다.
다음으로, 수신자는 자체 관리하는 리스트 점검결과 송신자가 정당한 사용자가 아니라고(화이트리스트에 없거나 블랙리스트에 등록된 경우) 판단한 경우에는 수신메시지를 자체적으로 스팸메시지로 처리한 후, 스팸메시지 수신 이력을 기록하고 보관한다.
다음으로, 스팸메시지에 대한 처리 이력은 반드시 한 달 이상 보관함으로써, 해당 송신자에 대한 수신거부의 정당성을 확인할 수 있도록 한다.
[유통 메시징서버 시스템]
이하에서는, 상술한 바와 같은 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템의 유통 메시징서버 시스템과 관련하여 상세히 설명하도록 한다.
유통 메시징서버 시스템은 크게 메시지 송신, 메시지 수신, 수신 메시지에 대한 사서함 관리, 메시지 보안(사용자 인증, 문서 암/복호화 등), 송수신 이력관리, 주소디렉터리 서버 연계, 메시지 검증, 내부시스템 연계인터페이스, 유통증명서 발급 및 관리, 제3자 보관기관 연계 등으로 구성된다.
도 86에는 유통 메시징서버 시스템의 구조를 도시하였으며, 이와 같은 도 86을 참조하여 유통 메시징서버 시스템의 구성 요소 각각(①~⑨)에 대하여 상세히 설명하면 다음과 같다.
① 메시지 송수신
- 유통 프로토콜에 따라 메시지를 송신하고 수신한다.
② 사용자 별 계정(사서함) 관리
- 송수신한 메시지를 사용자 계정 또는 내부구분자에 따라 계정별 사서함에 보관한다.
- 사서함에 보관한 송신문서에 대하여 "송신 중", "송신 완료", "송신 실패", "담당자 수신 완료"를 포함하는 4단계의 상태정보를 관리한다. 이때, "중신 중" 상태는 문서 전송 후 수신자로부터 아무런 응답을 받지 못한 상태이며, "송신 완료" 상태는 수신자의 유통 메시징서버 시스템으로부터 "수신증명서"를 받은 상태이고, "송신 실패" 상태는 수신 유통 메시징서버 시스템 내부에서 오류가 발생하여 SOAP Fault 메시지를 리턴하거나, 송수신 과정에서 네트워크 오류가 발생한 경우이며, "담당자 수신 완료" 상태는 송신 유통 메시징서버 시스템이 수신자로부터 담당자의 문서를 확인했음을 증명하는 "열람증명서"를 받은 경우이다.
- 사용자 계정별 사서함에 보관된 수신문서에 대하여 "검증오류", "수신 확인 전", "수신 확인", "열람 확인"을 포함하는 4단계의 상태정보를 관리한다. 이때, "검증오류" 상태는 수신한 메시지에 대한 기본구조 검증에서 오류 발생한 상태이며, "수신 확인 전" 상태는 수신문서 담당자가 사서함의 수신 문서 목록을 읽기 전이고, "수신 확인" 상태는 수신문서 담당자가 사서함의 수신 문서 목록을 읽은 상태이며, "열람 확인" 상태는 수신문서 담당자가 수신문서에 대한 상세내용을 열람한 상태로서 이 시점에 수신자의 유통 메시징서버 시스템은 "열람증명서"를 발급한 후에 송신자에게 전달한다.
- 수신사용자에 의해 삭제 요청이 오면 해당 수신문서를 물리적으로 삭제 처리한다.
- 사서함에서 송신문서, 송신에 대한 수신확인 메시지, 수신담당자의 수신확인 메시지는 서로 연관될 수 있도록 연관정보를 가진다.
③ 주소 디렉터리 서버 연계
- 주소 디렉터리 서버가 제공하는 주소정보 등록 및 검색 프로세스에 따라 주소정보를 관리한다.
- 주소 디렉터리 서버가 제공하는 서비스를 호출할 수 있는 클라이언트 기능을 포함한다. 즉, 주소 디렉터리 서버가 제공하는 주소정보 등록, 검색, 수정, 삭제 기능을 원격에서 호출하는 서비스 클라이언트 기능을 제공한다.
④ 메시지 보안(사용자 인증, 문서 암/복호화 등)
- 유통 프로토콜에서 제시하는 메시지 보안 기능(메시지 전자서명, 서명 검증)을 기본적으로 수행한다.
⑤ 송수신 이력 관리
- 유통 메시징서버 시스템은 송수신 이력에 대해 최소 1년 이상은 반드시 보관/관리한다.
- 보관하는 송수신 이력에 대한 정보는 송신 이력과 수신 이력이며, 송신 이력은 메시지 id, 연관메시지 id, 송신자(사용자 계정 포함), 수신자, 송신시간, 송신 문서에 대한 해쉬 값을 포함하며, 수신이력은 송신자, 수신자(사용자 계정 포함), 수신시간, 수신 문서에 대한 해쉬 값을 포함한다.
⑥ 유통증명서 발급 및 관리
- 유통 메시징서버 시스템은 문서 송수신 사실에 대한 내용을 증빙할 수 있도록 유통증명서를 발급하고 관리한다.
- 발급된 유통증명서는 전달받자마자 제3자 보관기관에 보관 의뢰함으로써 그 신뢰성을 보장받는다.
- 발급된 후 제3자 보관기관에 보관된 유통증명서 이력을 관리하며, 유통증명서 발급 이력은 유통증명서 id, 유통증명서 발급 시각, 관련 메시지 id, 유통증명서 원본(선택적), 제3자 보관기관 보관 후 수신한 보관-key정보를 포함한다.
⑦ 메시지 패키지 처리 (Packaging, Parsing, Extracting)
- 송신 문서를 전송 전에 유통 프로토콜에 정의된 메시지구조로 패키징(Packaging) 한다.
- 수신한 문서를 유통 프로토콜에 정의된 메시지구조에 의해 파싱(Parsing, 구문해석)하고 필요한 정보를 추출(Extracting)한다.
⑧ 유통증명서 보관요청
- 일반 송수신 개체가 유통증명서의 보관요청을 위해서는 제3자 보관기관의 유통 메시징서버 시스템에 제3자 보관기관 보관요청메시지를 전송한다.(원격 보관요청)
- 제3자 보관기관의 유통 메시징서버 시스템은 공인전자문서보관소 보관요청 메시지를 수신하면, 제3자 보관기관에 유통증명서 보관을 위한 보관요청 Client를 호출한다.
- 제3자 보관기관의 유통 메시징서버 시스템이 직접 유통증명서를 생성한 경우에는 생성시점에 제3자 보관기관 보관요청 Client를 직접 호출한다.(로컬 보관요청)
- 유통증명서 보관요청을 위한 Client는 제3자 보관기관의 송수신 연계인터페이스 규격에 따라 제3자 보관기관에 보관을 요청한다.
⑨ 부가 서비스
- 유통 클라이언트 APP 관리의 배포, 버전 관리 등을 수행한다.
- 메시지 유통관리(이력, 통계정보 등)를 수행한다.
- 시스템 관리(시스템 모니터링, 환경정보 등)를 수행한다.
- 문서양식(Form) 관리를 수행한다.
상기와 같은 ①~⑨의 구성 요소를 가지는 본 발명에 따른 유통 메시징서버 시스템을 도 87과 같이 제3자 보관기관에 적용한 경우에는, 유통증명서를 보관할 시에 유통증명서 보관요청 모듈은 제3자 보관기관 연계인터페이스 규격에 따라 개발된 연계인터페이스 클라이언트를 호출하여 보관 요청을 한다.
상기와 같은 ①~⑨의 구성 요소를 가지는 본 발명에 따른 유통 메시징서버 시스템을 도 88과 같이 일반 송수신 개체(일반 사업자)에 적용한 경우에는, 유통증명서를 보관할 시에 제3자 보관기관 사업자의 유통 메시징서버 시스템에 유통증명서 보관을 요청하는 메시지를 전송하고 처리 결과를 받아오는 방식으로 처리한다.
상기와 같은 ①~⑨의 구성 요소를 가지는 본 발명에 따른 유통 메시징서버 시스템을 이용하여 송신자와 수신자 간에 직접 메시지를 유통하는 프로세스는, "①수신자에 대한 물리적 주소 및 보안정보 획득", "② 메시지 전송 및 전송확인", "③ 업무수신자의 수신확인", "④ 유통증명서 발급 및 보관"을 포함하는 4단계로 이루어지는데, 이와 같은 4단계와 관련하여 도 89를 참조하여 상세히 설명하면 다음과 같다.
① 수신자에 대한 물리적 주소 및 보안정보 획득
- 송신자의 시스템은 상대방에 대한 주소 정보를 바탕으로 실제 메시지가 전달되어야 할 물리적 주소 정보 및 보안정보(송신메시지에 대한 수신암호를 필요로 하는 경우)를 주소 디렉터리 서버에 요청함으로써 이를 획득한다.
- 수신자에 대한 물리적 주소 및 보안 정보는 유통 클라이언트 APP가 주소 디렉터리 서버에 요청한 후에 수신자의 물리적 주소 정보를 유통 메시징 서버에 전달하도록 한다.
- 사용자에 대한 id(예: 주민등록번호, 사업자 등록번호 등)만으로 수신자에 대한 주소정보를 획득할 수도 있으나, 이 경우에는 수신자가 송신자에게 id 기반의 주소정보 검색을 허용한 경우에만 가능하다.
* 송신자가 수신자의 물리적 주소 정보 및 보안 정보를 이미 알고 있는 경우에 이 절차는 생략이 가능하다.
② 메시지 전송 및 전송확인
- 송신자는 메시지를 유통 프로토콜 규격에 맞게 패키징 한 후, 유통 메시징서버 시스템의 공인인증서를 기반으로 전자서명을 수행한다.
- 유통 메시징서버 시스템은 앞서 획득한 물리적 주소에 패키징하고 전자서명된 메시지를 전송한다.
- 메시지를 수신한 수신 유통 메시징서버 시스템은 메시지의 기본 패키징 구조, 전자서명에 대한 유효성, 송신자에 대한 적합성(검증에 대한 상세 내용은 “2.4.6 메시지 검증”부분 참조)을 검증한 후, 수신확인을 위한 수신증명서 또는 오류메시지를 생성한다.
- 수신 유통 메시징서버 시스템은 생성한 응답메시지를 송신자에게 전송한다.
- 전송과 전송확인 과정은 동기식 메시지 처리로 이루어진다.
③ 업무수신자의 수신확인
- 송신자가 메시지 전송시점에 업무 수신자의 담당자 열람확인 메시지를 요청한 경우에는 수신자는 메시지에 대한 업무적 수신확인 시점에 송신자에게 반드시 담당자 열람확인을 증빙할 수 있는 열람증명서를 생성하여 이를 전송하여야 한다.
- 수신자가 메시지 송신자에게 담당자 열람확인을 위한 열람증명서 메시지를 보내면 원 메시지 송신자를 이에 대한 수신확인 메시지를 동기식으로 보내준다.
④ 유통증명서 발급 및 보관
- 각 단계별로 유통에 대한 증빙을 받고자 하는 경우 송신자는 각 단계에 따라 수신, 열람, 송신에 대한 증명서를 발급하고 이를 제3자 보관기관에 보관함으로써 유통에 대한 법적 증빙의 근거를 확보한다.
본 발명에 따른 유통 메시징서버 시스템을 이용하여 송신자와 수신자 간에 직접 메시지를 유통하는 프로세스는 상기와 같은 "①수신자에 대한 물리적 주소 및 보안정보 획득", "② 메시지 전송 및 전송확인", "③ 업무수신자의 수신확인", "④ 유통증명서 발급 및 보관"외에 "⑤오류 처리"도 수행하는데, 도 90 내지 도 92를 참조하여 오류 처리 기능과 관련하여 상세히 설명하면 다음과 같다.
⑤오류 처리 기능
유통 메시징서버 시스템의 모든 메시지 송수신 프로세스는 동기식 처리를 기본으로 한다. 따라서, 전송에 대한 모든 오류는 전송자가 확인 가능하므로 재전송하는 것을 기본으로 하며, 동일한 메시지 전송은 동일한 MessageId 값을 설정하여 다시 보내도록 함으로써 수신자가 수신 성공 후 수신확인 메시지 전송과정에서의 오류에 대해서도 중복메시지 수신을 감지할 수 있도록 한다.
유통 메시징서버 시스템은 요청메시지 송신에 실패한 경우에 도 90과 같은 처리 흐름도를 따른다. 즉, 메시지 송신자가 전송하는 과정에서 네트워크 오류 등에 의해 전송오류가 발생한 경우에 송신자는 HTTP 오류와 같은 오류 메시지를 받게 되면 동일한 메시지를 다시 재전송 요청하며, 송신자는 수신자에게 수신확인 메시지를 받은 경우에만 전송성공으로 인식한다.
유통 메시징서버 시스템은 응답메시지 수신에 실패한 경우에 도 91과 같은 처리 흐름도를 따른다. 즉, 메시지가 수신자에게 정상적으로 전달되었으나 송신자가 수신자로부터 수신확인 메시지를 받지 못한 경우에 송신자는 송신실패 오류로 인식하고 수신자게에 동일한 메시지를 동일한 MessageId로 재전송하게 되며, 수신자는 수신한 문서의 MessageId가 이전 수신 메시지와 동일한 경우에는 중복 수신으로 수신확인 메시지를 보낸 후 내부 처리를 한다.
유통 메시징서버 시스템은 오류메시지 수신에 실패한 경우에 도 92와 같은 처리 흐름도를 따른다. 즉, 송신자가 수신자에게 전송한 메시지가 정확히 전달되었으나 전송메시지 자체에 오류가 있어서 오류메시지를 응답받은 경우에 송신자는 오류 유형에 따라 메시지 처리를 달리하며, 재요청 시 전송하는 메시지의 MessageId는 동일할 필요는 없으며 업무 상황에 따라 다르게 처리할 수 있다.
상술한 바와 같은 본 발명에 따른 유통 메시징서버 시스템에 있어서 필수로 요구되는 기능인 "① 메시지 송수신", "② 수신 메시지 사서함 관리", "③ 메시지 보안", "④ 송수신 이력 관리", "⑤ 주소 디렉터리 서버 연계", "⑥ 메시지 검증", "⑦ 내부시스템 연계 인터페이스", "⑧ 유통증명서 발급 및 관리" 기능들에 대하여 상세히 설명하면 다음과 같다.
① 메시지 송수신
유통 메시징서버 시스템이 메시지를 송수신하는 기본 프로세스는 상술한 본 발명에 따른 [전자문서 유통 방법]의 "문서 송수신 방안"을 따른다. 메시지 송수신을 위한 기본이 되는 메시지 교환 유형은 메시지 유통 프로토콜의 동기식 응답을 기본으로 하며, 송신메시지와 수신확인 메시지, 송신 메시지와 수신오류 메시지, 송신 메시지와 비즈니스적 응답메시지(수신확인 메시지의 의미를 포함)의 구성을 이룰 수 있다.
메시지 송수신 유형으로는 송신과 수신확인 응답 메시지의 조합과, 송신과 비즈니즈 응답메시지의 조합을 포함하는 2가지 유형이 있다.
메시지 송수신 유형이 송신과 수신확인 응답 메시지의 조합인 경우에 처리 흐름은 도 93과 같으며, 송신 메시지와 수신확인(또는 수신오류) 메시지는 SOAP(Simple Object Access Protocol) Request-Response의 조합으로 이루어지며, 송신 메시지와 그에 대한 응답 메시지는 송신 메시지의 MessageId를 응답 메시지의 RefToMessageId에 넣어서 보냄으로써 연관관계를 맺어주는데, 이와 관련한 상세한 설명은 후술하는 [유통 프로토콜]을 참조한다.
메시지 송수신 유형이 송신과 비즈니스 응답메시지의 조합인 경우에 처리 흐름은 도 94와 같으며, 송신 메시지와 수신확인(또는 수신오류) 메시지를 포함한 응답메시지는 SOAP Request-Response의 조합으로 이루어지며, 수신자가 메시지를 수신한 후 내부시스템에 실시간 연계하여 비즈니스 처리한 응답문서를 생성한 후에 응답문서와 수신확인 ACK 메시지를 함께 응답메시지에 실어서 송신자에게 전달하며, 송신메시지와 그에 대한 응답메시지는 송신메시지의 MessageId를 응답메시지의 RefToMessageId에 넣어서 보냄으로써 연관관계를 맺어주는데, 이와 관련한 상세한 설명은 후술하는 [유통 프로토콜]을 참조한다.
송수신되는 메시지의 구조는 도 95에 도시한 바와 같이 MultiPart-MIME 구조를 가지며, 첫 번째 MIME 부분에는 SOAP 메시지가, 2번째 MIME부터는 전송하고자 하는 문서가 들어간다.
첫 번째 MIME은 SOAP 헤더와 SOAP Body로 구성된 SOAP Envelope이 들어가며, SOAP 헤더는 메시지 송수신을 위한 메시지 헤더 정보, 전자서명, 수신확인 메시지, 동기식 전송 표시, 오류 메시지 등이 들어간다. 그리고, 두 번째 MIME은 메시지 수신자에게 전달하는 문서(정보)가 들어가며, 담당자 수신확인 메시지를 전달하는 경우에 이 위치에 들어간다. 그리고, 세 번째 MIME은 메시지 수신자에게 전달하는 문서(정보)가 2개 이상인 경우 세 번째 MIME부터 순차적으로 들어간다.
② 수신 메시지 사서함 관리
유통 메시징서버 시스템은 메시지를 수신하면 수신 메시지를 계정 별로 사서함에 저장한다. 수신 메시지 사서함은 하나 이상의 사용자 계정 별로 구분되어 메시지를 저장 관리하며, 사용자의 요청(새 수신메시지 존재 여부, 수신메시지 열람, 수신메시지 다운로드, 수신메시지 삭제 등)에 따라 필요한 처리 후 결과를 돌려주는 인터페이스를 반드시 표준화된 방식으로 제공하여야 한다.
유통 메시징서버 시스템이 관리하는 사용자 계정이 전자문서유통에 포함되는 공인전자주소로서 자격을 갖기 위해서는 유통 메시징서버 시스템은 신뢰 사용자 계정을 갖기 위한 인증요건(차후 별도의 평가지침을 통해 요건을 정의할 것이며, 현 시점에서는 제3자 보관기관만이 이 인증요건을 충족한 것으로 인정함)을 통과하여야 한다.
따라서, 개인 또는 기업(기관)이 전자문서유통에서 공인전자주소를 획득하기 위한 방안으로는 다음과 같은 2가지 방안이 있다. 첫 번째 방안은, 자체적으로 유통 메시징서버 시스템을 구축하고 이를 인증 받은 후 획득한 송수신 개체 ID를 주소 디렉터리 서버에 등록하는 것이며, 두 번째 방안은, 인증 받은 유통 메시징서버 시스템 중 신뢰 사용자 계정을 갖는 요건을 추가적으로 충족한 송수신 개체에 사서함을 개설하여 사용자 ID를 발급 받은 후 이를 주소 디렉터리 서버에 등록하는 것이다.
③ 메시지 보안
전송 메시지에 대한 보안은 무결성 보장을 위한 전자서명과 기밀성 보장을 위한 암/복호화로 나눌 수 있다. 유통 메시징서버 시스템을 통해 전송되는 메시지는 SOAP 메시지와 첨부문서로 나뉜다. 이때, 첨부문서는 유통 클라이언트 APP에서 이미 암호화되어 있는 상태이고 SOAP Envelope에는 단지 메시지 송수신을 위한 헤더 정보만 포함되므로 유통 메시징서버 시스템에서는 추가적인 암호화 과정을 거치지 않으며, 메시지 송수신 과정에서 위변조 방지를 위한 전자서명 과정은 수행한다. 전자서명 방식 및 세부 절차는 후술하는 [유통 프로토콜]을 참조한다.
④ 송수신 이력 관리
유통 메시징서버 시스템은 향후 송수신에 관련한 분쟁이 발생하거나 이슈가 제기되었을 때, 이를 확인하기 위해 송수신에 대한 이력정보를 관리하여야 한다. 이력정보는 송수신 행위에 대한 정보뿐 아니라 실제 송수신한 문서에 대한 정보도 관리하여야 하는데, 실 문서를 제3자 보관기관에 보관한 경우에는 문서의 원본이 아닌 제3자 보관기관으로부터 받은 등록증명서만을 보관하는 것도 가능하다.
⑤ 주소 디렉터리 서버 연계
유통 메시징서버 시스템은 주소 디렉터리 서버가 제공하는 서비스 연계 인터페이스를 사용하여 주소 디렉터리 서버와 연계를 한다. 주소 디렉터리 서버는 2종류의 주소 검색 서비스와 주소 등록 서비스, 주소 변경 서비스를 제공하는데 유통 메시징서버 시스템은 주소 검색 서비스 중 “공인전자주소에 대한 물리적 주소 검색" 서비스 연계 기능은 필수적으로 제공한다.
검색 서비스 외에 주소 등록 및 주소 변경 서비스는 유통 메시징서버 시스템이 하위에 등록/관리하는 사용자 계정을 기업이나 개인의 공인전자주소로 사용할 수 있는지에 따라 사용 여부가 결정된다. 유통 메시징서버 시스템이 등록/관리하는 사용자 계정이 공인전자주소로 등록이 가능하도록 인증을 받은 경우에는 공인전자주소에 대한 등록 및 변경서비스를 대행하여야 하므로 주소 디렉터리 서버의 해당 서비스를 연계한다.
⑥ 메시지 검증
- 유통 메시징서버 시스템이 메시지를 송수신할 때 수신자는 메시지 수신시점에 메시지 유효성에 대한 검증을 수행하며, 도 96에 도시한 프로세스와 같이 수신자는 메시지 유효성 검증을 한 후 검증에 통과한 경우에만 메시지 수신확인 메시지를 송신자에게 전달하고, 그렇지 않은 경우에는 수신 메시지에 대한 오류 메시지를 전송한다.
- 검증대상: 수신 메시지의 스키마 검증(수신 메시지가 유통 프로토콜에 따라 정확히 패키징되었는지를 검증), 메시지의 무결성 검증(수신한 메시지의 전자서명 값을 검증함으로써, 메시지의 위변조가 발생하지 않고 무결한지를 검증), 메시지 송신자 검증(메시지에 전자서명을 한 송신자가 메시지에 표기된 송신자가 맞는지를 인증하기 위해 전자서명에 사용된 인증서와 메시지의 송신자가 동일한지를 검증)
⑦ 내부시스템 연계 인터페이스
유통 메시징서버 시스템은 내부 시스템이 유통 메시징서버 시스템을 통해 문서를 전송하고 수신할 수 있도록 송수신을 위한 표준화된 인터페이스를 제공하여야 한다. 이 인터페이스에 대한 상세한 내용은 후술하는 [유통 클라이언트 APP]를 참조한다.
⑧ 유통증명서 발급 및 관리
유통증명서의 기본요건은, ① 유통증명서는 발신 및 수신 유통 메시징서버 시스템이 생성한다는 것과, ② 유통증명서는 GPKI 및 NPKI 인증서를 기반으로 전자서명하여 생성된다는 것과, ③ 유통증명서는 전자문서 유통행위를 기준으로 생성(이때, 한 번의 전자문서 유통 시 하나 이상의 전자문서가 전달되는 경우 하나의 유통증명서를 생성하고, 하나의 전자문서 유통을 위해서는 반드시 해당 유통을 식별할 수 있는 ID가 부여되며 이를 기준으로 유통으로 유통증명서를 생성함)된다는 것이다.
유통증명서 발급 시점에 고려하여야 할 내용은, ① 유통증명서의 일련번호는 개별 송수신 개체가 생성하므로 유일성 부여를 위하여 기존 증명서의 규격과는 달리 20byte 난수를 사용하는 것과, ② 유통증명의 갱신 및 폐지는 정의하지 않는다는 것과, ③ 유통증명서를 생성하는 유통 메시징서버 시스템 및 유통 클라이언트 APP의 시스템 시각은 항상 현재 시각을 유지해야한다는 것과, ④ 유통증명서 정책은 기술규격에서 정의한 OID 및 명칭만을 사용한다.
유통증명서 발급 프로세스는 도 97에 도시한 바와 같으며, 유통 증명서의 유형 및 생성에 필요한 필수 정보는 아래 표141와 같으며, 유통 증명서의 필수 정보의 획득 방법은 아래 표142과 같다.
표 141
Figure PCTKR2011005027-appb-T000063
표 142
Figure PCTKR2011005027-appb-T000064
유통증명서는 송수신 개체가 생성하며 송수신 개체의 NPKI 및 GPKI 인증서를 이용하여 전자서명하며, 유통증명서의 기본 구조는 CMS 표준의 SignedData 구조를 사용하며 증명서와 동일한 콘텐츠 식별자를 사용한다.
유통증명서의 contentType 은 다음과 같다.
id-kiec-arcCertReseponse OBJECT IDENTIFIER ::= { iso(1) member-body(2) korea(410) kiec(200032) certificate(2) 2 }
ARCCertResponse ::= CHOICE {
arcCertInfo [0] EXPLICIT ARCCertInfo,
arcErrorNotice [1] EXPLICIT ARCErrorNotice }
유통증명서의 기본필드는 다음과 같다.
ARCCertInfo ::= SEQUENCE {
version [0] EXPLICIT ARCVersion DEFAULT v1,
serialNumber SerialNumber,
issuer GeneralNames,
dateOfIssue GeneralizedTime,
dateOfExpire DateOfExpiration,
policy ARCCertificatePolicies,
requestInfo RequestInfo,
target TargetToCertify,
extionsions [1] EXPLICIT Extensions OPTIONAL
}
상기와 같은 유통증명서의 기본필드에 대하여 상세히 설명하면 다음과 같다.
① version, 버전
- 유통증명서 구조의 버전을 나타낸다. 유통증명서를 위해서는 v2로 설정해야하며 target 필드에 dataHash를 사용한다.
ARCVersion ::= INTEGER {v1(1), v2(2)}
② Serial Number, 일련번호
- 유통증명서의 식별정보를 나타낸다. 유통증명서는 전자문서를 수신한 송수신 개체가 생성하므로 일련번호 방식의 식별번호는 의미가 없다. 또한, 송수신 개체의 유통클라이언트가 재설치되는 등의 경우에는 일련번호의 유지가 불가능하다.
따라서 유통증명서의 식별정보는 20byte 난수를 사용한다. 유통증명서를 처리하기 위해서는 20byte 난수를 처리할 수 있어야 한다.
SerialNumber ::= INTEGER
③ issuer, 증명서 발급자
- 유통증명서를 발급하는 발급자의 인증서 식별값을 넣는다. 본 필드의 값은 유통증명서를 전자서명한 서명자의 인증서 내 SubjectName 필드과 동일한 값을 가져야 한다.
④ dateOfIssue, 증명서 발급일
- 발급자가 유통증명서를 발급한 시점을 나타낸다.
⑤ dateOfExpire, 증명서 효력 만기일
- 유통증명서의 만료 시점을 나타낸다.
⑥ policy, 증명서 정책
- 유통증명서 정책을 나타낸다. 모든 유통증명서 내의 정책 OID는 증명서 종류에 따라 다르며 기술규격에서 저장한 값만을 사용하여야 한다.
- 유통증명서는 증명서 종류에 따라 일괄적으로 하나의 OID를 가진다.
- Qualifier 값으로는 UserNotice > ExplicitText > DisplyText 에 UTF8String 형식으로 나타내며 지정된 문장을 사용한다.
- 유통증명서 유형에 따라 아래의 표 143와 같은 정책 정보를 사용하여야 한다.
표 143
Figure PCTKR2011005027-appb-T000065
⑦ requestInfo, 증명서 요청 메시지 정보
- 본 필드는 null로 설정한다.
RequestInfo ::= CHOICE {
arcCertRequest ARCCertRequest,
null NULL }
⑧ target, 증명 대상
- 유통된 전체 전자문서의 해쉬 값을 지정한다. 본 필드는 반드시 distributionInfos 방식을 사용하여야 한다. opRecord 및 orgAndIssued, dataHash 필드에 대한 구조는 제3자 보관기관의 '증명서 포맷 및 운용절차 기술규격'을 참조한다.
- 유통되는 전자문서에 대한 정보는 DistributionInfos 필드에 포함된다.
TargetToCertify ::= CHOICE {
opRecord [0] EXPLICIT OperationRecord,
orgAndIssued [1] EXPLICIT OriginalAndIssuedDocumentInfo,
dataHash [2] EXPLICIT HashedDataInfo
distributionInfos [10] EXPLICIT DistributionInfos}
DistributionInfos ::= SEQUENCE OF DistributionInfo
DistributionInfo ::= SEQUENCE {
senderAdd GeneralNames,
receiverAdd GeneralNames,
dateOfSend GeneralizedTime,
dateOfReceive [0] EXPLICIT GeneralizedTime OPTIONAL,
dateOfReceiveConfirm [1] EXPLICIT GeneralizedTime OPTIONAL,
distributionId INTEGER,
numberOfFiles INTEGER,
distributedFileInfos DistributedFileInfos}
①-① senderAdd, 공인 전자주소
- 송신자의 공인 전자주소를 나타낸다.
①-② receiverAdd, 수신자 공인 전자주소
- 수신자의 공인 전자주소를 나타낸다.
①-③ dateOfSend, 송신 일시
- 송신자가 전자문서를 발송한 시점을 나타낸다.
- 송신증명서의 경우 송신자가 전자문서 유통허브에 송신 의뢰한 시각을 지정한다.
- 송신증명서는 본 필드만 포함하여야 하며 dateOfReceive 및 dateOfReceiveConfirm는 포함하지 않아야 한다.
①-④ dateOfReceive, 수신 일시
- 수신자가 전자문서를 수신한 시점을 나타낸다. 해당 시점은 증명서를 생성한 시점보다 같거나 이전이어야 한다. 수신 증명서 및 열람 증명서는 반드시 본 필드를 포함하여야 한다. 송신증명서는 본 필드를 포함하지 않아야 한다.
①-⑤ dateOfReceiveConfirm, 열람 일시
- 수신자가 전자문서를 수신하여 확인한 시점을 나타낸다. 해당 시점은 수신 일시보다 같거나 이후이어야 하며 증명서를 생성한 시점보다 같거나 이전이어야 한다. 열람 증명서는 반드시 본 필드를 포함하여야 한다. 송신 증명서 및 수신 증명서는 반드시 본 필드를 포함하지 않아야 한다.
①-⑥ distributionId, 유통식별값
- 전자문서의 유통 건에 대한 식별 값을 나타낸다. 본 필드의 생성을 위하여 20byte 난수를 생성하여 사용한다. 본 필드값은 전자문서 유통에 대하여 유통메시지에 부여되는 식별값을 의미한다.
①-⑦ numberOfFiles, 유통파일 개수
- 유통 시 하나 이상의 전자문서가 전달될 수 있으며, 본 필드는 한 번의 유통에 전달되는 파일의 개수를 나타낸다.
①-⑧ distributedFileInfos, 유통문서정보
- 유통 시 하나 이상의 전자문서가 전달될 수 있으며, 본 필드에는 전달되는 모든 문서에 대한 정보가 포함되어야 한다.
DistributedFileInfos ::= SEQUENCE OF DistributedFile
DistributedFile ::= SEQUENCE {
fileHashedData HashedDataInfo,
fileId [0] UTF8String OPTIONAL,
fileName [1] UTF8String OPTIONAL
}
①-⑧-① fileHashedData, 파일 해쉬 정보
- 본 필드는 유통되어 전달된 전자문서에 대한 해쉬 값을 나타낸다.
①-⑧-② fileId, 파일 식별값
- 유통되는 전자문서에 식별 값을 부여한 경우 해당 문서에 대한 식별 값을 지정한다. 파일 식별 값은 송신자가 생성하며 전자문서를 수신자에게 전달할 때 함께 전달되어야 한다. 수신자는 전달받은 파일 식별 값을 이용하여 본 필드에 적용하여야 한다.
- 송신자는 본 필드의 생성을 위하여 uuid 방식으로 생성하여야 한다.
- 본 필드는 선택적으로 사용될 수 있으나 fileName 필드가 사용되지 않는 경우에는 반드시 사용되어야 하며 field 필드의 사용을 권고한다.
①-⑧-③ fileName, 파일명
- 유통되는 전자문서에 대한 파일명을 나타낸다. 파일명은 송신자가 지정하며 전자문서를 수신자에게 전달할 때 함께 전달되어야 한다. 수신자는 전달받은 파일 식별 값을 이용하여 본 필드에 적용하여야 한다.
- 본 필드는 선택적으로 사용될 수 있으나 fileID 필드가 사용되지 않는 경우에는 반드시 사용되어야 한다.
상술한 바와 같은 유통증명서의 시각 정보관련 정합성 기준은 아래 표144와 같다.
표 144
Figure PCTKR2011005027-appb-T000066
시각정보 순서는 발송일시 < 수신 일시 ≤ 열람 일시 ≤ 증명서 발급일 < 증명서 효력 만기일이며, 유통증명서 검증 시에 시각 정보가 상기의 순서에 맞는지 확인해야 한다.
유통증명서의 검증은 증명서 구조 검증, 증명서 전자서명 검증, 증명서 주요 필드 확인, 증명서 시각 정보 정합성 검증을 포함한다.
증명서 구조 검증은 증명서가 ASN.1 정의된 바와 동일한 지 검증하는 과정이다.
증명서 전자서명 검증은 유통증명서에 적용된 전자서명을 검증하는 과정이다.
증명서 주요 필드 확인은 version 필드 값이 v2인지 확인하는 버전필드 확인, target 필드가 hashData 인지 확인하는 target 필드 확인, 전자서명에 사용된 인증서의 DN과 증명서 기본필드의 DN이 동일한지 검증하는 발급자 정보 검증, requestInfo 필드가 Null 인지 확인하는 requestInfo 필드 확인, distributionInfos 확장필드가 존재하는지 확인하고 critical이 TRUE인지 확인하는 확장필드 확인, numberOfFiles 필드의 값과 distributionInfos 확장필드 내 DistributedFile의 개수가 동일한 지 확인하는 파일 개수 확인, target 필드의 해쉬 값과 distributionInfos 확장필드의 해시 값이 동일한 지 확인하는 target 필드 해시 값 확인, 유통증명서 시각 정보의 정합성 검증 기준에 따라 검증하는 시각 정보 정합성 검증을 포함한다.
증명서 시각 정보 정합성 검증은 유통증명서 시각 정보의 정합성 검증 기준에 따라 검증한다.
한편, 유통증명은 전자문서의 유통과정에서 발생한 발신, 수신, 수신확인에 대한 사실에 대하여 신뢰성 있는 방식으로 증명하는 행위를 말한다. 유통증명은 별도의 응용프로그램에서 수행하며 유통증명서 뷰어 및 유통증명API에서 수행하지 않는다. 유통증명은 유통증명서 검증에 추가적으로 수행하고자 하는 경우 다음의 내용을 수행한다.
- 유통증명서 검증: 유통증명서의 검증을 수행한다.
- 유통증명서 정책 확인: 발신, 수신, 수신확인에 대한 유통증명서 정책 OID 및 Qualifier 값을 확인한다.
- 송신자 주소 확인: 전자문서를 발송한 송수신 개체의 주소가 정확한지 확인한다.
- 수신자 주소 확인: 전자문서를 수신한 송수신 개체의 주소가 정확한지 확인한다.
- 발송 일시 확인: 송신자가 전자문서를 발송한 시각이 정확한지 확인한다.
- 수신 일시 확인: 수신자가 전자문서를 수신한 시각이 정확한지 확인한다.
- 수신확인 일시 확인: 수신자가 전자문서를 수신확인한 시각이 정확한지 확인한다.
- 유통ID 확인: 유통 개별 건에 부여된 유통ID가 정확한지 확인한다. 송신자 및 수신자가 유통ID를 별도로 보관하여 관리하는 경우 이를 비교하여 관리할 수 있다.
- 유통 파일의 식별자 또는 파일명 확인: 유통되는 파일의 ID 또는 파일명이 정확한지 확인한다. 송신자 및 수신자가 파일ID 및 파일명을 별도로 보관하여 관리하는 경우 이를 비교하여 관리할 수 있다.
- 유통 파일의 해쉬 값 확인: 유통 대상이 되는 파일들의 각각의 해쉬 값과 확장필드의 DistributedFile 필드의 값이 동일한지 확인한다. 이때 사용하는 해쉬 알고리즘은 유통증명서 내에 지정된 것으로 수행하여 비교한다.
한편, 유통증명서 프로파일은 아래 표 145과 같으며, 고려할 사항은 전자서명은 RSA 2048bit 및 SHA256 알고리즘을 적용한다는 것과, signedData 구조에서 인증서는 반드시 포함되어야 한다는 것과, signerInfos 필드에는 하나의 signerInfo 만 포함된다는 것이다.
표 145
Figure PCTKR2011005027-appb-T000067
상술한 바와 같은 유통증명서를 제3자 보관기관과 연계하는 방안은 유통증명서를 발급함과 동시에 제3자 보관기관에 저장(보관) 의뢰함으로써 발급된 유통증명서의 신뢰성을 보장받는 것이다.
제3자 보관기관 사업자의 유통 메시징서버 시스템의 경우에 유통증명서 보관 프로세스는 도 98과 같으며, 유통 메시징서버 시스템에서 발급한 유통증명서를 직접 제3자 보관기관 연계모듈을 통해 제3자 보관기관 내부에 보관요청을 하며, 제3자 보관기관 연계모듈은 유통증명서 보관요청모듈과 제3자 보관기관 연계인터페이스 클라이언트 모듈로 구성되며, 기존의 제3자 보관기관 연계인터페이스 규격에 따라 제3자 보관기관에 보관된다.
일반 송수신 개체의 유통 메시징서버 시스템의 경우에 유통증명서 보관 프로세스는 도 99와 같으며, 발급된 유통증명서 보관을 위해 제3자 보관기관 사업자들에게 요청을 하기 위해 제3자 보관기관 사업자의 유통 메시징서버 시스템에 요청메시지를 전달하며, 외부에서 유통증명서 보관요청을 받은 제3자 보관기관 사업자 유통 메시징서버 시스템은 제3자 보관기관 연계모듈을 통해 제3자 보관기관 내부에 보관 요청을 하며 제3자 보관기관 연계모듈은 기존의 제3자 보관기관 연계 인터페이스 규격에 따라 제3자 보관기관에 보관 요청을 한다.
송수신 개체가 유통증명서를 제3자 보관기관에 보관하는 상세 처리는 도 100에 도시한 바와 같은 절차로 이루어지며, 상세한 설명은 다음과 같다.
○ 유통증명서 등록자
- 제3자 보관기관에 유통증명서를 보관할 때 제3자 보관기관 사업자와 송수신 개체 간 계약에 의해 보관대행자를 지정할 수 있으며, 제3자 보관기관 사업자는 보관대행자가 등록자가 되어 보관대행자의 공인인증서를 기반으로 유통증명서를 보관하게 됨
○ 제3자 보관기관 보관요청 프로세스 유형
- 제3자 보관기관 사업자는 동기식 또는 비동기식 처리 중 하나이상 제공하여야 하며 유통 메시징서버는 연계하고자 하는 제3자 보관기관 사업자가 제공하는 방식에 따라 연계됨
- Case 1: 동기식 처리 프로세스 (송신자가 유통증명서 보관요청 시 제3자 보관기관에 등록이 완료된 후 등록증명서가 발급되는 모든 프로세스가 동기식으로 이루어짐으로써 송신자의 유통 메시징서버는 동기식 응답 메시지로 등록증명서를 전달 받음. 요청에 대한 응답 메시지가 최종적인 제3자 보관기관 등록결과이므로 보관요청에 대한 오류 발생 시 재처리는 송신자의 유통 메시징서버가 수행하여야 함)
- Case 2: 비동기식 처리 프로세스 (송신자가 제3자 보관기관 유통 메시징서버에 유통증명서 보관요청을 하면, 제3자 보관기관 유통 메시징서버가 먼저 요청메시지의 유효성을 검증한 후, 보관요청을 접수함. 제3자 보관기관 사업자는 보관요청 메시지에 따라 제3자 보관기관에 등록하고 발급 받은 등록증명서를 최초 보관요청자인 송신자의 유통 메시징서버에 전달하여야 함. 접수한 보관요청에 대해서 제3자 보관기관에 등록하는 것은 제3자 보관기관 사업자의 책임이므로, 보관오류 발생 시 재처리 역시 제3자 보관기관 사업자가 수행하여야 함)
[유통 프로토콜]
이하에서는, 상술한 바와 같은 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템 및 방법에 적용되는 유통 프로토콜에 대하여 상세히 설명하도록 한다.
본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템 및 방법에 적용되는 유통 프로토콜을 설명함에 있어서, "① 메시지 패키징", "② 메시지 봉투 구성", "③ HTTP 바인딩"에 대하여 차례로 설명하도록 한다.
① 메시지 패키징
유통 프로토콜의 메시지 구조는 ebMS V2.0 규격을 준용하며, 두 개의 논리적인 MIME 파트를 가진다.
첫 번째 MIME 파트는 SOAP 메시지를 포함하며 헤더 컨테이너라고 불리고, SOAP 메시지는 Header와 Body로 구성되며, 두 번째 MIME 파트는 0개 이상의 추가적인 MIME 파트로서 페이로드 컨테이너라고 불리는데 어플리케이션 레벨의 첨부 문서를 포함한다.
이와 같은 유통 메시지의 기본적인 구조는 도 101과 같으며, Simple Object Access Protocol(SOAP) 1.1 및, SOAP Messages with Attachment와 같은 표준 규격을 준수한다.
유통 메시지 패키지의 모든 MIME Header 요소들은 SOAP Messages with Attachments 규격을 준수한다. 추가로, 메시지 패키지 내의 Content-Type MIME Header는 반드시 SOAP 메시지 문서를 포함하는 MIME Body 부분의 MIME 미디어 유형과 동일한 type 속성을 가진다. SOAP 규격에 따르면 SOAP 메시지의 MIME 미디어 유형은“text/xml” 값을 가져야 한다고 되어 있다.
루트 부분은 [RFC2045]에 준하는 구조를 가지는 Content-ID MIME 헤더를 포함하고 Multipart/Related 미디어 유형에 대한 필수적인 파라미터에 추가하여, start 파라미터([RFC2387]에서는 선택사항)가 항상 존재해야 한다. multipart/related 메시지 패키지의 MIME 헤더 예제는 다음 표 146과 같다.
표 146
Figure PCTKR2011005027-appb-T000068
이하에서 본 발명에 따른 유통 메시지에 대하여 설명함에 있어서 메시지 패키지의 루트 Body 부분을 Header(헤더) 컨테이너라고 정의한다. Header 컨테이너는 MIME 몸체 부분으로 SOAP Messages with Attachment명세에서 정의한 것과 같이 하나의 SOAP 메시지를 포함한다.
헤더 컨테이너의 MIME Content-Type header는 SOAP 규격에 따라 “text/xml” 값을 가져야 한다. Content-Type 헤더는 “charset” 속성을 포함할 수도 있으며, 예제는 다음 표 147과 같다.
표 147
Figure PCTKR2011005027-appb-T000069
MIME charset 속성은 SOAP 메시지를 생성하는데 사용되는 문자 군을 식별하기 위해 사용된다. 이 속성의 의미론은 [XMLMedia]에 명시되어 있는 text/xml 의 “charset parameter / encoding consideration”에 설명되어 있다. 유효한 값의 목록은 http://www.iana.org/에서 찾을 수 있다.
만약에 두 가지가 모두 포함되어 있다면, MIME charset 속성은 SOAP 메시지의 인코딩 선언부와 동일해야 한다. 만약에 제공되어 있다면 MIME charset 속성은 SOAP 메시지를 생성할 때 인코딩과 상충되는 값을 포함하고 있어서는 안 된다.
이 문서를 인코딩할 때는 최대한의 호환성을 위하여 반드시 [UTF-8]을 사용하여야 한다. text/xml[XMLMedia]에서 도출해 온 미디어 유형들을 위해 정의된 처리 규칙 때문에 이 MIME 속성은 기본 값을 가지지 않는다.
헤더 컨테이너의 예제는 아래 표 148와 같다.
표 148
Figure PCTKR2011005027-appb-T000070
SOAP Messages with Attachments 규격에 따라 메시지 패키지 내에는 0개 이상의 페이로드 컨테이너가 포함될 수 있다. 만약 메시지 패키지가 어플리케이션 페이로드를 포함하고 있다면, 이는 반드시 페이로드 컨테이너에 포함되어 있어야 한다.
만약, 메시지 패키지가 어플리케이션 페이로드를 포함하고 있지 않다면 페이로드 컨테이너를 표시하지 말아야 한다. 각 페이로드 컨테이너의 내용물은 SOAP Body 내의 ebXML 메시지 Manifest 요소에 의해 식별되어야만 한다.
ebXML 메시지 서비스 명세는 어플리케이션 페이로드의 구조와 내용물에 대하여 어떠한 규정도 어떤 식의 제약도 정해놓고 있지 않다. 페이로드는 simple-plain-text 객체 또는 복잡하게 중첩된 여러 부분의 객체도 될 수 있다. 페이로드 객체의 구조와 구성에 대한 명세는 ebXML 메시지 서비스를 사용하는 업무 프로세스나 정보 교환을 어떻게 정의하는지에 따라 달라질 수 있다. 페이로드 컨테이너의 예제는 다음 표 149와 같다.
표 149
Figure PCTKR2011005027-appb-T000071
본 발명에 따른 유통 메시지의 모든 MIME 부분은 [RFC2045] 규격에 준하는 추가적인 MIME 헤더들을 포함할 수 있다. 구현 시에는 이 발명에서 정의되지 않은 MIME 헤더들을 무시할 수도 있으며, 식별할 수 없는 MIME 헤더들은 반드시 무시해야 한다. 예를 들어, 구현 시에 content-length를 메시지에 포함할 수 있지만, content-length가 나타나 있는 메시지의 수령자는 이를 무시할 수도 있다.
② 메시지 봉투 구성
SOAP 규격에 준하여 모든 확장 요소 내용은 유효한 네임스페이스로 한정되어야 한다. 본 발명에서 정의된 모든 ebXML SOAP 확장 요소 내용은 ebXML SOAP Envelope 확장 네임스페이스로 한정되어야 한다. 네임스페이스 선언부들은 SOAP Envelope, Header 또는 Body 요소들에 포함되어 있거나, 각 SOAP 확장 요소들에 직접 포함되어 있을 수 있다.
SOAP Envelope은 SOAP 메시지의 Root 항목으로 SOAP 메시지 내의 각종 Namespace 들을 선언한다. 선언해야 할 Namespace는 다음 표 150과 같다.
표 150
Figure PCTKR2011005027-appb-T000072
메시지 봉투의 스키마 구조는 도 102와 같으며, 메시지 봉투의 예제는 아래 표 151와 같다.
표 151
Figure PCTKR2011005027-appb-T000073
SOAP Envelope 요소의 자식 요소인 SOAP Header 요소와 SOAP Body 요소에 대하여 차례로 상세히 설명하면 다음과 같다.
SOAP Header 요소는 SOAP Envelope 요소의 첫 번째 자식 요소이며, MessageHeader, SyncReply, Signature, ErrorList와 같은 확장 요소를 포함한다.
MessageHeader는 메시지의 라우팅 정보(To/From, 등)와 메시지에 관한 다른 문맥정보를 포함한 필수 요소이며, SyncReply는 다음 SOAP 노드로 가는 필수 전송 상태를 가리키는 요소이고, Signature는 메시지와 연관된 데이터를 서명하는 [XMLDSIG]에 준하는 전자서명을 표시하는 요소이며, ErrorList는 이전의 메시지를 대상으로 보고되어진 오류의 목록을 담은 요소이며 이전의 메시지에 대한 오류를 보고할 때에만 사용되어지는데, 이와 같은 MessageHeader의 요소들 각각에 대하여 상세히 설명하면 다음과 같다.
MessageHeader 요소는 모든 ebXML 메시지에 표현되어야 하는 필수 요소로서 반드시 SOAP Header 요소의 자식 요소로 표현되어야 한다. MessageHeader 요소는 다음과 같은 하위 요소들로 구성된 복합 요소이며, MessageHeader의 element 구조는 아래 표 152과 같으며, MessageHeader의 스키마 구조는 도 103과 같다.
표 152
Figure PCTKR2011005027-appb-T000074
SyncReply 요소는 동기식 송신을 의미하는 것으로서id 속성,version 속성, SOAP actor 속성(반드시 "http://schemas.xmlsoap.org/soap/actor/next" 값을 가져야 함), SOAP mustUnderstand 속성값을 가지며, SyncReply 요소의 예제는 다음 표153와 같다.
표 153
Figure PCTKR2011005027-appb-T000075
Signature 요소는 SOAP Header의 자식요소로 반드시 존재해야 하는데, 이는 유통 메시지는 위에서 언급한 위험 요소에 대응하기 위하여 반드시 전자적으로 서명되어야 하기 때문이다.
[XMLDSIG] 규격에 따라 전자서명을 수행하는 과정은 다음과 같다.
먼저, SOAP Envelope에 SignatureMethod, CanonicalizationMethod, Reference 요소를 가진 SignedInfo 요소와 필수 페이로드 객체를 [XMLDSIG]에 규정된 대로 생성한다.
다음으로, 정규화 한 뒤 [XMLDSIG]에 지정된 대로 SignedInfo에 지정된 알고리즘을 기준으로 SignedInfo의 SignatureValue를 산출한다.
다음으로, [XMLDSIG]에 지정된 대로 SignedInfo, KeyInfo(권고사항), SignatureValue 요소를 포함하는 Signature 요소를 생성한다.
다음으로, SOAP Header의 Signature 요소를 SOAP Header 요소에 포함한다.
상술한 바와 같은 전자서명 시에 사용되는 알고리즘 정보는 다음과 같다. 알고리즘은 W3C "XML-Signature Syntax and Processing" (RFC3275)의 알고리즘 부분(6.0 Algorithms)을 기본적으로 따른다. 또한, 국내 고유 알고리즘을 지원하기 위해 TTAS.IF-RFC3075 "확장성 생성 언어 전자서명 구문과 처리 (XML-Signature Syntax and Processing)" (한국정보통신기술협회, 2004년)에서 정의된 알고리즘을 이용한다.
본 발명에 따른 유통 프로토콜에서 이용하는 알고리즘 목록은 전자서명 NameSpace, 해쉬 (Digest), 전자서명(Signature), 정규화(Canonicalization), 변환(Transform)을 포함한다. 메시지 송수신 시 전자서명의 생성 및 검증 과정에서의 모호성을 최소화하기 위해서 다음 목록 이외의 알고리즘은 사용하지 않는 것이 바람직하다.
전자서명의 Namespace의 예제는 다음 표 154와 같다.
표 154
Figure PCTKR2011005027-appb-T000076
데이터를 축약하는데 이용하는 알고리즘으로 SHA1과 SHA256을 이용할 수 있으며, 예제는 다음 표 155과 같다. 단, HA1은 '공인인증서 암호체계 고도화'가 완전히 적용되는 시점인 2012년부터는 사용이 제한된다.
표 155
Figure PCTKR2011005027-appb-T000077
메시지 전자서명 시 사용되는 알고리즘은 RSAwithSHA1, RSAwithSHA256로서, 예제는 다음 표 156과 같다. 단, RSAwithSHA1을 이용하는 경우는 '공인인증서 암호체계 고도화'가 완전히 적용되는 시점인 2012년 부터는 사용이 제한된다.
표 156
Figure PCTKR2011005027-appb-T000078
논리적으로 동일한 문서에 대해 물리적으로 여러 가지 표현이 가능 방식한 XML의 특성으로 인해 같은 문서에 대해 전자서명 값이 다르게 나올 수 있으므로, 이러한 현상을 방지하기 위해 반드시 정규화(Canonicalization) 과정을 거쳐야 하며, 예제는 다음 표 157과 같다. 정규화는 주석 없는 정규 XML(Canonical XML, omits comments)을 사용한다.
표 157
Figure PCTKR2011005027-appb-T000079
전체 XML 데이터 중에서 실제 서명 대상이 되는 데이터를 가공하고 선택하는 과정을 거치는 알고리즘으로 다양한 변환 알고리즘이 존재하나 그 중에서 3가지만을 이용하도록 한다. 첫 번째는 전자서명이 서명 대상 내에 포함되는 형식을 따르므로 Enveloped Signature 변환이고, 두 번째는 상기 설명한 정규화(Canonicalization), 그리고 세 번째는 서명 대상 정보를 선택하는 XPath 필터링(XPath Filtering)이이며, 예제는 다음 표 158와 같다.
표 158
Figure PCTKR2011005027-appb-T000080
전자서명 구문의 구조는 도 104와 같으며, 상술한 방식대로 전자서명이 수행된 메시지 예제는 다음 표 159와 같다.
표 159
Figure PCTKR2011005027-appb-T000081
Figure PCTKR2011005027-appb-I000009
Errorlist 요소는 메시지를 수신하여 처리 과정을 수행할 때 오류가 발생하는 경우에만 Header 하위에 위치한다. ErrorList 요소가 생성되는 경우에는 반드시 MessageHeader 요소 내에 RefToMessageId가 존재해야 하며 RefToMessageId는 오류가 발생한 메시지의 MessageId를 지칭해야 한다. ErrorList 요소는 id 속성, OAP mustUnderstand 속성, version 속성, highestSeverity 속성, 한 개 이상의 Error 요소와 같은 속성들을 가지며, ErrorList의 구조는 도 105와 같다. 이때, 보고될 오류가 없으면 ErrorList 요소는 존재해서는 안 된다.
highestSeverity 속성은 모든 Error 요소들의 가장 심각한 상태를 표시한다. 특히, 어떤 Error 요소가 severity를 Error 라고 설정되어 있으면, highestSeverity는 Error로 설정되어야 하며, 그렇지 않은 경우에는 highestSeverity를 Warning으로 설정해야 한다.
Error 요소는 id 속성, codeContext 속성, errorCode 속성, severity 속성, location 속성, Description 속성을 가진다.
id 속성은 문서 내에서 ErrorList 요소를 유일하게 식별하는 역할을 한다.
codeContext 속성은 errorCodes의 네임스페이스 또는 스키마를 나타낸다. 이는 반드시 URI이어야 한다. 이 속성의 기본값은 urn:oasis:names:tc:ebxml-msg:service:errors이다. 이 속성에 기본 값이 없으면, 그 명세의 구현은 errorCodes를 사용한다는 것을 가리킨다.
필수 속성인 errorCode 속성은 오류를 가지고 있는 메시지의 오류가 지닌 본질을 지시한다. errorCode 의 유효한 값들과 코드의 의미는 아래에서 설명하도록 한다.
필수 속성인 severity 속성은 오류의 심각성을 나타내는 값으로서, 유효한 값들은 Warning, Error가 있는데, Warning은 오류가 존재하지만 대화 중의 다른 메시지들은 정상적으로 생성되고 있다는 것을 가리키며, Error는 복구 불가능한 오류가 메시지에 존재하고 대화 중 더이상 다른 메시지들은 생성되지 않는다는 것을 가리킨다.
location 속성은 오류가 존재하는 메시지 부분을 가리킨다. 만약에 오류가 ebXML 요소 내에 존재하고 요소가 “well-formed”라면, location 속성의 내용은 [Xpointer]이어야 한다.
Description 속성의 내용은 xml:lang 속성에서 정의된 언어로 오류의 서술적인 설명을 제공한다. 보통, 이것은 XML 파서나 메시지를 검증하는 소프트웨어가 생성한 메시지가 된다. 이 의미는 이 내용은 Error 요소를 생성했던 소프트웨어의 판매자나 개발자에 의해 정의된다는 것을 의미한다.
ErrorList의 예제는 다음 표 160과 같다.
표 160
Figure PCTKR2011005027-appb-T000082
유통 프로토콜을 기반으로 메시지를 송수신하는 과정에서 오류가 발생하면 오류를 인지한 송수신 개체는 상대방에게 오류 내용을 보고해야 하며, 보고해야 할 오류는 메시지 구조 오류, 신뢰메시징 오류, 보안 오류를 포함한다.
본 발명에서 정의하는 유통 프로토콜보다 하위 레이어에 속하는 HTTP 및 Socket과 같은 데이터 통신 프로토콜과 관련된 오류들은 데이터 통신 프로토콜에서 지원하는 표준 메커니즘에 의해 발견되고 보고되어야 하며, 본 발명에서 정의하는 오류 보고 메커니즘을 사용하지 않는다.
오류코드는 오류 대상 및 유형 별로 구분되며, 자세한 내용은 다음 표 161과 같습니다.
표 161
Figure PCTKR2011005027-appb-T000083
한편, SOAP Body 요소는 SOAP Envelope 요소의 두 번째 자식 요소이며, Manifest와 같은 확장 요소를 포함하며, Manifest는 페이로드 컨테이너 또는 웹과 같이 다른 장소에 위치한 데이터를 가리키는 요소이다.
Manifest 요소는 한 개 이상의 Reference 요소들로 구성된 복합 요소이다. 각 Reference요소는 페이로드 컨테이너에 담긴 페이로드 문서(들)의 일부로 포함되거나 URL로 접근 가능한 원거리의 자원인 메시지에 관련된 데이터를 식별한다. SOAP Body에는 페이로드 데이터를 싣지 않는 것이 바람직하며, Manifest의 목적은 XML 메시지와 관련된 특정한 페이로드를 쉽게 직접적으로 접근할 수 있게 하는 것과, 파싱 작업 없이도 어플리케이션이 페이로드를 처리할 수 있는지 판단할 수 있도록 하는 것이다.
Manifest 요소는 다음과 같은 한 개의 id 속성, 한 개의 version 속성 및 한 개 이상의 Reference 요소로 구성되어 있다.
Reference 요소는 0개 이상의 Schema 요소 및 0개 이상의 Description 요소를 포함하는 하위 요소들로 구성된 복합 요소이다. 이때, 0개 이상의 Schema 요소는 부모 Reference 요소에서 식별된 인스턴스 문서를 정의하는 스키마(들)에 대한 정보이며, 0개 이상의 Description 요소: 부모 참조 요소에 의해 Reference된 페이로드 객체에 대한 설명이다.
Reference 요소는 그 자체가 [XLINK]의 단순 링크이다. XLINK 프로세서 또는 엔진의 사용이 필수적이지는 않지만 구현 요구 사항에 따라 유용할 수 있다. Reference 요소는 위에서 제공된 요소의 내용과 더불어 id, xlink-type, xlink:href, xlink:role와 같은 속성 내용을 포함하고 있으며, 이 외에 다른 유효 네임스페이스인 속성들이 존재할 수 있으며, 수신 MSH는 위에서 정의한 것 외에 외부의 네임스페이스 속성들은 무시할 수 있다. 이때, id는 Reference 요소에 대한 XML ID이며, xlink-type은 XLINK 단순 링크로 요소를 정의하며 "simple"이라는 고정된 값을 가지며, xlink:href는 참조된 페이로드 객체의 URI 값이며 [XLINK] 명세의 단순 링크에 준하는 것이어야 한다. 그리고, xlink:role는 페이로드 객체나 그의 목적을 설명하는 자원을 식별하는 것으로서, 존재한다면 [XLINK] 명세에 준하는 유효한 URI 값을 가져야 한다.
Schema 요소는 참조하는 항목이 그 것을 기술하는 스키마(들)를 가지고 있다면 (예, XML Schema, DTD, 또는 Database Schema), 그 Schema 요소는 Reference 요소의 자식 요소로 존재해야 한다. 이는 스키마와 버전을 식별하는 방법으로 사용되며, 부모 Reference 요소에 의해 식별되는 페이로드 객체를 정의한다. Schema 요소는 location 및 version과 같은 속성을 가지고 있다. 이때, location은 스키마의 필수 URI이며, version은 스키마의 버전 식별자이다.
xlink:href 속성이 content id(URI scheme "cid")인 URI를 포함하고 있으면 그 content-id를 가지는 MIME은 메시지의 페이로드 컨테이너에 표현되어 있거나, 그렇지 않으면 errorCode를 MimeProblem으로, severity를 Error로 하는 오류를 발신당사자에게 전달해야 한다. xml:href 속성이 content id(URI scheme "cid")인 URI를 포함하고 있지 않으면 URI는 해석되지 못하고, 구현에 따라 오류를 전달해야 할지 말아야 할지 결정해야 한다. 오류가 전달되어야 한다고 결정되면 errorCode를 MimeProblem으로, severity를 Error로 하는 오류를 발신당사자에게 전달해야 한다.
아래의 표 162은 전형적인 한 개의 페이로드 MIME Body 부분을 가지는 메시지의 Manifest를 나타낸다.
표 162
Figure PCTKR2011005027-appb-T000084
③ HTTP 바인딩
HTTP를 통해 메시지를 전송하는 방안에 있어서 HTTP 바인딩 예제는 다음 표163와 같다.
표 163
Figure PCTKR2011005027-appb-T000085
Figure PCTKR2011005027-appb-I000010
Figure PCTKR2011005027-appb-I000011
본 발명에 따른 유통 프로토콜에서 HTTP 레벨의 응답 코드를 반환하기 위해서 [RFC2616]에 정의된 HTTP 응답 코드를 이용해야 하며, 주요 응답 코드는 다음표 164와 같습니다.
표 164
Figure PCTKR2011005027-appb-T000086
[전자문서 서식 등록기]
이하에서는, 상술한 바와 같은 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템의 전자문서 서식 등록기와 관련하여 상세히 설명하도록 한다.
전자문서 서식 등록기는 전자문서유통에서 송수신 개체가 문서를 유통하기 위해 필요한 서식을 생성, 등록, 관리할 수 있는 시스템이다.
전자문서 서식 등록기는 서식생성기, 서식등록기, 서식관리기 및 표준연계모듈로 구성된다.
서식생성기는 PDF 변환모듈과 PDF Form Designer로 이루어지며, PDF 변환모듈은 일반 서식을 PDF로 변환하는 기능(예 : 표준 PDF-A로 생성)을 제공하며, PDF Form Designer는 입력가능한 Form PDF를 생성할 수 있는 기능을 제공하고 2차원바코드 및 복사방지마크등의 문서보안기능을 제공한다.
서식등록기는 사용자가 서식(예 : 아래 한글, MS-Word등의 일반 서식)을 등록할 수 있는 기능을 제공한다.
서식관리기는 서식 관리자가 서식을 등록, 관리할 수 있는 기능을 제공하며, 카테고리별 등록, 버전별 이력관리기능 제공하고, 서식별 열람기간, 열람횟수, 인쇄횟수제어 등 설정기능 제공한다.
표준연계모듈은 유통 클라이언트 어플리케이션과 연계할 수 있는 기능을 제공하며, 서식 리스트, 검색기능 제공하고, 파일 다운로드 기능을 제공한다.
본 발명에 따른 전자문서 서식 등록기의 서식 등록 프로세스는 도 106과 같다.
표준전자문서는 Form designer를 이용하여 FormPDF로 생성하며, 필수 요건은 아래 표 165와 같다.
표 165
Figure PCTKR2011005027-appb-T000087
표준전자문서의 구조는 문서 하단에 5㎝ 정도의 공간 확보가 필요하며 바코드 크기는 데이터량에 따라 가변적이며, 복사방지마크 크기는 3 〉1.3로 하며 위치는 서식 모양에 따라 적절한 위치로 배치하며, 일 예는 도 107과 같다.
표준연계모듈(표준인터페이스)은 유통 클라이언트 어플리케이션에서 사용자가 서식을 검색하고 다운로드하여 서식을 생성할 수 있도록 하며, Web UI(User Interface)로 제공하여 유통 클라이언트 어플리케이션에서 포함될 수 있도록 하고, 카테고리별 검색, 서식 목록, 파일 다운로드 등의 기능을 제공한다.
[전자문서 패키징]
이하에서는, 상술한 바와 같은 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템 및 방법에 적용되는 전자문서 패키징과 관련하여 상세히 설명하도록 한다.
전자문서 패키징은 전자문서유통에서 송수신 개체가 문서를 유통하기 위해 필요한 메시징 시스템 규격이다.
전자문서 패키징은 표준전자문서, 첨부문서로 구성되어있으며 표준전자문서에 대한 메타데이터로 구성되어있다. 표준전자문서는 PDF-A를 기반으로 생성되며 메타데이터는 문서보안기능 등의 정보로 구성되어 있다. 첨부문서는 PDF로 변환하지 않고 원본 그대로 패키징한다.
표준전자문서는 사용자의 공인인증서로 전자서명하며 패키징 후 전자문서 패키지를 전자서명하여 패키지에 포함한다.
도 108에는 전자문서 패키지 구조를 도시하였는데, 이와 같은 도 108을 참조하면 본 발명에 따른 전자문서 패키지 구조는 패키지 헤더, 메타 데이터, 표준전자문서, 첨부문서, 전자서명 데이터를 포함하며, 각각의 세부 구성 요소는 아래 표 27 내지 표 31과 같다.
패키지 헤더는 패키지 전체 구조정보를 포함하며, 메타데이터는 표준전자문서의 문서보안기능의 정보를 포함하고 문서 열람횟수, 인쇄횟수, 2차원 바코드 정보 등의 정보를 포함하며, 표준전자문서는 표준 PDF-A 형식으로 구성되고 PDF 파일내 이미지 영역에 2D 바코드 데이터를 포함하며 표준 PDF Signed Data 영역에 전자서명데이터 포함하고, 첨부문서는 표준전자문서가 아닌 비정형문서이므로 문서보안기능 적용대상에서 제외하며 개별적 전자서명은 제외하며, 전자서명 데이터는 패키징된 데이터를 사용자의 공인인증서를 사용하여 전자서명하여 패키징에 포함한다.
표 166
Figure PCTKR2011005027-appb-T000088
표 167
Figure PCTKR2011005027-appb-T000089
표 168
Figure PCTKR2011005027-appb-T000090
표 169
Figure PCTKR2011005027-appb-T000091
표 170
전자문서 패키징을 검증하는 방안으로는 ① 전자문서 패키징 전자서명 검증 방안, ② 표준전자문서 검증 방안, ③ 인쇄된 전자문서 검증 방안이 있으며, 각 방안에 대하여 설명하면 다음과 같다.
- 클라이언트 App 는 전자서명 패키징을 처리할 때 전자서명을 검증하며 검증을 성공하였을 경우에만 표준전자문서를 전자문서뷰어로 전달한다.
- 또한, 수동 전자서명 검증 기능을 지원하여 분쟁 발생 시 전자서명 검증을 할 수 있도록 한다.
② 표준전자문서 검증 방안
- 전자문서뷰어는 표준전자문서를 열람할 때 전자서명검증을 수행하고 성공하였을 경우에만 전자문서뷰어에서 파일을 열람할 수 있도록 한다.
③ 인쇄된 전자문서 검증 방안
- 별도 제공되는 검증 프로그램과 평판 스캐너를 이용하여 2차원 바코드내 전자서명 데이터 검증 및 원본문서 내용과 인쇄된 문서의 내용을 육안 비교한다.
한편, 복사방지마크는 전자문서를 최종으로 받는 사용자의 프린터 패턴에 따라 생성해야하므로, 패키징에는 포함되지 않는다.
[유통 클라이언트 어플리케이션]
이하에서는, 상술한 바와 같은 본 발명의 바람직한 실시예에 따른 전자문서 유통 시스템의 유통 클라이언트 어플리케이션과 관련하여 상세히 설명하도록 한다.
기업 또는 개인들이 공인전자주소를 바탕으로 문서(정보)를 송수신하기 위해서는 이를 지원하기 위한 사용자 인터페이스(User Interface, 이하 UI라 함)를 제공하는 어플리케이션이 필요하다. 유통 메시징서버 시스템이 메시지를 주고받기 위한 메시징엔진으로서 이메일과 비교했을 때 메일서버와 같은 역할을 한다면, 유통 클라이언트 어플리케이션(이하, APP라 함)은 사용자가 이 메일서버와 연계하여 이메일을 주고받기 위해 제공되는 메일 클라이언트와 같은 사용자용 어플리케이션의 역할을 한다.
도 109에는 유통 클라이언트 APP의 구조도를 도시하였으며, 이와 같은 도 109를 참조하면 유통 클라이언트 APP는 유통 메시징서버 시스템을 이용해서 문서를 교환하고자 하는 일반 사용자를 위한 UI환경의 어플리케이션으로서 기본적으로 "① 사용자 인증", "② 메시지 작성", "③ 메시지 목록조회 및 상세내용 열람 기능", "④ 유통 메시징서버 시스템 연계"로 구성된다. 클라이언트 APP는 이와 같은 기본기능 외에 추가적으로 메시지 송수신 및 어플리케이션 관리를 위한 "⑤ 기본정보와 환경정보 관리", "⑥ 메시지 폴더 관리", "⑦ 문서 서식 관리", "⑧ 문서 작성기" 등의 기능을 제공할 수 있으나, 이는 어플리케이션 개발자에 의해 선택적으로 제공되는 기능이다.
① 사용자 인증
- 유통 클라이언트 APP이 유통 메시징서버 시스템과 연계되기 전에 유통 메시징서버 시스템은 사용자 계정을 확인한 후 로그인 세션 정보를 받아야 한다.
- 유통 클라이언트 APP가 사용자 인증을 받기 위한 방법으로는 인증서(공인 또는 사설 모두 허용)를 기반으로 한 사용자 인증 또는 ID/PW를 기반으로 한 사용자 인증 등이 있다.
② 메시지 작성 기능
- 유통 클라이언트 APP는 신규 메시지를 작성할 수 있는 사용자 인터페이스를 제공하여야 하며, 작성된 문서를 유통 메시징서버 시스템과 연계하여 수신 상대방에게 전달하여야 한다.
- 메시지 작성 기능은 메시지 전송하기 위해 유통 메시징서버 시스템의 전송인터페이스를 호출할 때, 필요한 기본정보들 중 환경정보에 의해 기 설정된 값이 아닌 항목은 입력을 할 수 있도록 제공하여야 한다.
③ 메시지 목록조회 및 상세내용 열람 기능
- 유통 메시징서버 시스템은 메시지를 송신메시지, 수신메시지로 구분하여 관리를 합니다. 유통 클라이언트 APP는 로그인된 사용자 계정을 기반으로 유통 메시징서버 시스템과 연계하여, 사용자 계정에 해당하는 각 메시지의 목록을 조회하는 기능과 메시지의 상세내용을 보고자 할 때 첨부문서를 포함하여 메시지의 상세정보를 모두 열람할 수 있는 기능을 반드시 제공하여야 합니다.
④ 유통 메시징서버 시스템 연계
- 유통 클라이언트 APP의 가장 중요한 기능이 유통 메시징서버 시스템과 연계하여 메시지를 송수신하는 기능이다. 유통 클라이언트 APP는 유통 메시징서버 시스템이 제공하는 메시지 송신기능과 수신메시지 읽음 인터페이스를 통해서 로그인한 계정을 기반으로 메시지를 전송하고 수신한다.
⑤ 기본정보와 환경정보 관리
- 클라이언트 APP는 메시지 전송 시 기본적으로 필요한 환경정보를 관리하는 기능을 제공하여야 한다. 유통 클라이언트 APP는 독립적으로 존재하는 어플리케이션이 아니므로 반드시 유통 메시징서버 시스템과의 연계를 통해 유통 기반인프라에 참여가 가능하다. 따라서 기본적으로 유통 메시징서버 시스템과의 연계를 위해 필요한 유통 메시징서버 시스템 연계정보(유통 메시징서버 시스템 주소정보)를 기본적으로 설정하고 관리하여야 한다.
- 그 외에 문서 서식 등록기와의 연계를 위한 등록기 서버 정보 관리나, 유통 클라이언트 APP의 시스템 환경에 대한 부가정보들 관리는 어플리케이션의 개발범위에 따라 정의하여 제공하면 된다.
⑥ 메시지 폴더 관리
- 유통 메시징서버 시스템이 관리하는 메시지는 송신, 수신메시지를 기본으로 분류하여 관리하며, 송수신 메시지는 각각 처리 상태에 따라 상태정보를 관리한다. 각 메시지의 상태정보로, 송신메시지는 송신 전, 송신완료, 송신실패, 담당자 수신완료의 상태를, 수신메시지는 검증오류, 수신 확인 전, 수신확인, 열람확인의 상태를 관리하며, 유통 클라이언트 APP는 유통 메시징서버 시스템이 제공하는 기본 상태정보를 바탕으로 메시지 폴더를 관리하여 사용자에게 제공한다.
- 유통 클라이언트 APP는 송수신 폴더를 기준으로 송신과 수신 메시지를 구분하여 유통 메시징서버 시스템이 제공하는 상태정보에 따라 사용자에게 각 메시지의 상태를 알려주는 것을 기본으로 제공하여야 한다. 그러나, 그 외에 임시보관함, 휴지통과 같은 지운 메시지함을 제공하거나 사용자가 직접 폴더를 정의하고 관리할 수 있도록 하는 기능을 제공하는 것은 어플리케이션 개발자의 선택사항이므로 본 발명의 설명에서는 생략한다.
⑦ 문서 서식 관리 기능
- 유통 메시징서버 시스템은 전송하는 메시지에 첨부되는 문서의 양식을 제한하지 않으므로 송수신 대상 문서로는 일반 텍스트파일부터, 오피스 파일, XML 문서, 멀티미디어 파일 등 어떠한 종류의 파일도 모두 가능하다. 그러나, 사용자들이 유통 클라이언트 APP를 업무에 활용하도록 편의를 제공하기 위해 기본적인 문서에 대해서는 서식 기반으로 문서 작성을 지원하는 기능을 부가적으로 제공하는 것이 가능하다. 유통 클라이언트 APP는 문서 서식 등록기에서 제공하는 문서서식을 등록기의 표준 인터페이스를 통해 검색하여 다운로드한 후, 다운로드한 문서서식을 기반으로 문서를 작성하고 이를 메시지에 첨부하여 보낼 수 있는 기능을 제공할 수 있다.
- 유통 클라이언트 APP는 전자문서 유통허브에서 제공하는 문서 서식 등록기와 연계하여 해당 문서 서식 등록기와 연계하여 문서서식을 관리할 수도 있으며, 독자적으로 문서 서식 관리체계를 구축하고 이 체계와 연계하여 문서 서식을 관리하는 방법이 있다. 전자문서 유통허브에서 제공하는 문서 서식 등록기와 연계하여 서식을 검색하고 다운로드 하는 방법에 대한 상세한 내용은 상술한 [전자문서 서식 등록기]에 대한 설명을 참조한다.
⑧ 문서 작성기
- 문서 작성기는 문서 서식 관리 기능을 통해 유통 클라이언트 APP가 다운로드한 서식을 기반으로 사용자들이 문서를 작성할 수 있도록 지원하는 작성기이다. 문서작성기는 전자문서 유통허브가 제공하는 문서 서식 등록기를 이용하는 경우에는 상술한 [전자문서 서식 등록기]에 대한 설명을 참조하여 설계하면 되며, 자체적으로 문서 서식 관리체계를 구축한 경우에는 해당 서식 관리체계에 따라 문서 작성기를 설계하면 된다.
상기와 같은 유통 클라이언트 APP의 가장 기본이 되는 프로세스로는 "① 문서 전송 프로세스", "② 문서 수신 프로세스"가 있으며, 부가적 프로세스로는 "③ 전자문서 서식 다운로드 프로세스"가 있다. 문서 전송 및 문서 수신을 위해 유통 클라이언트 AP는 서버가 되는 유통 메시징서버 시스템과 연계되며, 표준문서양식 등록을 위해서는 전자문서 서식 등록기 서버와 연계가 된다.
① 문서 전송 프로세스
유통 클라이언트 APP가 연계된 유통 메시징서버 시스템을 통해 타 “송수신 개체”에게 전자문서를 전송하는 단계는 도 110과 같으며, 처리 절차는 아래와 같다.
먼저, 유통 클라이언트 APP를 통해 수신자에게 전송할 메시지를 생성. 이 때 메시지는 이미 송신자가 작성한 문서를 첨부하거나, 유통 클라이언트 APP가 제공하는 문서작성기를 통해 작성한 문서를 첨부하여 수신자를 지정한 후 메시지를 생성한다.
다음으로, 수신자 주소정보를 입력한 후, 유통 메시징서버 시스템의 전송 인터페이스를 호출함으로써 메시지 전송을 요청한다.
다음으로, 전송자의 유통 메시징서버 시스템은 전송 프로세스에 따라 수신자에게 메시지를 전송한 후, 수신자로부터 수신에 대한 응답메시지(수신증명서 또는 수신오류)를 수신한다.
다음으로, 전송자의 유통 메시징서버 시스템은 수신에 대한 응답메시지를 수신한 후 유통 클라이언트 APP에 전송에 대한 응답으로 전달한다.
여기서, 첫번째~네번째 단계는 필수 절차이며, 두번째~네번째의 단계는 반드시 동기식으로 이루어져야 한다.
다음으로, 전송자의 유통 메시징서버 시스템이 수신자로부터 수신담당자의 열람을 확인 하는 열람증명서를 포함한 메시지를 받으면, 전송 유통 메시징서버 시스템은 수신에 대한 응답메시지를 돌려주고 수신 메시지를 해당 사용자의 사서함에 보관한다.
다음으로, 최초 전송자의 유통 클라이언트 APP은 연계된 유통 메시징서버 시스템에 수신문서를 요청한다.
다음으로, 전송자의 유통 메시징서버 시스템은 사서함에 보관된 수신 문서목록을 수신문서를 요청한 사용자의 유통 클라이언트 APP에 전달한다.
여기서, 다섯번째~일곱번째의 단계는 선택적 사항으로 최초 메시지 전송 시에 수신담당자의 열람 확인을 요청한 경우에만 발생되는 선택적 절차이다.
② 문서 수신 프로세스
유통 클라이언트 APP가 타 "송수신 개체"로부터 전자문서를 수신하는 프로세스는 도 111과 같으며, 처리 절차는 다음과 같다.
먼저, 수신자의 유통 메시징서버 시스템은 메시지를 수신하면, 수신한 메시지에 대한 수신 응답메시지를 수신자에게 돌려주고, 수신 메시지를 해당 사용자의 사서함에 보관한다.
다음으로, 수신자의 유통 클라이언트 APP은 연계된 유통 메시징서버 시스템에 로그인을 한 후 수신문서를 요청한다.
다음으로, 수신자의 유통 메시징서버 시스템은 수신문서를 요청한 사용자의 사서함에 보관된 수신 문서목록을 전달한다.
여기서, 두번째~세번째 단계는 동기식이다.
다음으로, 수신자가 수신메시지의 목록에서 메시지에 대한 상세정보 보기를 요청하면, 유통 클라이언트 APP는 유통 메시징서버 시스템에 해당 메시지의 첨부문서를 포함한 상세정보를 전달한다.
다음으로, 최초 전송자가 수신 담당자의 열람확인을 요청한 경우, 수신자의 유통 메시징서버 시스템은 사용자가 수신문서에 대한 상세정보요청을 한 시점에 해당 메시지의 송신자에게 열람증명서를 포함한 메시지를 전송한다.
다음으로, 수신자의 유통 메시징서버 시스템은 다섯 번째 단계에서 전송된 담당자 열람확인 메시지(열람증명서)에 대한 수신 응답메시지를 수신한다.
③ 전자문서 서식 다운로드 프로세스
유통 클라이언트 APP가 전자문서 서식을 다운로드하는 프로세스는 도 112와 같으며, 처리 절차는 다음과 같다.
먼저, 유통 클라이언트 APP는 전자문서 서식 등록기 서버에 직접 연계하여 문서서식에 대한 검색을 요청한다. 이때, 전자문서 서식 등록기 서버가 제공하는 표준 연계인터페이스 기반으로 연계한다.
다음으로, 전자문서 서식 등록기 서버는 검색된 문서 서식에 대한 정보를 결과로 돌려 준다.
이때, 첫번째~두번째 단계는 동기식이다.
다음으로, 유통 클라이언트 APP는 검색된 서식 목록을 사용자에게 보여줌으로써 사용자가 서식을 선택할 수 있도록 한다.
다음으로, 유통 클라이언트 APP는 전자문서 서식 등록기 서버에 선택된 전자문서 서식에 대한 다운로드를 요청한다.
다음으로, 전자문서 서식 등록기 서버는 요청 받은 서식을 유통 클라이언트 APP에 되돌려 준다.
다음으로, 유통 클라이언트 APP는 다운로드 받은 전자문서 서식을 등록하여 문서 작성기에서 사용할 수 있도록 Plug-In한다.
상기와 같은 유통 클라이언트 APP를 위해 유통 메시징서버 시스템이 제공하는 인터페이스 유형으로는 사용자 인증(로그인), 로그아웃, 메시지 전송요청, 수신메시지 Get, 메시지 상세정보 요청, 메시지 삭제가 있다.
유통 클라이언트 APP와 유통 메시징서버 시스템의 연계 방안(①~⑤)에 대하여 설명하면 다음과 같다.
① 유통 메시징서버 시스템의 연계 프로토콜
유통 메시징서버 시스템이 유통 클라이언트 APP를 위해 제공하는 연계 인터페이스는 유통 메시징서버 시스템의 송수신 프로토콜과 동일한 프로토콜을 기반으로 한다. 다만, 유통 메시징서버 시스템들 간에 송수신하는 경우와 달리, 유통 클라이언트 APP와 유통 메시징서버 시스템은 도 113과 같이 단방향(One-Way) 동기식 통신만을 제공하며, 둘 간에는 메시지에 대한 전자서명 인증 또는 사용자 인증 방식을 사용한다.
전송메시지는 유통 메시징서버 시스템의 메시지 구조를 그대로 활용하되, 사용자 정보 및 요청과 응답메시지는 도 114와 같은 구조로 구성되며, 상세한 설명은 다음과 같다.
- SOAP Header : 유통 클라이언트 APP 및 유통 메시징서버 시스템이 업무 유형에 따라 송신자 또는 수신자가 되어 상술한 [유통 프로토콜]에 따라 구성되며, messageHeader 및 Signature 정보로 구성된다.
- SOAP Body : 상술한 [유통 프로토콜]에서 정의한 Manifest 요소 정보 및 사용자 로그인 정보가 들어간다.
- 전송문서 컨테이너 #1 : 메시지 전송 요청, 수신 메시지 Get, 메시지 상세정보 수신의 경우 본문 문서(Contents)가 들어간다.
- 전송문서 컨테이너 #2 : 메시지 전송 요청, 메시지 상세정보 수신의 경우 첨부 문서가 #2부터 순차적으로 들어간다.
SOAP Header의 구조는 아래 표171과 같으며, MessageHeader의 구조는 아래 표172와 같고, SOAP Body의 구조는 아래 표173과 같으며, 본문 메시지의 구조는 아래 표174와 같다.
표 171
Figure PCTKR2011005027-appb-T000093
표 172
Figure PCTKR2011005027-appb-T000094
Figure PCTKR2011005027-appb-I000012
표 173
Figure PCTKR2011005027-appb-T000095
표 174
Figure PCTKR2011005027-appb-T000096
② 메시지 전송요청
메시지 전송 시에 유통 클라이언트 APP가 유통 메시징서버 시스템에 전달해야 하는 기본정보는 다음과 같다. 전송 완료된 후 사서함에 보관된 송신문서는 아래 표 175와 같이 4단계의 상태정보를 가진다.
표 175
Figure PCTKR2011005027-appb-T000097
요청 메시지의 예제는 아래 표 176과 같다.
표 176
Figure PCTKR2011005027-appb-T000098
Figure PCTKR2011005027-appb-I000013
Figure PCTKR2011005027-appb-I000014
응답 메시지의 예제는 아래 표 177과 같다.
표 177
Figure PCTKR2011005027-appb-T000099
③ 수신메시지 Get
유통 클라이언트 APP가 유통 메시징서버 시스템과 연계하여 로그인 한 사용자 계정으로 수신메시지를 읽어오는 행위와 유통 메시징서버 시스템에서 메시지를 삭제하는 행위는 분리가 되어 있다. 메시지 수신의 각 프로세스에 따라 다음과 같은 2단계의 상태정보를 관리해야 한다.
- 수신사용자가 사서함의 수신 문서 목록을 열람했는지 여부
- 수신사용자가 수신문서에 대한 상세내용을 열람했는지 여부
요청 메시지의 예제는 아래 표 178과 같다.
표 178
Figure PCTKR2011005027-appb-T000100
Figure PCTKR2011005027-appb-I000015
응답 메시지의 예제는 아래 표 179와 같다.
표 179
Figure PCTKR2011005027-appb-T000101
Figure PCTKR2011005027-appb-I000016
Figure PCTKR2011005027-appb-I000017
④ 메시지 상세정보 요청
수신한 문서목록을 기반으로 사용자가 상세내용을 열람하고자 하는 경우에 유통 클라이언트 APP는 유통 메시징서버 시스템의 메시지 상세정보를 요청한다. 상세정보를 요청 받은 유통 메시징서버 시스템은 메시지의 상세 속성정보와 해당 메시지의 첨부문서 등 모둔 메시지 내용을 유통 클라이언트 APP에 응답메시지로 전달한다.
요청 메시지의 예제는 아래 표 180과 같다.
표 180
Figure PCTKR2011005027-appb-T000102
Figure PCTKR2011005027-appb-I000018
응답 메시지의 예제는 아래 표 181과 같다
표 181
Figure PCTKR2011005027-appb-T000103
Figure PCTKR2011005027-appb-I000019
Figure PCTKR2011005027-appb-I000020
Figure PCTKR2011005027-appb-I000021
⑤ 메시지 삭제
유통 클라이언트 APP는 사용자가 삭제요청을 하는 경우에 유통 메시징서버 시스템에 해당 문서에 대한 삭제요청을 전달하고 그 결과를 사용자에게 알려주어야 한다. 사용자의 삭제 시 휴지통 개념의 임시 삭제 기능 부여 여부는 실제 서버상에서의 행위가 아니라 유통 클라이언트 APP의 부가기능이므로 유통 클라이언트 APP 개발자가 제공여부를 결정할 수 있으나, 최종적으로 유통 메시징서버 시스템에 삭제 요청을 하는 기능은 반드시 제공되어야 한다.
요청 메시지의 예제는 아래 표 182와 같다.
표 182
Figure PCTKR2011005027-appb-T000104
Figure PCTKR2011005027-appb-I000022
응답 메시지의 예제는 아래 표 183과 같다.
표 183
Figure PCTKR2011005027-appb-T000105
Figure PCTKR2011005027-appb-I000023
[기록매체]
한편, 상술한 본 발명에 따른 전자문서 유통 방법은 컴퓨터에서 실행될 수 있는 프로그램으로 작성 가능하고, 컴퓨터로 읽을 수 있는 기록 매체를 이용하여 프로그램을 동작시키는 범용 디지털 컴퓨터에서 구현될 수 있다. 컴퓨터로 읽을 수 있는 기록 매체는 마그네틱 저장 매체(예 : ROM, 플로피 디스크, 하드 디스크, 자기 테이프 등), 광학적 판독 매체(예 : CD-ROM, DVD, 광데이터 저장 장치 등) 및 캐리어 웨이브(예를 들면, 인터넷을 통한 전송)와 같은 저장 매체를 포함한다.
이하, 상술한 바와 같은 본 발명에 있어서 주소디렉터리 서버와 관련하여 또다른 실시예에 대하여 설명하면 다음과 같다.
[주소 디렉터리 서버]
신뢰할 수 있는 전자문서유통에 참여하기 위해서 모든 사용자는 고유의 전자주소를 발급받아야 한다.
전자주소는 다음과 같은 구조로 표현된다.
전자주소: 내부 구분자 + 구분 기호 + 고유등록주소
이와 같은 전자주소의 일 예로서 "gdhong#nipa.kr" 이 있다.
상기 전자주소의 내부 구분자는 고유등록주소의 소유자가 내부적 처리의 편의를 위해 선택적으로 추가하는 정보이며, 필요에 따라 생략이 가능하다.
상기 전자주소의 구분 기호는 고유등록주소의 앞에 위치하거나, 내부 구분자와 고유등록주소의 사이에 존재하는 기호이며, 일 예로서 "#"이 가능하며, 필요에 따라 다른 기호를 사용할 수 있다.
상기 전자주소의 고유등록주소는 기업/기관/개인이 발급 요청한 고유의 ID 값이며, 구분 기호 뒤에 존재하는 고유등록주소 단위가 송수신에 대한 법적 책임 단위가 된다. 이와 같은 고유등록주소는 송수신 개체가 유통 메시징서버를 자체적으로 구축한 후에 발급받거나 또는 송수신 개체가 전자문서 3자 유통 대행 기관을 통해 발급받은 고유등록주소로서, 전자 주소의 필수 구성 요소이다.
상기 송수신 개체는 자신이 보유한 유통 메시징서버 시스템에 대한 실제 물리적 주소(IP Address)를 가지는데, 이러한 물리적 주소와 상기 전자주소는 연관 관계가 없으며, 물리적 주소와 전자주소는 1:N의 관계를 가진다. 하나의 전자주소가 여러 개의 물리적 주소를 갖는 경우는 존재하지 않는다.
전자주소에 대한 정보(전자 문서)의 법적 수신책임은 구분 기호 뒤에 존재하는 기업/기관/개인이 가져야 하며, 내부 구분자에 의한 배부는 기업/기관/개인이 편의를 위해 구분한 것이므로 자체적으로 책임을 져야 한다.
전자문서 유통 시스템 내에서 전자주소가 가지는 의미는 도 3에 도시한 전자문서 유통 시스템 참여자 관계도와 같이 표현될 수 있다.
이와 같이 내부 구분자와 고유등록주소를 가지는 전자주소에 대하여 한번 더 정리하면 다음과 같다.
① 내부 구분자
- 내부 구분자는 주소 디렉터리 서버와 관계없이 각 송수신 개체가 자체적으로 발급하고 관리한다.
- 내부 구분자는 송수신 개체 내에서는 고유한 값이어야 하며, 생략이 가능한 정보다.
- 내부 구분자에 대한 부여방식은 각 기업/기관/개인이 책임을 지는 것을 기본으로 하며, 내부 구분자에 의한 전자문서의 배부 역시 전자문서유통 기반인프라 체계 하에서 공식적인 의미를 갖지는 않는다
- 고유등록주소가 수신에 대한 책임을 질 수 있는 정부/공공/법인/기관/단체/개인이 3자 유통 가능한 송수신 개체에 계정을 개설하고 공식적으로 주소 디렉터리 서버에 등록하여 사용하는 개체라면, 내부 구분자는 기업의 업무편의를 위해 전자문서를 분배하기 위한 용도로 사용되며, 주소 디렉터리 서버에 등록하지 않고 기업내부의 정보로서만 사용한다.
② 고유등록주소
- 전자문서 유통 시스템에 참여하여 전자문서를 유통하고자 하는 정부/공공/법인/기관/단체/개인은 유통 메시징서버 시스템을 자체적으로 구축한 후에 송수신 개체로서 고유등록주소를 발급받거나, 3자 유통(유통 대행)기관을 통해 고유등록주소를 발급받아야 한다.
- 고유등록주소는 발급 시점에 주소디렉터리 서버에 고유등록주소의 유일성(uniqueness)을 확인함으로써 중복되어 발급되지 않도록 관리된다.
- 정부/법인/기관/단체/개인의 고유등록주소의 구성 방식은 공인전자주소 관리 총괄의 정책에 의해 결정된다.
상술한 바와 같은 전자주소는 기본적으로 2-level에 의해 관리가 된다. 공인전자주소의 최상단에는 주소 디렉터리 서버를 관리하는 공인전자주소 관리 총괄(예 : 정보통신산업진흥원)이 있으며, 공인전자주소 관리 총괄은 하위 송수신 개체에 대한 고유등록주소를 발급해주고 이를 관리한다. 공인전자주소 관리 총괄의 하위 송수신 개체 중에 3자 유통(유통 대행)이 가능한 송수신 개체는 3차 유통을 원하는 사용자에 대한 등록주소를 개설한 후에 이에 대한 주소정보를 주소 디렉터리 서버에 등록한다. 이때, 사용자 고유등록주소 값의 유일성(uniqueness)을 보장하기 위해 반드시 주소디렉터리 서버에 중복 여부를 확인하여야 한다.
전자주소 중 공식적인 사용자가 아니라 내부에서 업무 편의를 위해 발급하고 사용하는 내부 구분자는 주소 디렉터리 서버와 관계 없이 각 송수신 개체가 자체적으로 발급하고 관리한다.
전자 주소를 발급하는 체계는 도 4와 같으며, 도 4에 나타낸 각 구성 요소의 역할은 아래 표 184와 같다.
표 184
Figure PCTKR2011005027-appb-T000106
전자주소를 발급하는 프로세스는 도 5와 같으며, 사용자(기업)가 직접 주소 디렉터리 서버가 제공하는 화면에 접속하여 주소를 등록하거나 수정하는 방법과, 공인전자주소를 대행 발급해 주는 유통 메시징 서버 시스템(시스템이 제공하는 웹 사이트)을 통해 발급받는 방법이 있다.
유통에 참여하는 사용자는 상대방에게 메시지를 전송하기 전에 전자주소 정보를 바탕으로 물리적인 실 주소 정보를 반드시 알아야 하며, 부가적으로 첨부하는 문서를 암호화하기 위해서는 수신자의 공개키 정보도 획득하여야 한다.
전자문서 유통프로세스에서 전자주소의 물리적 주소를 획득하는 절차는 필수 단계로서, 송신자는 수신자의 주소정보를 기준으로 수신 상대방에 대한 물리적 주소정보 및 보안정보 획득을 위해 주소 디렉터리 서버에 질의를 던지게 된다. 이 물리적 주소를 기준으로 송신자가 수신자에게 전송문서를 전달하면 수신자의 유통 메시징서버 시스템은 이를 받아서 수신자주소정보를 기반으로 사용자 계정 또는 내부 구분자에 따라 수신문서를 내부적으로 분배하게 된다.
전자주소의 물리적 주소 및 보안정보 획득의 프로세스는 도 6과 같다. 전자문서 유통에서 공인전자주소를 기반으로 수신자에게 문서를 전송하기 위해서는, ① 유통 클라이언트 APP가 수신 상대방의 주소정보를 입력하는 시점에 주소 디렉터리 서버에 연계하여 필요정보를 획득한 후 검색된 실 물리주소정보를 바탕으로 유통 메시징서버에 전송요청을 하는 방법과, ② 유통 클라이언트 APP가 수신자에 대한 공인전자주소를 기반으로 유통 메시징서버에 전송요청을 하고, 유통 메시징서버가 전송 전에 주소 디렉터리 서버에 물리적 주소 및 보안정보를 획득한 후, 수신자에게 문서를 전송하는 방법이 있다. 이와 같은 두 방법에 대한 절차는 도 7에 도시한 바와 같다.
주소 디렉터리 서버는 유통 메시징서버 시스템이 주소 정보를 검색하거나 주소 발급을 대행할 수 있도록 원격서비스를 제공한다. 주소 디렉터리 서버가 제공하는 서비스는 주소검색 서비스, 주소 등록 서비스, 주소 변경 서비스가 있으며, 유통 프로토콜 규격을 기반으로 다음과 같은 서비스 인터페이스를 제공한다.
주소 검색 서비스는 주소 디렉터리 버서가 공인 전자주소에 해당하는 물리적 주소 정보(예 : IP 주소, Domain 주소)와 공개키 정보를 검색 요청자에게 되돌려주는 서비스로서, 일반적으로 송신자가 문서를 전송하기 전에 수신자의 실제 주소 정보와 암호화를 위한 보안 정보를 획득하기 위해 사용한다. 이때, 요청 메시지와 응답 메시지의 역할은 아래 표 185와 같다.
표 185
Figure PCTKR2011005027-appb-T000107
주소 등록 서비스는 주소 디렉터리 서버가 제공하는 UI를 통해서 뿐만 아니라 원격에서도 사용자의 공인 전자주소를 등록할 수 있도록 제공하는 서비스로서, 사용자 정보 및 공인 전자주소 정보를 요청 메시지로 받아서 주소 디렉터리 서버가 등록 처리한 후에 이에 대한 결과를 응답 메시지로 수신받는다. 주소 등록 서비스에 대한 요청 메시지는 반드시 요청자에 대한 전자서명 정보가 포함되어 전달되어야 하며, 주소 디렉터리 서버는 요청 메시지에 포함된 사용자 정보와 전자서명에 사용된 인증서정보가 동일한지를 검증하여야 한다. 이때, 요청 메시지와 응답 메시지의 역할은 아래 표 186과 같다.
표 186
Figure PCTKR2011005027-appb-T000108
주소 변경 서비스는 등록된 사용자에 대한 주소정보를 원격에서 직접 사용자가 변경할 수 있도록 하는 기능을 제공하는 원격 서비스로 변경하여야 할 정보를 포함하여 주소 디렉터리 서버에 변경요청 메시지를 전송하고 이에 대한 결과를 응답메시지로 수신받는다. 주소 변경서비스에 대한 요청 메시지는 반드시 요청자에 대한 전자서명정보가 포함되어 전달되어야 하며, 주소 디렉터리 서버는 요청 메시지에 포함된 사용자 정보와 전자서명에 사용된 인증서 정보가 동일한지를 검증하여야 한다. 이때, 요청 메시지의 응답 메시지의 역할은 아래 표 187과 같다.
표 187
Figure PCTKR2011005027-appb-T000109

Claims (20)

  1. 전자문서를 유통하는 시스템에 있어서,
    전자주소를 기반으로 메시지를 송수신하고 메시지 송수신에 대한 유통증명서를 발급 및 관리하는 유통 메시징서버를 통해 전자문서를 유통하는 송수신 개체;
    상기 송수신 개체의 전자주소를 등록/관리하며, 상기 송수신 개체 간의 전자문서 유통 경로를 설정하고, 상기 송수신 개체에게 전자문서의 표준서식을 제공하며, 송수신 개체 간의 전자문서 유통 과정에서 오류가 발생하였을 시에 메시지 전송을 대행하고 유통증명서를 발급하는 유통 허브; 및
    유통증명서를 전달받아 보관하며, 신뢰할 수 있는 제3자 보관기관;
    을 포함하는 것을 특징으로 하는 전자문서 유통 시스템.
  2. 제 1 항에 있어서, 상기 송수신 개체의 유통 메시징서버는,
    송수신한 메시지는 사용자별로 상태 정보를 포함하여 메시지함에 보관하고,
    메시지 송수신 이력을 편집 및 삭제가 불가능한 매체에 소정 기간 동안 보관하며,
    메시지 송수신에 대한 유통증명서를 발급하여 상기 제3자 보관기관에 보관을 의뢰하고,
    상기 유통허브의 주소 디렉터리 서버와의 연계를 통해 상기 송수신 개체에게 전자주소 등록 및 검색, 수정, 삭제를 포함하는 기능을 사용할 수 있도록 하며,
    소정 기간 이상 보관된 메시지들을 외부 저장장치에 이관하여 보관하는 것을 특징으로 하는 전자문서 유통 시스템.
  3. 제 1 항에 있어서, 상기 전자주소는,
    상기 송수신 개체가 상기 유통허브의 주소 디렉터리 서버를 통해 발급받은 이용자 식별기호;
    상기 송수신 개체가 필요한 경우에 자체적으로 부여하는 고유한 값이며, 해당 송수신 개체 내에서 고유한 값인 추가 식별기호;
    상기 이용자 식별기호와 추가 식별기호 사이에 위치하는 구분 기호;
    를 포함하는 것을 특징으로 하는 전자문서 유통 시스템.
  4. 제 3 항에 있어서, 전자문서 유통에 대한 주체는 고유등록주소를 발급받은 사용자인 것을 특징으로 하는 전자문서 유통 시스템.
  5. 제 3 항에 있어서, 상기 구분 기호는 '#'인 것을 특징으로 하는 전자문서 유통 시스템.
  6. 제 1 항에 있어서, 상기 유통허브는 전자문서 서식 등록기를 구비하며,
    상기 전자문서 서식 등록기는 전자문서 표준서식의 등록, 삭제 및 정보 수정을 포함하는 관리를 수행하며, 전자문서 표준서식을 문맥(context)에 따라 추가로 분류하고, 전자문서 표준서식이 사용될 수 있는 문맥(context)에 대한 등록, 수정을 포함하는 관리를 수행하는 것을 특징으로 하는 전자문서 유통 시스템.
  7. 제 6 항에 있어서, 상기 전자문서 서식 등록기는, 문서 양식을 관리하는 서버 엔진; 및 송수신 개체를 사용하는 사용자가 문서 양식을 검색하고 다운로드 받아서 사용할 수 있도록 하는 표준인터페이스; 를 포함하며,
    상기 송수신 개체는 송수신 개체를 사용하는 사용자가 유통 메시징서버를 통해 메시지를 송수신할 수 있도록 하는 사용자 인터페이스인 유통 클라이언트 어플리케이션을 추가로 구비하며,
    상기 유통 클라이언트 어플리케이션을 사용하는 사용자는 상기 전자문서 서식 등록기의 표준인터페이스를 통해 문서 서식을 검색하고 다운로드 받은 후에, 해당 문서 서식을 이용하여 전자문서를 생성하는 것을 특징으로 하는 전자문서 유통 시스템.
  8. 제 1 항에 있어서, 상기 유통허브는 송수신 개체 간의 전자문서 유통 과정에서 오류가 발생하였을 시에 메시지 전송을 대행하고 유통증명서를 발급하는 유통 중계서버를 구비하며,
    상기 유통 중계서버는 송수신 개체로부터 메시지 전송을 의뢰받으면 메시지 전송을 대행한 후에 메시지 전송을 의뢰한 송수신 개체에게 송신증명서를 발급하며, 의뢰받은 메시지 전송을 실패하였을 시에는 메시지 전송을 의뢰한 송수신 개체에게 오류 메시지를 전송하는 것을 특징으로 하는 전자문서 유통 시스템.
  9. 제 1 항에 있어서, 상기 유통허브는 외부 시스템과의 연계를 위한 외부 연계 게이트웨이 서버를 구비하며,
    상기 외부 연계 게이트웨이 서버는 전자주소를 기반으로 메시지를 송수신하는 유통 메시징서버를 구비하며, 연계된 외부 시스템과 전자문서 유통 시스템 간의 송수신 전자주소의 검증/변환 기능과, 연계된 외부 시스템과 전자문서 유통 시스템 간의 메시지 검증/변환 기능, 연계된 외부 시스템과 전자문서 유통 시스템 간의 전자문서에 적용된 보안의 검증/변환 기능, 연계된 외부 시스템과 전자문서 유통 시스템 간의 전자문서의 적합성을 검증하고 상호간 변환하는 기능을 제공하는 것을 특징으로 하는 전자문서 유통 시스템.
  10. 제 1 항에 있어서, 전자주소 등록대행기관이 주소 디렉터리서버에 전자주소를 등록 요청하여 응답을 받는데 이용되는 제1인터페이스; 전자주소 등록대행기관이 주소 디렉터리서버에 등록된 전자주소 정보에 대한 변경을 요청하여 응답을 받는데 이용되는 제2인터페이스; 및 전자주소 등록대행기관이 주소 디렉터리서버에 등록된 전자주소 정보의 삭제를 요청하여 응답을 받는 제3인터페이스; 가 구비되며,
    상기 전자주소 등록대행기관은 제1인터페이스를 통해 전자주소 신청자 정보 및 전자주소 정보를 요청메시지에 포함하여 전송한 후에 주소 디렉터리서버의 등록 처리 결과를 응답메시지로 수신받으며, 상기 전자주소 등록대행기관은 제2인터페이스를 통해 변경하고자 하는 사용자 정보 및 전자주소 정보를 요청메시지에 포함하여 전송한 후에 주소 디렉터리서버의 변경 처리 결과를 응답메시지로 수신받고, 상기 전자주소 등록대행기관은 제3인터페이스를 통해 삭제하고자 하는 사용자 정보 및 전자주소 정보를 요청메시지에 포함하여 전송한 후에 주소 디렉터리서버의 삭제 처리 결과를 응답 메시지로 수신받는 것을 특징으로 하는 전자문서 유통 시스템.
  11. 제 10 항에 있어서, 상기 전자주소 등록대행기관 또는 송수신 개체가 주소 디렉터리서버에 전자문서 수신자의 전자주소에 해당하는 물리적 주소 정보와 메시지 보안처리를 위한 공인인증서 정보를 요청하여 응답을 받는데 이용되는 제4인터페이스가 구비되며,
    전자주소 등록대행기관 또는 송수신개체의 유통 메시징서버는 전자문서 수신자의 전자주소 및 공인인증서 요청 여부를 요청메시지에 포함하여 전송한 후에 주소 디렉터리서버로부터 전자문서 수신자의 물리적 주소 정보 및 공인인증서 정보를 응답메시지로 수신받는 것을 특징으로 하는 전자문서 유통 시스템.
  12. 제 1 항에 있어서, 송수신 개체의 유통 메시징서버 또는 전자주소 등록대행기관의 유통 메시징서버는 메시지 전송, 유통증명서 전달, 유통증명서 보관요청 및 제3자 보관기관 보관결과 전달에 이용하는 제5인터페이스를 구비하는 것을 특징으로 하는 전자문서 유통 시스템.
  13. 제 1 항에 있어서, 송수신 개체 내의 사용자는 사용자 인터페이스인 유통 클라이언트 어플리케이션을 구비하고,
    송수신 개체의 유통 메시징서버는 전자문서 유통을 요청하는 사용자를 위한 유통 클라이언트 어플리케이션과 연계하여 사용자에게 문서 송수신 기능을 제공하는 제6인터페이스를 구비하며,
    상기 제6인터페이스는 메시지 전송요청, 메시지 목록 요청, 메시지 상세정보 요청, 스팸 메시지 신고 및 물리적 주소정보 검색 기능을 유통 클라이언트 사용자에게 제공하는 것을 특징으로 하는 전자문서 유통 시스템.
  14. 송수신 개체와 유통허브를 포함하는 전자문서 유통 시스템에서 전자문서를 유통하는 방법에 있어서,
    (a) 송신 개체는 수신 개체의 주소 정보에 대응되는 물리적 주소 정보를 유통허브를 통해 획득한 후에, 전자문서를 첨부한 메시지를 상기 물리적 주소로 전송하는 단계;
    (b) 메시지를 수신한 수신 개체는 수신 메시지 및 송신 개체에 대한 적합성 검증 결과에 따라 수신증명서 또는 오류증명서를 발급하여 송신 개체에게 전달하는 단계; 및
    (c) 수신 개체에게 메시지를 전송하였으나 실패한 송신 개체는 유통허브에 메시지 전송 대행을 의뢰하며, 메시지 전송 대행 의뢰를 받은 유통허브는 송신증명서를 발급하여 송신 개체에게 전달하고 수신 개체에게 메시지를 전송한 후에 상기 (b)단계를 수행하는 단계;
    를 포함하는 전자문서 유통 방법.
  15. 제 14 항에 있어서, 상기 (a)단계는,
    (a1) 송신 개체는 수신 개체의 전자주소 정보를 기준으로 수신 개체에 대한 물리적 주소 정보 및 보안 정보를 유통허브의 주소 디렉터리 서버에 질의하는 단계;
    (a2) 상기 주소 디렉터리 서버는 송신 개체의 질의를 수신하여 검증한 후에 전자주소가 화이트리스트에 있는 경우에 전자주소에 대응되는 물리적 주소 정보를 송신 개체에게 제공하는 단계; 및
    (a3) 상기 송신 개체는 전자문서를 첨부한 메시지를 상기 주소 디렉터리 서버로부터 제공받은 물리적 주소 정보를 기준으로 경로 설정을 하여 수신 개체에게 전송하는 단계;
    를 포함하는 것을 특징으로 하는 전자문서 유통 방법.
  16. 제 14 항에 있어서, 상기 (b)단계 이후에, 수신 증명서를 수신한 송신 개체는 수신 증명서의 적합성을 검증하고 검증된 정보를 수신증명서에 첨부한 후에 수신증명서를 자체 보관함과 동시에 제3자 보관기관에 보관 의뢰하는 것을 특징으로 하는 전자문서 유통 방법.
  17. 제 14 항에 있어서, 상기 (c)단계는,
    (c1) 수신 개체에게 메시지를 전송하였으나 실패한 송신 개체는 유통허브에 메시지 전송 대행을 의뢰하는 단계;
    (c2) 유통허브는 메시지 전송을 시작하되, 전송 실패 시에는 소정 시간 간격으로 재시도하며, 메시지 전송에 최종 실패한 경우에는 송신 개체에게 전송실패 메시지를 전달하는 단계;
    (c3) 메시지를 정상적으로 수신한 수신 개체는 수신증명서를 발급하여 유통허브에 전송하는 단계; 및
    (c4) 전자문서의 수신자가 전자문서를 열람한 경우에 수신 개체는 열람증명서를 발급하여 유통허브를 거치지 않고 송신 개체에 직접 전송하는 단계;
  18. 송신자 또는 수신자의 역할을 하는 송수신 개체와 전자문서 유통허브를 포함하는 전자문서 유통 시스템에서 전자문서를 유통하는 방법에 있어서,
    (a) 송신자는 수신자의 전자주소 정보를 획득하는 단계;
    (b) 송신자는 송신할 문서를 미리 정해진 메시지 구조체로 패키징한 메시지를 생성한 후에 수신자의 전자주소로 전송하는 단계;
    (c) 상기 (b)단계에서 전송 실패한 경우에, 송신자는 전자문서 유통허브에 메시지 전송을 의뢰하며, 메시지 전송 의뢰를 받은 전자문서 유통허브는 송신증명서를 발급하여 송신자에게 전달한 후에 메시지 전송을 대행하는 단계;
    (d) 수신자는 송신자 또는 전자문서 유통허브로부터 수신한 메시지를 검증하여 검증이 통과되면 수신한 메시지에서 문서를 추출하고 수신증명서를 발급하여 송신자에게 전달하는 단계;
    (e) 송신자는 전달받은 수신증명서를 신뢰할 수 있는 제3자 보관기관을 활용하여 보관하는 단계; 및
    (f) 수신자는 추출한 문서를 문서 담당자에게 전달하는 단계;
    를 포함하는 전자문서 유통 방법.
  19. 제 18 항에 있어서, 상기 (a)단계 전에는,
    (g) 송신자 및 수신자는 문서 유통을 위한 유통 메시징서버를 구축할지, 3자 유통이 가능한 유통 메시징서버를 보유한 송수신 개체를 이용할지에 대하여 결정하는 단계;
    (h) 상기 (g)단계에서 문서 유통을 위한 유통 메시징서버를 구축할 것이라고 결정한 경우에는, 송신자 및 수신자는 문서 유통을 위한 유통 메시징서버를 구축한 후에, 인증 기관을 통해 유통 메시징서버의 인증테스트를 수행하고, 전자문서 유통허브의 주소 디렉터리 서버에 접속한 후 송수신 개체로서의 전자주소를 발급받은 후에, 내부의 실 사용자를 위해 자체적으로 내부 구분자를 등록하고 관리하는 단계;
    (i) 상기 (g) 단계에서 3자 유통이 가능한 유통 메시징서버를 보유한 송수신 개체를 이용할 것이라고 결정한 경우에는, 송신자 및 수신자는 3자 유통이 가능한 유통메시징서버를 통해 전자주소 개설을 요청한 후에, 전자주소 정보를 전자문서 유통허브의 주소 디렉터리 서버에 등록하는 단계; 및
    (j) 상기 (h)단계 또는 (i)단계 후에 상기 송신자는 전자문서 유통허브의 전자문서 서식 등록기에서 문서 서식을 검색하고 다운로드 받아서 등록하는 단계;
    를 포함하며,
    상기 (b)단계 전에는, 송신할 문서를 선택하거나 또는 상기 (j)단계에서 등록한 문서 서식을 이용하여 송신할 문서를 작성하는 하는 (k)단계가 추가로 수행되는 것을 특징으로 하는 전자문서 유통 방법.
  20. 컴퓨터로 판독 가능한 기록매체에 있어서,
    제 14 항 내지 제 19 항 중 어느 한 항에 따른 방법을 구현하는 프로그램이 저장되는 기록매체.
PCT/KR2011/005027 2010-07-08 2011-07-08 전자문서 유통 시스템 및 전자문서 유통 방법 WO2012005546A2 (ko)

Priority Applications (5)

Application Number Priority Date Filing Date Title
JP2013518281A JP2013535858A (ja) 2010-07-08 2011-07-08 電子文書流通システムおよび電子文書流通方法
SG2013001870A SG187006A1 (en) 2010-07-08 2011-07-08 Electronic document distribution system and electronic document distribution method
US13/808,576 US9143358B2 (en) 2010-07-08 2011-07-08 Electronic document communication system and electronic document communication method
CN201180043451.8A CN103124981B (zh) 2010-07-08 2011-07-08 电子文档流通系统和电子文档流通方法
EP11803832.2A EP2602758B1 (en) 2010-07-08 2011-07-08 Electronic document distribution system

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
KR10-2010-0065985 2010-07-08
KR20100065985 2010-07-08
KR10-2010-0131936 2010-12-21
KR20100131936A KR20120005364A (ko) 2010-07-08 2010-12-21 전자 주소, 및 전자문서 유통 시스템
KR20100131935A KR20120005363A (ko) 2010-07-08 2010-12-21 전자문서 유통 시스템 및 전자문서 유통 방법
KR10-2010-0131935 2010-12-21
KR1020110067185A KR101266086B1 (ko) 2010-07-08 2011-07-07 전자문서 유통 시스템
KR10-2011-0067185 2011-07-07

Publications (2)

Publication Number Publication Date
WO2012005546A2 true WO2012005546A2 (ko) 2012-01-12
WO2012005546A3 WO2012005546A3 (ko) 2012-05-31

Family

ID=45611562

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/KR2011/005027 WO2012005546A2 (ko) 2010-07-08 2011-07-08 전자문서 유통 시스템 및 전자문서 유통 방법
PCT/KR2011/005039 WO2012005555A2 (ko) 2010-07-08 2011-07-08 전자문서 유통증명서 생성/발급 방법, 전자문서 유통증명서 검증 방법, 및 전자문서 유통시스템

Family Applications After (1)

Application Number Title Priority Date Filing Date
PCT/KR2011/005039 WO2012005555A2 (ko) 2010-07-08 2011-07-08 전자문서 유통증명서 생성/발급 방법, 전자문서 유통증명서 검증 방법, 및 전자문서 유통시스템

Country Status (7)

Country Link
US (2) US9143358B2 (ko)
EP (2) EP2592594B1 (ko)
JP (3) JP2013535858A (ko)
KR (4) KR20120005363A (ko)
CN (2) CN103124981B (ko)
SG (3) SG187005A1 (ko)
WO (2) WO2012005546A2 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110419040A (zh) * 2017-04-27 2019-11-05 惠普发展公司，有限责任合伙企业 用于履行服务操作的控制器
US12137174B2 (en) 2021-07-27 2024-11-05 Fujitsu Limited Computer-readable recording medium storing information processing program, information processing apparatus, and system

Families Citing this family (88)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8826375B2 (en) * 2008-04-14 2014-09-02 Lookwithus.Com Inc. Rich media collaboration system
US8083129B1 (en) * 2008-08-19 2011-12-27 United Services Automobile Association (Usaa) Systems and methods for electronic document delivery, execution, and return
KR20120005363A (ko) * 2010-07-08 2012-01-16 정보통신산업진흥원 전자문서 유통 시스템 및 전자문서 유통 방법
AU2011378110B2 (en) * 2011-09-30 2015-05-21 Ranganath C. ABEYWEERA Method, system and apparatus for a communications client program and an associated transfer server for onymous and secure communications
CN103067338B (zh) * 2011-10-20 2017-04-19 上海贝尔股份有限公司 第三方应用的集中式安全管理方法和系统及相应通信系统
CA2796540A1 (en) * 2011-11-28 2013-05-28 Pika Technologies Inc. Transparent bridge device
US9367560B1 (en) * 2011-12-14 2016-06-14 Unboundid, Corp. Method, system and apparatus for synchronizing changes in a directory service
EP2632097A1 (en) * 2012-02-21 2013-08-28 Lleidanetworks Serveis Telemàtics S.A. Method for certifying delivery of SMS/MMS data messages to mobile terminals
US9344275B2 (en) 2012-05-08 2016-05-17 Arm Technologies Israel Ltd. System, device, and method of secure entry and handling of passwords
US9736121B2 (en) * 2012-07-16 2017-08-15 Owl Cyber Defense Solutions, Llc File manifest filter for unidirectional transfer of files
KR101223674B1 (ko) * 2012-09-06 2013-01-22 토피도 주식회사 샵 메일 전송 기능을 갖는 이 메일 클라이언트 데몬 시스템 및 이를 이용한 샵 메일 전송 방법
US20140082095A1 (en) * 2012-09-17 2014-03-20 Helen Y. Balinsky Workflow monitoring
KR20140048415A (ko) * 2012-10-12 2014-04-24 삼성전자주식회사 단말기의 전자편지지 다운로드서비스 제공 장치 및 방법
US9357382B2 (en) * 2012-10-31 2016-05-31 Intellisist, Inc. Computer-implemented system and method for validating call connections
KR102065390B1 (ko) 2013-02-15 2020-01-13 엘지이노텍 주식회사 발광소자, 발광소자 패키지 및 라이트 유닛
US9306887B1 (en) * 2013-03-14 2016-04-05 Dana Brunetti Systems and methods for implementing email delivery
US8739243B1 (en) 2013-04-18 2014-05-27 Phantom Technologies, Inc. Selectively performing man in the middle decryption
US10776384B1 (en) 2013-04-30 2020-09-15 Ping Identity Corporation Method, server and system for criteria-based assured replication
US9021575B2 (en) 2013-05-08 2015-04-28 Iboss, Inc. Selectively performing man in the middle decryption
US9160718B2 (en) 2013-05-23 2015-10-13 Iboss, Inc. Selectively performing man in the middle decryption
US20140379584A1 (en) * 2013-06-25 2014-12-25 FraudFree Finance, LLC Anti-fraud financial transaction method
US9009461B2 (en) 2013-08-14 2015-04-14 Iboss, Inc. Selectively performing man in the middle decryption
KR101332607B1 (ko) * 2013-09-02 2013-11-25 서호진 공인전자주소 기반 전자문서유통체계에서 샵 메일의 전달 및 전달된 샵 메일의 유효성 검사 시스템 및 방법
US9710808B2 (en) * 2013-09-16 2017-07-18 Igor V. SLEPININ Direct digital cash system and method
US20150135338A1 (en) 2013-11-13 2015-05-14 Fenwal, Inc. Digital certificate with software enabling indicator
KR101425513B1 (ko) * 2014-02-12 2014-08-05 주식회사 티모넷 ＨＳＭ（Ｈａｒｄｗａｒｅ Ｓｅｃｕｒｉｔ Ｍｏｄｕｌｅ）과 인증 ＡＰＰＬＥＴ을 이용한 디바이스 인증 시스템
US9130996B1 (en) 2014-03-26 2015-09-08 Iboss, Inc. Network notifications
CN103997453B (zh) * 2014-05-13 2018-03-30 北京奇虎科技有限公司 一种与应用相关的信息处理的方法和装置
US9673998B2 (en) * 2014-05-15 2017-06-06 Futurewei Technologies, Inc. Differential cache for representational state transfer (REST) API
US9906367B2 (en) * 2014-08-05 2018-02-27 Sap Se End-to-end tamper protection in presence of cloud integration
CN105337950B (zh) 2014-08-14 2019-02-19 阿里巴巴集团控股有限公司 一种表单填充方法及相关终端
KR102295570B1 (ko) * 2014-11-07 2021-08-30 주식회사 엘지유플러스 클라우드 프린팅 환경에서의 워터마크를 이용한 출력물 관리 방법
KR102256642B1 (ko) * 2014-12-04 2021-05-27 삼성전자주식회사 메시지 송수신 장치 및 메시지 송수신 방법
US20160162991A1 (en) * 2014-12-04 2016-06-09 Hartford Fire Insurance Company System for accessing and certifying data in a client server environment
US10079833B2 (en) * 2015-03-30 2018-09-18 Konica Minolta Laboratory U.S.A., Inc. Digital rights management system with confirmation notification to document publisher during document protection and distribution
KR101709197B1 (ko) * 2015-05-21 2017-02-22 (주)데이터코리아 어플리케이션을 기반으로 채권잔액확인서를 송수신하는 방법 및 어플리케이션
US10175977B2 (en) * 2015-11-04 2019-01-08 International Business Machines Corporation User profile based code review
US10839378B1 (en) * 2016-01-12 2020-11-17 21, Inc. Systems and methods for performing device authentication operations using cryptocurrency transactions
US11212363B2 (en) 2016-02-08 2021-12-28 Microstrategy Incorporated Dossier interface and distribution
US10791109B2 (en) 2016-02-10 2020-09-29 Red Hat, Inc. Certificate based expiration of file system objects
US10068074B2 (en) * 2016-03-25 2018-09-04 Credly, Inc. Generation, management, and tracking of digital credentials
US9680801B1 (en) 2016-05-03 2017-06-13 Iboss, Inc. Selectively altering references within encrypted pages using man in the middle
US10291604B2 (en) 2016-06-03 2019-05-14 Docusign, Inc. Universal access to document transaction platform
US20180006823A1 (en) * 2016-07-01 2018-01-04 Qualcomm Incorporated Multi-hop secure content routing based on cryptographic partial blind signatures and embedded terms
USRE49964E1 (en) 2016-10-04 2024-05-07 Samsung Electronics Co., Ltd Method and apparatus for transmitting a mission critical data message in a communication system
CN106789585A (zh) * 2016-12-27 2017-05-31 沃通电子认证服务有限公司 可验证电子邮件发送时间的方法及装置
CN106685979B (zh) * 2017-01-09 2019-05-28 北京信息科技大学 基于STiP模型的安全终端标识及认证方法及系统
JP6536609B2 (ja) * 2017-03-17 2019-07-03 富士ゼロックス株式会社 管理装置及びドキュメント管理システム
US11126665B1 (en) 2017-04-18 2021-09-21 Microstrategy Incorporated Maintaining dashboard state
KR101976665B1 (ko) * 2017-04-25 2019-08-28 주식회사 포시에스 영상 출력 장치들을 활용한 전자문서 정보 처리 장치 및 그의 정보 처리 방법
US11544669B2 (en) * 2017-06-26 2023-01-03 Oracle Financial Services Software Limited Computing framework for compliance report generation
CN107241341B (zh) * 2017-06-29 2020-07-07 北京五八信息技术有限公司 访问控制方法及装置
US11487868B2 (en) * 2017-08-01 2022-11-01 Pc Matic, Inc. System, method, and apparatus for computer security
US20190087833A1 (en) 2017-09-15 2019-03-21 Pearson Education, Inc. Digital credential receiver performance model
KR101951270B1 (ko) * 2017-09-28 2019-02-22 주식회사 스마트솔루션 메신저 인증 서버를 이용한 문서 발송 시스템 및 그 방법
US10803104B2 (en) 2017-11-01 2020-10-13 Pearson Education, Inc. Digital credential field mapping
US10607291B2 (en) 2017-12-08 2020-03-31 Nasdaq Technology Ab Systems and methods for electronic continuous trading of variant inventories
US10810350B2 (en) * 2018-01-05 2020-10-20 Jpmorgan Chase Bank, N.A. System and method for aggregating legal orders
CN108540528B (zh) * 2018-03-07 2021-12-17 胡金钱 确认电子文书送达的方法及系统、计算机存储介质
CN108804238B (zh) * 2018-03-29 2022-03-04 中国工程物理研究院计算机应用研究所 一种基于远程过程调用的软总线通信方法
CN112260995B (zh) * 2018-03-31 2022-05-24 华为云计算技术有限公司 接入认证方法、装置及服务器
US10742613B2 (en) * 2018-04-25 2020-08-11 Sap Se Pluggable framework for AS4 adapter generation
RU2702505C1 (ru) * 2018-08-07 2019-10-08 Акционерное общество Инжиниринговая компания "АСЭ" (АО ИК "АСЭ") Система управления электронным документооборотом
CN108989055A (zh) * 2018-08-31 2018-12-11 密信技术(深圳)有限公司 兼容不同类型文件的签名和加密方法、装置及存储介质
CN109150516A (zh) * 2018-08-31 2019-01-04 密信技术(深圳)有限公司 浏览器文件的签名及/或加密方法、装置、浏览器及介质
KR102158299B1 (ko) * 2019-01-23 2020-09-21 소프트캠프 주식회사 영업비밀에 관한 네트워크 기반의 문서 보호시스템
US10645197B1 (en) * 2019-04-19 2020-05-05 Clario Tech Limited Method and a system for a secure link-up to a non-secure synchronous connection and a machine-readable carrier configured for performing the method
JP2021060915A (ja) * 2019-10-09 2021-04-15 富士通株式会社 本人確認プログラム、制御装置及び本人確認方法
JP7367443B2 (ja) * 2019-10-09 2023-10-24 富士通株式会社 本人確認プログラム、管理装置及び本人確認方法
CN113591439B (zh) * 2020-04-30 2023-07-11 抖音视界有限公司 一种信息交互方法、装置、电子设备及存储介质
EP4099646B1 (en) 2020-04-30 2025-07-16 Beijing Bytedance Network Technology Co., Ltd. Method and device for information exchange, electronic device, and storage medium
FR3110801A1 (fr) * 2020-05-25 2021-11-26 Orange Procédé de délégation de la livraison de contenus à un serveur cache
CN111651196B (zh) * 2020-06-24 2024-06-21 腾讯科技（深圳）有限公司 文档发布方法、装置及服务器
KR102337673B1 (ko) 2020-07-16 2021-12-09 (주)휴먼스케이프 데이터 열람 검증 시스템 및 그 방법
KR102337677B1 (ko) 2020-07-16 2021-12-09 (주)휴먼스케이프 디지털 검증 지문 삽입 시스템 및 그 방법
JP7502618B2 (ja) 2020-07-20 2024-06-19 富士通株式会社 通信プログラム、通信装置、及び通信方法
TWI759908B (zh) * 2020-10-15 2022-04-01 威聯通科技股份有限公司 產生授權允許名單的方法與利用其之資安系統
JP7526655B2 (ja) * 2020-12-10 2024-08-01 富士通株式会社 情報処理プログラム、情報処理方法、情報処理装置および情報処理システム
KR102261527B1 (ko) 2021-01-14 2021-06-08 성균관대학교산학협력단 인휠 모터를 장착한 차량의 토크 벡터링 제어 장치 및 방법
US11556696B2 (en) * 2021-03-15 2023-01-17 Avaya Management L.P. Systems and methods for processing and displaying messages in digital communications
CN113126936B (zh) * 2021-04-23 2022-04-12 深圳市爱商在线科技有限公司 一种适配多种文档类型的打印控件
KR102470713B1 (ko) * 2021-04-29 2022-11-25 (주)소프트제국 블록체인 did 기반 증명서 유통 서비스 제공 방법 및 장치
KR102599089B1 (ko) * 2021-10-06 2023-11-03 효성티앤에스 주식회사 전자문서 생성 방법 및 장치, 컴퓨터 판독 가능한 기록 매체 및 컴퓨터 프로그램
KR102498461B1 (ko) * 2022-04-25 2023-02-13 주식회사 디엠테크컨설팅 싱글사인온 제조정보 통합관리 시스템를 이용한 통합관리 방법
KR102479174B1 (ko) * 2022-07-05 2022-12-20 (주)링크허브 보안 전자 서명 관리 시스템 및 그 방법
KR102781390B1 (ko) * 2022-09-16 2025-03-14 주식회사 한글과컴퓨터 전자 문서에 대한 위변조 방지 처리를 수행할 수 있는 문서 폼 제공 서버 및 그 동작 방법
US20240114001A1 (en) * 2022-10-03 2024-04-04 Bank Of America Corporation System and method for server monitoring and problem resolution for electronic mail messages
KR102809674B1 (ko) * 2022-10-18 2025-05-21 주식회사 한글과컴퓨터 입력 필드의 셀 서식 정보를 기초로, 전자 문서에 대한 위변조 방지 처리를 수행할 수 있는 문서 폼 제공 서버 및 그 동작 방법

Family Cites Families (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2887806B2 (ja) 1989-08-18 1999-05-10 富士ゼロックス株式会社 ネットワークシステム及びメールゲートウエイ
JPH0535562A (ja) 1991-07-31 1993-02-12 Toshiba Corp 情報処理システムの文書管理装置
GB2287619A (en) 1994-03-03 1995-09-20 Ibm Security device for data communications networks
JPH07297822A (ja) 1994-04-21 1995-11-10 Hitachi Ltd メッセージ伝送システム
JPH08307448A (ja) * 1995-04-28 1996-11-22 Nippon Telegr & Teleph Corp <Ntt> 電子メールにおける受信通知方法およびその方法を適用した電子メール通信システム
JP3453459B2 (ja) 1995-06-19 2003-10-06 キヤノン株式会社 電子メールシステム及びその制御方法、並びに通信端末装置及びその制御方法
US6327656B2 (en) * 1996-07-03 2001-12-04 Timestamp.Com, Inc. Apparatus and method for electronic document certification and verification
US6584565B1 (en) * 1997-07-15 2003-06-24 Hewlett-Packard Development Company, L.P. Method and apparatus for long term verification of digital signatures
US8468089B1 (en) * 1998-09-21 2013-06-18 International Business Machines Corporation Method of improving security in electronic transactions
JP2000183951A (ja) 1998-12-18 2000-06-30 Pfu Ltd 暗号化システムおよび記録媒体
US7966372B1 (en) * 1999-07-28 2011-06-21 Rpost International Limited System and method for verifying delivery and integrity of electronic messages
WO2001010090A1 (en) * 1999-07-28 2001-02-08 Tomkow Terrance A System and method for verifying delivery and integrity of electronic messages
US6775771B1 (en) 1999-12-14 2004-08-10 International Business Machines Corporation Method and system for presentation and manipulation of PKCS authenticated-data objects
IL138408A0 (en) 2000-04-07 2001-10-31 Digitalsecu Co Ltd Apparatus for and method of storing log data in communication network
JP2002082880A (ja) 2000-06-28 2002-03-22 Oregadare Inc メッセージの送受信管理方法及びメッセージの送受信管理システム
US20020059525A1 (en) * 2000-11-10 2002-05-16 Estes Timothy A. Authenticating the contents of e-documents
US20090144382A1 (en) * 2001-01-09 2009-06-04 Benninghoff Iii Charles F Method for certifying and unifying delivery of electronic packages
US8179555B2 (en) * 2002-03-08 2012-05-15 Hewlett-Packard Development Company, L.P. Printing and finishing capability for customized document production system and method
US7707624B2 (en) * 2002-11-26 2010-04-27 Rpost International Limited System for, and method of, proving the transmission, receipt and content of a reply to an electronic message
JP4001047B2 (ja) * 2003-04-23 2007-10-31 村田機械株式会社 中継装置
JP2005108063A (ja) 2003-10-01 2005-04-21 Hitachi Ltd 暗号化データ変換装置を利用した電子自治体共用サーバ及び暗号化データ復号化装置を利用した電子自治体用端末
KR100579147B1 (ko) 2004-01-29 2006-05-12 (주)드림투리얼리티 전자문서파일의 위변조 검증 전자문서관리시스템 및 그를이용한 방법
KR101006322B1 (ko) * 2004-04-08 2011-01-06 인터내셔널 비지네스 머신즈 코포레이션 파일 처리 방법 및 파일 인증 방법 장치와 컴퓨터 판독가능한 매체 및 시스템
ATE342625T1 (de) 2004-08-31 2006-11-15 Opportunity Solutions As Vorrichtung zur behandlung von e-mails in einer mehrbenutzer-umgebung
KR100653512B1 (ko) 2005-09-03 2006-12-05 삼성에스디에스 주식회사 전자문서 관리 및 보관 시스템, 이 시스템에서 수행되는전자문서의 등록방법 및 이용방법
JP2007179145A (ja) 2005-12-27 2007-07-12 Brother Ind Ltd アドレス情報検索システム、およびアドレス情報検索プログラム
KR100816184B1 (ko) * 2006-08-10 2008-03-21 한국전자거래진흥원 전자문서의 불변경성과 사실증명을 수행하는전자문서보관소 시스템 및 그 시스템에서 수행되는전자문서 등록방법, 열람방법, 발급방법, 이관방법, 증명서발급방법
WO2008078366A1 (ja) * 2006-12-22 2008-07-03 Fujitsu Limited データ検証装置、データ検証方法およびデータ検証プログラム
US20080168536A1 (en) * 2007-01-10 2008-07-10 Rueckwald Mark C System and methods for reduction of unwanted electronic correspondence
CN101017544B (zh) * 2007-02-15 2010-12-01 江苏国盾科技实业有限责任公司 含电子印章数字证书的合体印章签署认证方法
WO2008120334A1 (ja) * 2007-03-28 2008-10-09 Fujitsu Limited 証明書検証方法及び証明書検証装置
KR100978906B1 (ko) * 2007-09-12 2010-08-31 정보통신산업진흥원 전자문서 관리 시스템 및 그 운용 방법, 상기 방법을구현하는 프로그램이 저장된 기록매체
KR100969313B1 (ko) * 2007-09-12 2010-07-09 정보통신산업진흥원 전자문서 증명서 발급 방법 및 이를 위한 전자문서 보관시스템, 상기 방법을 구현하는 프로그램이 저장된 기록매체
KR100932266B1 (ko) * 2007-10-12 2009-12-16 주식회사 하나은행 전자문서중계 서비스 제공 방법
US8739292B2 (en) * 2008-03-04 2014-05-27 Apple Inc. Trust exception management
US8732452B2 (en) * 2008-06-23 2014-05-20 Microsoft Corporation Secure message delivery using a trust broker
JP2010093354A (ja) * 2008-10-03 2010-04-22 Sanyo Electric Co Ltd 通信装置
US8255685B2 (en) * 2009-03-17 2012-08-28 Research In Motion Limited System and method for validating certificate issuance notification messages
JP5105291B2 (ja) * 2009-11-13 2012-12-26 セイコーインスツル株式会社 長期署名用サーバ、長期署名用端末、長期署名用端末プログラム
KR20120005363A (ko) * 2010-07-08 2012-01-16 정보통신산업진흥원 전자문서 유통 시스템 및 전자문서 유통 방법

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"XML-Signature Syntax and Processing", TELECOMMUNICATIONS TECHNOLOGY ASSOCIATION, 2004

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110419040A (zh) * 2017-04-27 2019-11-05 惠普发展公司，有限责任合伙企业 用于履行服务操作的控制器
US12137174B2 (en) 2021-07-27 2024-11-05 Fujitsu Limited Computer-readable recording medium storing information processing program, information processing apparatus, and system

Also Published As

Publication number Publication date
CN103080958A (zh) 2013-05-01
WO2012005546A3 (ko) 2012-05-31
CN103124981A (zh) 2013-05-29
EP2602758B1 (en) 2016-08-24
CN103080958B (zh) 2016-12-07
KR20120005392A (ko) 2012-01-16
US20130110919A1 (en) 2013-05-02
EP2592594B1 (en) 2016-08-17
KR20120005364A (ko) 2012-01-16
EP2592594A2 (en) 2013-05-15
KR20120005363A (ko) 2012-01-16
CN103124981B (zh) 2016-12-07
WO2012005555A2 (ko) 2012-01-12
US9143358B2 (en) 2015-09-22
JP2013535859A (ja) 2013-09-12
WO2012005555A3 (ko) 2012-05-31
KR101266086B1 (ko) 2013-05-27
KR20120005393A (ko) 2012-01-16
SG10201505317XA (en) 2015-08-28
EP2602758A2 (en) 2013-06-12
JP2016195440A (ja) 2016-11-17
SG187005A1 (en) 2013-02-28
SG187006A1 (en) 2013-02-28
JP2013535858A (ja) 2013-09-12
KR101364612B1 (ko) 2014-02-20
EP2592594A4 (en) 2014-05-14
EP2602758A4 (en) 2014-01-22
US20130117400A1 (en) 2013-05-09

Similar Documents

Publication Publication Date Title
WO2012005546A2 (ko) 전자문서 유통 시스템 및 전자문서 유통 방법
Atkinson et al. Web services security (WS-Security)
US7653810B2 (en) Method to automate the renewal of digital certificates
US20070276768A1 (en) Trusted third party services system and method
JP2013535858A5 (ko)
US20040213283A1 (en) Information transmitting apparatus, information saving apparatus, information receiving apparatus, method for using the same, and recording medium thereof
Adams et al. Internet X. 509 Public Key Infrastructure data validation and certification server protocols
US8578150B2 (en) Contact information retrieval system and communication system using the contract information retrieval system
Foudil et al. A file format to aid in security vulnerability disclosure
Nadalin et al. Web services security
Abley et al. Dnssec trust anchor publication for the root zone
Foudil et al. Rfc 9116: A file format to aid in security vulnerability disclosure
Blakley et al. WS-Security Profile of the OASIS Security Assertion Markup Language (SAML)
OUT Devices Profile for Web Services
Hallam-Baker et al. WS-Security Profile of the OASIS Security Assertion Markup Language (SAML)
Hada et al. Web Services Security (WS-Security)
Bob Blakley et al. Document identifier: draft-sstc-ws-sec-profile-01 5 Location: http://www. oasis-open. org/committees/security/docs 6
Zolotarev et al. Network Working Group C. Adams Request for Comments: 3029 Entrust Technologies Category: Experimental P. Sylvester EdelWeb SA-Groupe ON-X Consulting

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 201180043451.8

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11803832

Country of ref document: EP

Kind code of ref document: A2

WWE Wipo information: entry into national phase

Ref document number: 13808576

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2013518281

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2011803832

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2011803832

Country of ref document: EP