KR100978906B1

KR100978906B1 - 전자문서 관리 시스템 및 그 운용 방법, 상기 방법을구현하는 프로그램이 저장된 기록매체

Info

Publication number: KR100978906B1
Application number: KR1020070140322A
Authority: KR
Inventors: 강현구; 임영철; 이중구; 심재성; 김동하; 이진규; 박소연
Original assignee: 정보통신산업진흥원
Priority date: 2007-09-12
Filing date: 2007-12-28
Publication date: 2010-08-31
Also published as: KR20090027555A

Abstract

본 발명은 이용자 측과 전자문서 보관소(CEDA) 측간 구성되는 연계 인터페이스의 유형에 따라 전자문서의 등록/발급/폐기/보관연장이나 전자문서 증명서의 발급/갱신발급/검증/다운로드, 검색 등이 제공되는 전자문서 관리 시스템 및 그 운용 방법, 상기 방법을 구현하는 프로그램이 저장된 기록매체에 관한 것이다. 본 발명은 전자문서를 관리하는 시스템에 있어서, 이용자의 요청에 따라 구동하는 이용자 서버; 및 이용자 서버의 요청을 처리하는 전자문서 보관소 서버를 포함하며, 이용자 서버와 전자문서 보관소 서버에는 전자문서 또는 전자문서를 증명하는 전자문서 증명서의 보안전송을 구현하는 연계 인터페이스 모듈이 구비되는 것을 특징으로 하는 전자문서 관리 시스템을 제공한다. 본 발명에 의하면, 이용자 측과 전자문서 보관소 측 상호 간에 통신 보안이 부여되어 안전하게 전자문서나 전자문서 증명서를 주고 받을 수 있게 된다.

전자문서, 전자문서 증명서, 전자문서 보관소(CEDA), 공인인증기관(CA), 연계 인터페이스, SOAP, 스키마 구조

Description

전자문서 관리 시스템 및 그 운용 방법, 상기 방법을 구현하는 프로그램이 저장된 기록매체 {System for managing electric filing document, and application method therefor, and the recording media storing the program performing the said method}

본 발명은 전자문서 관리 시스템 및 그 운용 방법, 상기 방법을 구현하는 프로그램이 저장된 기록매체에 관한 것이다. 보다 상세하게는, 이용자 측과 전자문서 보관소(CEDA) 측간 구성되는 연계 인터페이스의 유형에 따라 전자문서의 등록/발급/폐기/보관연장이나 전자문서 증명서의 발급/갱신발급/검증/다운로드, 검색 등이 제공되는 전자문서 관리 시스템 및 그 운용 방법, 상기 방법을 구현하는 프로그램이 저장된 기록매체에 관한 것이다.

일반적으로 전자문서란 컴퓨터와 같이 정보처리 능력을 가진 장치에 의하여 전자적인 형태로 작성되며, 신호를 이용하여 송수신되는 저장될 수 있는 정보를 말한다. 이러한 전자문서는 오늘날 법률에 근거하여 보호받고 있는데, 그 예로써 전기통신사업법 제5조에 따르면, "전자문서는 다른 법률에 특별한 규정이 있는 경우를 제외하고는 전자적 형태로 되어 있다는 이유로 문서로서의 효력이 부인되지 않 는다."라고 명시되어 있다.

그런데, 종래에는 이러한 전자문서에 대해 진위여부를 가늠할 수 있는 증명서가 제대로 갖추어지지 못했다. 이로 인해, 해킹 등을 통해 전자문서를 위조하거나 변조시키는 경우에는 적절한 대처가 이루어지지 못해 사용자로 하여금 전자문서 자체에 의구심을 가지게 하는 현상까지 발생하였다. 이러한 점을 감안할 때 사용자 입장에서는 전자문서의 현재 상태가 어떠한지를 전자문서 보관소 측에 문의할 수 있겠으나 종래에는 증명서가 없는 관계로 이러한 서비스 자체가 불가능하였다.

한편, 종래에는 전자문서 전달과정에서 해킹(hacking)이 발생할 경우를 대비한 대비책이 전무하였다. 이에 대해 전자문서를 암호화하는 방법이 제기되었으나, 다음과 같은 2가지 문제점이 발생하였다. 첫째, 수신자가 암호를 해독하지 못하는 경우에는 전자문서의 이용이 불가능하게 되어 매우 불편하였다. 둘째, 암호화 해독방법이 외부에 노출될 경우에는 전자문서가 무방비로 노출되는 사고 우려가 있다.

본 발명은 상술한 문제점을 해결하기 위해 안출된 것으로서, 이용자의 요청에 따라 구동되는 이용자 서버와 전자문서 보관소에 구비되는 전자문서 보관소 서버에 각각 구현되는 연계 인터페이스 모듈을 통하여 전자문서의 등록/발급/폐기/보관연장이나 전자문서 증명서의 발급/갱신발급/검증/다운로드, 검색 등을 제공하는 것을 특징으로 하는 전자문서 관리 시스템 및 그 운용 방법, 상기 방법을 구현하는 프로그램이 저장된 기록매체를 제공함을 목적으로 한다.

또한, 본 발명은 전송보안이 고려된 HTTP 기반의 SOAP 프로토콜에 따라 연계 인터페이스 모듈을 운용하는 것을 특징으로 하는 전자문서 관리 시스템 및 그 운용 방법, 상기 방법을 구현하는 프로그램이 저장된 기록매체를 제공함을 목적으로 한다.

본 발명은 상술한 목적을 달성하기 위해 안출된 것으로서, 전자문서를 관리하는 시스템에 있어서, 이용자의 요청에 따라 구동하는 이용자 서버; 및 상기 이용자 서버의 요청을 처리하는 전자문서 보관소 서버를 포함하며, 상기 이용자 서버와 상기 전자문서 보관소 서버에는 전자문서 또는 상기 전자문서를 증명하는 전자문서 증명서의 보안전송을 구현하는 연계 인터페이스 모듈이 구비되는 것을 특징으로 하는 전자문서 관리 시스템을 제공한다.

바람직하게는, 상기 전자문서 증명서는 상기 전자문서 등록을 증명하는 등록 증명서, 상기 전자문서 발급을 증명하는 발급 증명서, 상기 전자문서 이관을 증명하는 이관 증명서, 상기 전자문서 폐기를 증명하는 폐기 증명서, 발급된 전자문서가 보관된 전자문서와 동일한 원본임을 증명하는 원본 증명서, 및 일정 데이터가 특정 시각에 보관되고 있었음을 증명하는 시점확인 증명서 중 하나 이상을 포함한다.

바람직하게는, 상기 연계 인터페이스 모듈은 HTTP 프로토콜 기반의 SOAP(Simple Object Access Protocol) 프로토콜을 구현한다.

바람직하게는, 상기 전자문서 보관소 서버의 처리결과는 상기 전자문서 등록, 상기 전자문서 발급, 상기 전자문서 폐기, 상기 전자문서 보관연장, 상기 전자문서 이관, 상기 전자문서 증명서 발급, 상기 전자문서 증명서 갱신발급, 상기 전자문서 증명서 검증, 상기 전자문서 증명서 다운로드, 상기 전자문서 검색, 및 상기 전자문서 증명서를 사용한 상기 전자문서의 발급 중 어느 하나로 구성된다.

바람직하게는, 상기 이용자 서버는 상기 이용자의 요청을 반영하여 요청 메시지를 SOAP 메시지의 바디 부분에 생성하는 요청 메시지 생성부; 메시지 보안구조를 상기 SOAP 메시지의 헤더 부분에 삽입시키는 헤더 작성부; 상기 생성된 SOAP 메시지 및 첨부파일을 Multi-MIME 형식으로 패키징시키는 패키징부; 상기 패키징을 통해 완성된 이용자 요청 메시지를 상기 전자문서 보관소 서버에 송신하며, 상기 전자문서 보관소 서버로부터 상기 이용자 요청 메시지의 처리결과를 담은 보관소 응답 메시지를 수신하는 통신부; 상기 수신된 보관소 응답 메시지가 유효한 메시지인지를 판별하는 보안 처리부; 상기 보관소 응답 메시지가 유효한 메시지이면, 상 기 보관소 응답 메시지에서 처리결과인 응답 메시지 또는 첨부파일을 추출하는 데이터 추출부; 상기 추출된 응답 메시지를 검증하는 메시지 검증부; 상기 검증된 응답 메시지를 상기 이용자에 제공하는 내부 시스템 모듈; 및 상기 이용자 서버를 구성하는 모든 구성요소의 전체 작동을 제어하는 제어부를 포함한다. 또한, 상기 전자문서 보관소 서버는 상기 이용자의 요청을 담은 이용자 요청 메시지를 상기 이용자 서버로부터 수신하는 통신부; 상기 수신된 이용자 요청 메시지가 유효한 메시지인지를 판별하는 보안 처리부; 상기 이용자 요청 메시지가 유효한 메시지이면, 상기 이용자의 요청을 나타내는 요청 메시지 또는 첨부파일을 추출하는 데이터 추출부; 상기 추출된 요청 메시지를 검증하는 메시지 검증부; 상기 검증된 요청 메시지에 대한 처리결과를 도출하는 보관소 엔진 모듈; 상기 도출된 처리결과를 반영하여 응답 메시지를 SOAP 메시지의 바디 부분에 생성하는 응답 메시지 생성부; 메시지 보안구조를 상기 SOAP 메시지의 헤더 부분에 삽입시키는 헤더 작성부; 상기 생성된 SOAP 메시지 및 첨부파일을 Multi-MIME 형식으로 패키징시키는 패키징부; 및 상기 패키징을 통해 완성된 보관소 응답 메시지를 상기 통신부를 통하여 상기 이용자 서버에 제공하는 제어부를 포함한다.

더 바람직하게는, 상기 보안 처리부는 이용자 인증 또는 전자서명 검증을 통해 메시지의 유효성을 판별한다. 또한, 상기 메시지 검증부는 상기 요청 메시지 또는 상기 응답 메시지에 첨부된 전자서명을 검증하는 전자서명 검증, 상기 요청 메시지 또는 상기 응답 메시지의 무결성을 검증하는 무결성 검증, 상기 검증된 전자서명에 사용된 인증서가 유효한 것인지를 검증하는 유효성 검증, 및 상기 요청 메 시지 또는 상기 응답 메시지의 서명자가 정당한 권리자인지를 인증하는 서명자 인증 중 하나 이상을 이용하여 상기 요청 메시지 또는 상기 응답 메시지를 검증한다.

또한, 본 발명은 전자문서를 관리하는 시스템의 운용 방법에 있어서, (a) 이용자의 요청을 반영하여 요청 메시지를 생성하는 단계; (b) 상기 생성된 요청 메시지를 가공하여 SOAP 메시지인 이용자 요청 메시지를 생성 전송하는 단계; (c) 상기 전송된 이용자 요청 메시지를 수신하여 유효한 메시지인지를 판별하는 단계; (d) 상기 수신된 이용자 요청 메시지가 유효한 메시지인 경우, 상기 이용자 요청 메시지에서 상기 이용자의 요청을 나타내는 요청 메시지를 추출하는 단계; (e) 상기 추출된 요청 메시지를 처리하여 처리결과를 도출하는 단계; (f) 상기 도출된 처리결과를 반영하여 응답 메시지를 생성하는 단계; (g) 상기 생성된 응답 메시지를 가공하여 SOAP 메시지인 보관소 응답 메시지를 생성 전송하는 단계; (h) 상기 전송된 보관소 응답 메시지를 수신하여 유효한 메시지인지를 판별하는 단계; (i) 상기 수신된 보관소 응답 메시지가 유효한 메시지인 경우, 상기 보관소 응답 메시지에서 상기 처리결과를 나타내는 응답 메시지를 추출하는 단계; 및 (j) 상기 추출된 응답 메시지에 있는 처리결과를 상기 이용자에게 제공하는 단계를 포함하며, 상기 이용자의 요청 또는 상기 처리결과는 상기 전자문서 등록, 상기 전자문서 발급, 상기 전자문서 폐기, 상기 전자문서 보관연장, 상기 전자문서 이관, 상기 전자문서를 증명하는 전자문서 증명서 발급, 상기 전자문서 증명서 갱신발급, 상기 전자문서 증명서 검증, 상기 전자문서 증명서 다운로드, 상기 전자문서 검색, 및 상기 전자문서 증명서를 사용한 상기 전자문서의 발급 중 어느 하나인 것을 특징으로 하는 전 자문서 관리 시스템의 운용 방법을 제공한다.

바람직하게는, 상기 (b) 단계는 (ba) 상기 생성된 요청 메시지를 SOAP 메시지의 바디 부분에 패키징시키는 단계; 및 (bb) 메시지 보안구조를 상기 SOAP 메시지의 헤더 부분에 삽입시키는 단계를 이용하여 상기 이용자 요청 메시지를 생성하며, 상기 (g) 단계는, (ga) 상기 생성된 응답 메시지를 SOAP 메시지의 바디 부분에 패키징시키는 단계; 및 (gb) 메시지 보안구조를 상기 SOAP 메시지의 헤더 부분에 삽입시키는 단계를 이용하여 상기 보관소 응답 메시지를 생성한다. 또한, 상기 (d) 단계는 상기 추출된 요청 메시지를 검증하는 단계를 더 포함하며, 상기 (i) 단계는 상기 추출된 응답 메시지를 검증하는 단계를 더 포함한다.

더 바람직하게는, 상기 (bb) 단계와 상기 (gb) 단계는 첨부파일을 상기 SOAP 메시지와 더불어 Multi-MIME 형식으로 패키징시키는 단계를 더 포함한다.

바람직하게는, 상기 (c) 단계와 상기 (h) 단계는 이용자 인증 또는 전자서명 검증을 통해 메시지의 유효성을 판별한다.

바람직하게는, 상기 추출된 요청 메시지 또는 응답 메시지의 검증은 (a1) 상기 요청 메시지 또는 상기 응답 메시지에 첨부된 전자서명을 검증하는 단계; (a2) 상기 요청 메시지 또는 상기 응답 메시지의 무결성을 검증하는 단계; (a3) 상기 검증된 전자서명에 사용된 인증서가 유효한 것인지를 검증하는 단계; 및 (a4) 상기 요청 메시지 또는 상기 응답 메시지의 서명자가 정당한 권리자인지를 인증하는 단계를 포함한다.

또한, 본 발명은 전자문서를 관리하는 시스템의 운용 방법에 있어서, (a) 이 용자의 요청을 반영하여 요청 메시지를 생성 전송하는 단계; (b) 상기 전송된 요청 메시지를 수신하여 검증하는 단계; (c) 검증 성공시 요청 메시지를 수신하였다는 수신확인 메시지를 생성 전송하고, 검증 실패시 그 원인을 담은 에러 메시지를 생성 전송하는 단계; (d) 상기 검증된 요청 메시지를 처리하여 처리결과를 도출하는 단계; (e) 상기 도출된 처리결과를 반영하여 응답 메시지를 생성하는 단계; 및 (f) 상기 응답 메시지를 사전 협의된 바에 따라 비동기적으로 전송하는 단계를 포함하며, 상기 응답 메시지에는 상기 전자문서 등록, 상기 전자문서 발급, 상기 전자문서 폐기, 상기 전자문서 보관연장, 상기 전자문서 이관, 상기 전자문서를 증명하는 전자문서 증명서 발급, 상기 전자문서 증명서 갱신발급, 상기 전자문서 증명서 검증, 상기 전자문서 증명서 다운로드, 상기 전자문서 검색, 및 상기 전자문서 증명서를 사용한 상기 전자문서의 발급 중 어느 하나의 처리결과가 포함되는 것을 특징으로 하는 전자문서 관리 시스템의 운용 방법을 제공한다.

바람직하게는, 상기 (f) 단계에서의 비동기적 전송은 HTTP 전송, FTP 전송, E-mail 전송, 특정 프로토콜을 이용한 온라인 전송, 및 저장매체를 이용한 오프라인 전송 중 어느 하나로 구성된다.

또한, 본 발명은 컴퓨터로 판독 가능한 기록매체에 있어서, 상술한 방법을 구현하는 프로그램이 저장되는 기록매체를 제공한다.

본 발명은 상술한 목적 및 구성을 만족할 경우 다음과 같은 효과를 생산한다. 첫째, 시간과 장소에 관계없이 사용자는 전자문서 보관소 측으로부터 전자문서 증명서를 제공받을 수 있게 되며, 이에 따라 전자문서 보관소 측의 인지도는 향상될 수 있으며, 전자문서에 대한 신뢰성은 제고된다. 둘째, 본 발명에 따르면 전자문서 보관소 측이나 관련 업체들은 상호간에 일관성 있는 이용자 서버 시스템을 개발할 수 있게 되며, 전자문서 보관소 서비스 이용자는 개발업체에 상관없이 통일된 기능을 가지는 이용자 서버 시스템을 이용함으로써 보다 쉽고 신뢰할 수 있는 서비스를 이용할 수 있게 된다. 세째, 이용자 측과 전자문서 보관소 측 상호간에 통신보안이 부여되어 안전하게 전자문서나 전자문서 증명서를 주고 받을 수 있게 된다.

이하, 본 발명의 바람직한 실시예를 첨부된 도면들을 참조하여 상세히 설명한다. 우선 각 도면의 구성요소들에 참조부호를 부가함에 있어서, 동일한 구성요소들에 대해서는 비록 다른 도면상에 표시되더라도 가능한한 동일한 부호를 가지도록 하고 있음에 유의해야 한다. 또한, 본 발명을 설명함에 있어, 관련된 공지구성 또는 기능에 대한 구체적인 설명이 본 발명의 요지를 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명은 생략한다. 또한, 이하에서 본 발명의 바람직한 실시예를 설명할 것이나, 본 발명의 기술적 사상은 이에 한정하거나 제한되지 않고 당업자에 의해 변형되어 다양하게 실시될 수 있음은 물론이다.

도 1은 본 발명의 바람직한 실시예에 따른 전자문서 관리 시스템의 전체적인 구성을 개략적으로 설명한 개념도이다. 상기 도 1에 도시한 바에 따르면, 본 발명의 바람직한 실시예에 따른 전자문서 관리 시스템(100)은 이용자 단말기(110), 이용자 서버(120), 이용자 데이터베이스(122), 전자문서 보관소 서버(130), 전자문서 보관소 데이터베이스(132) 및 공인인증기관 서버(150)를 포함한다.

본 발명에 따른 전자문서 관리 시스템(100)은 전자문서를 관리하기 위한 시스템에 관한 것으로, 특히 전자문서를 증명하는 전자문서 증명서도 제공함을 그 특징으로 한다.

이용자 단말기(110)는 본 발명의 실시예에서 전자문서 또는 전자문서를 증명하는 역할을 하는 전자문서 증명서를 이용하고자 하는 자가 접속하는 단말기(terminal)를 말한다. 본 발명의 실시예에서 전자문서 증명서는 등록 증명서, 발급 증명서, 이관 증명서, 폐기 증명서, 원본 증명서, 시점확인 증명서 등 중 어느 하나일 수 있다. 증명서 각각에 대한 정의는 다음과 같다.

등록 증명서는 전자문서 보관소 서버(130)가 수행한 전자문서 등록 기능에 대한 증적을 대상으로 발급하는 보증서로 정의된다. 발급 증명서는 전자문서 보관소 서버(130)가 수행하는 전자문서 발급 기능에 대한 증적을 대상으로 발급하는 보증서로 정의된다. 이관 증명서는 전자문서 보관소 서버(130)가 수행한 전자문서 이관 기능에 대한 증적을 대상으로 발급하는 보증서로 정의된다. 폐기 증명서는 전자문서 보관소 서버(130)가 수행하는 전자문서 폐기 기능에 대한 증적(예컨대, 전자문서 폐기 사실에 대한 증명)을 대상으로 발급하는 보증서로 정의된다. 원본 증명서는 전자문서 보관소 서버(130)가 발급하는 전자문서의 내용이 전자문서 보관소 서버(130)가 보관 중인 원본 전자문서의 내용과 동일함을 증명하는 보증서로 정의된다. 시점확인 증명서는 특정 데이터가 특정 시각에 존재하였음을 증명하는 보증서로 정의된다.

전자문서 보관소 서버(130)는 공인전자문서전자문서 보관소 서버(130)(CEDA; Certified E-Document Authority)에 구비되는 정보처리 기능을 가진 장치로서, 본 발명에서는 서버 개념을 차용하였으나 꼭 서버에 한정될 필요는 없다. 즉, 서버 역할을 수행할 수 있는 컴퓨터로도 구현이 가능하며, 이는 이후 설명할 이용자 서버(120)도 마찬가지이다.

전자문서 보관소 서버(130)는 본 발명의 실시예에서 네트워크 기능을 하는 각종 유무선 통신망(140)을 통하여 이용자 서버(120)와 연결되며, 이용자 서버(120)가 요청하는 각종 사항들을 처리하는 기능을 수행한다. 본 발명에서 전자문서 보관소 서버(130)가 수행하는 기능은 이용자 서버(120)의 요청에 대응하므로 구체적인 내용은 이후 설명할 이용자 서버(120)의 기능들을 참조하면 된다.

전자문서 보관소 서버(130)는 본 발명의 실시예에서 이를 이용하는 이용자를 위해 다양한 접근방안을 제공한다. 구체적으로, 전자문서 보관소 서버(130)는 웹 상에서 문서를 등록/검색/열람하거나 증명서를 발급받을 수 있도록 ASP 기반의 포털 어플리케이션을 제공한다. 또한, 전자문서 보관소 서버(130)는 CD, DVD 등이나 FTP를 통하여 전자문서를 교환할 수 있게 하며, 휴대폰이나 PDA 등 모바일 기기를 통해서도 전자문서 등록요청, 검색, 열람 요청 등을 가능하게 한다.

전자문서 보관소 데이터베이스(132)는 전자문서 보관소 서버(130)에 연동되며, 전자문서 보관소 서버(130)가 수신하거나 처리한 데이터를 저장한다. 전자문서 보관소 데이터베이스(132)는 본 발명의 실시예에서 WORM(Write Only Read Many) 기능을 가지도록 함이 바람직하다. 그 이유는 설정된 보존 기간동안에는 데이터의 삭 제나 위변조가 불가능하게 되어 이용자로부터 높은 신뢰성을 얻을 수 있기 때문이다. 이 기능은 본 발명의 실시예에서 이용자 데이터베이스(122)에도 적용됨은 물론이다.

이용자 서버(120)는 본 발명의 실시예에서 이용자 단말기(110)를 통하여 접속하는 이용자의 요청에 따라 전자문서 또는 그 증명서에 대하여 등록, 발급신청, 제공 등의 기능을 수행한다. 구체적으로, 이용자 서버(120)는 본 발명의 실시예에서 전자문서 증명서 발급요청에 관련한 정보를 담고 있는 요청 메시지를 생성하는 기능, 요청 메시지에 따라 제공되는 전자문서 증명서를 저장시키는 기능, 전자문서 증명서 열람 기능, 전자문서 증명서를 위변조 방지되도록 설정하여 페이퍼(paper)로 출력시키는 기능, 전자문서 증명서를 검증하는 기능 등을 제공한다.

한편, 상기에서 언급한 요청 메시지는 전자서명 구조인 IETF RFC 3852 CMS(Cryptographic Message Syntax)에서 제시하는 ContentInfo 구조체로 표현된 signedData를 사용한다. signedData는 일반적으로 많이 사용되는 구조이며, 다양한 추가 정보 및 기능을 부여할 수 있는 구조를 가지고 있다. CMS는 기본적으로 인코딩 방식은 ASN.1(Abstract Syntax Notation One: 추상적 구문 표기) BER(Basic Encoding Rules: 기본 부호화 규칙)을 따르며, 일부 정보에 대하여는 DER(Distinguished Encoding Rules: 식별 부호화 규칙)을 요구할 수도 있다. 이러한 요청 메시지를 구현하는 방법으로 본 발명의 실시예에서는 예컨대 "X680; ITU-T Recommendation X.680 | ISO/IEC 8824-1: Information Technology ◎bstract Syntax Notation One (ASN.1) : Specification of basic notation", "X690; ITU-T Recommendation X.690 | ISO/IEC 8825-1: Information Technology ◎SN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", "CMP; Internet X.509 Public Key Infrastructure Certificate Management Protocol(CMP)(RFC 4210), IETF, 2005", "CMS; Cryptographic Message Syntax(RFC 3852), IETF, 2004" 등의 문헌을 참조한다. 물론, 요청 메시지를 구현하는 방법이 이 문헌들에 한정될 필요는 없다.

이용자 서버(120)는 본 발명의 실시예에서 전자문서 패키지와 관련한 기능도 제공한다. 구체적으로, 이용자 서버(120)는 이에 대해 전자문서 원본 발급요청에 관련한 정보를 담고 있는 SIP(Submission Information Package)를 생성하는 기능, SIP에 의해 발급된 전자문서 원본을 포함하는 암호화된 DIP(Dissemination Information Package)를 복호화시키는 기능, SIP와 DIP를 포함하는 전자문서 패키지를 저장시키는 기능, 전자문서 패키지 열람 기능, 전자문서 패키지가 위변조 방지되도록 설정하여 페이퍼로 출력시키는 기능 등을 제공한다.

한편, 상기에서 SIP(Submission Information Package)는 입수 정보 패키지를 말하며, 이에는 이용자가 전자문서를 전자문서 보관소 서버(130)에 전송할 때 구성하는 구조가 나타나 있다. 반면, DIP(Dissemination Information Package)는 배부 정보 패키지를 말하며, 이에는 전자문서 보관소 서버(130)가 전자문서를 이용자 서버(120)에 제공할 때 이용하는 구조가 나타나 있다.

한편, 본 발명의 실시예에서 이용자 서버(120)는 상술한 기능 이외에 이용자 관리 등 기타 운영에 관련한 기능을 제공함도 가능하다.

이상, 이용자 서버(120)가 상술한 기능들을 원활하게 제공하기 위해서는 특정 프로토콜(본 발명의 경우 HTTP 프로토콜 기반의 SOAP(Simple Object Access Protocol) 프로토콜)에 따라 전자문서 보관소 서버(130)와 연계됨이 필요하다. 이를 위해 본 발명의 실시예에서는 이용자 서버(120)와 전자문서 보관소 서버(130) 각각에 연계 인터페이스 모듈을 구성시킨다. 연계 인터페이스 모듈이라 함은 타 서버(또는 단말기)의 접근이나 상호간에 데이터 전송이 이루어질 수 있도록 프로그램으로 제어되는 모듈로서, 본 발명의 실시예에서는 메시지를 생성하거나 처리하는 기능을 하며, 메시지 보안 기능도 제공한다. 연계 인터페이스 모듈에 대한 자세한 설명은 이용자 서버(120)와 전자문서 보관소 서버(130)의 내부구성을 설명할 때에 할 것이므로 여기서는 생략한다. 다만, 연계 인터페이스의 유형별 분류는 다음과 같음을 미리 언급한다. ① 문서 등록(SubmitDocument), ② 문서 발급(GetDocument), ③ 문서 3자발급(DeliverDocument), ④ 증명서를 사용한 문서 발급(GetDocumentByCert), ⑤ 문서 이관(TransferDocument), ⑥ 문서 폐기(DeleteDocument), ⑦ 문서 보관연장(ExtendRetention), ⑧ 증명서 발급(IssueCert), ⑨ 증명서 갱신발급(UpdateCert), ⑩ 증명서 검증(VerifyCert), ⑪ 증명서 다운로드(GetCert), ⑫ 검색(Search).

한편, 연계 인터페이스 모듈이 송수신하는 메시지로는 요청 메시지, 응답 메시지, 에러 메시지 등 3가지가 있다. 요청 메시지는 이미 언급한 바와 같이 이용자 단말기(110)가 증명서 발급을 위해 요청한 일련의 정보(예컨대, 증명 요청서)를 담고 있는 메시지를 말한다. 응답 메시지는 요청 메시지에 대한 처리 결과로서 전자 문서 보관소 서버(130)가 생성한 일련의 정보(예컨대, DIP)를 담고 있는 메시지를 말한다. 에러 메시지는 응답 메시지 생성에 실패하였을 경우 그 원인에 대한 정보를 담고 있는 메시지를 말한다. 이상, 언급한 메시지의 표준 구조(즉, 연계 인터페이스를 위한 메시지 표준 구조)에 대한 자세한 설명은 후술한다.

한편, 이후 설명할 연계 인터페이스 모듈은 본 발명에 제안된 바에 한정되지 않으며, 시행령, 시행규칙, 관련고시 등에 적합하다면 다른 모듈을 더 추가하거나 이용자 정의 프로토콜을 사용함도 가능하다. 다만, 이러한 연계 인터페이스 모듈은 본 발명의 실시예에서 각 서버에 용이하게 접근할 수는 있으나 어느 서버에도 종속적이지 않게 구현됨이 바람직하다.

이용자 데이터베이스(122)는 이용자 서버(120)와 연계되는 데이터베이스로서, 본 발명에서는 이용자 서버(120)가 수신하거나 처리한 데이터를 저장한다.

공인인증기관 서버(150)는 공인인증기관(CA; Certificate Authority)에 구현되는 서버로서, 본 발명의 실시예에서 전자문서 보관소 서버(130)에 네트워크 연결된다. 이러한 공인인증기관 서버(150)는 전자문서 보관소 서버(130) 이용자들의 인증서를 발급하게 해주는 기능을 수행한다. 또한, 공인인증기관 서버(150)는 인증서 유효성 검증을 위하여 디렉토리(Directory) 또는 OCSP(Online Certificate Status Protocol : 실시간 인증서 상태 확인 프로토콜) 기능을 제공한다. 공인인증기관 서버(150)가 구현하는 이러한 기능들은 예컨대, "X500; ITU-T Recommendation X.500 | ISO/IEC 9594-1:1998, Information technology - Open Systems Interconnection - The Directory : Overview Of Concepts, Models and Services", "X501; ITU-T Recommendation X.501 | ISO/IEC 9594-2:1995, Information technology - Open Systems Interconnection - The Directory : Part 2 : Models", "X509; ITU-T Recommendation X.509 | ISO/IEC 9594-8:1998, Information technology - Open Systems Interconnection - The Directory : Authentication Framework" 등의 문헌을 참고할 수 있으므로 자세한 설명은 여기서는 생략한다.

다음으로, 이용자 서버(120)와 전자문서 보관소 서버(130)의 내부구성을 설명한다. 도 2는 본 발명의 바람직한 실시예에 따른 이용자 서버와 전자문서 보관소 서버의 내부구성을 도시한 블록도이다. 도 2를 참조하면, 본 발명에 따른 이용자 서버(120)는 내부 시스템 모듈(200)과 제1 연계 인터페이스 모듈(210)로 구분된다.

내부 시스템 모듈(200)은 본 발명의 실시예에서 이용자 단말기(110)의 요청을 수신하며, 상기 요청에 대한 처리결과가 도달되면 이를 토대로 도 1을 참조하여 상술한 기능들을 수행하는 역할을 한다. 내부 시스템 모듈(200)이 이러한 기능을 수행함을 참작할 때, 본 발명의 실시예에서 전자문서 증명서나 전자문서 패키지의 열람을 제공하는 디스플레이부, 페이퍼로의 출력을 제공하는 인쇄부, 상기 인쇄부와 연동하여 출력물의 위변조가 방지되도록 하는 위변조 방지부, 요청 메시지에 담을 내용을 조회하는 조회부 등으로 구현시킬 수 있다.

제1 연계 인터페이스 모듈(210)은 이용자 단말기(110)의 요청을 SOAP 프로토콜에 적합하게 정형화시킴으로써 요청 메시지를 생성하며, 상기 SOAP 프로토콜을 참고하여 수신된 응답 메시지에서 처리결과를 추출하는 역할을 한다. 본 발명에서 의 SOAP 프로토콜은 SOAP v1.1 이상의 규약을 기준으로 하는데, 바람직하게는 "SOAP Version1.2 Part 0: Primer, W3C, 2005(http://www.s3c.org/TR/2003/REC-soap12-part0-20030624#L11549)", "ebXML Registry Services and Protocols V3.0, OASIS, 2005(http://docs.oasis-open.org/regrep-rs/v3.0/)", "Web Services Description Language(WSDL) Version2.0 Part 0: Primer, W3C, 2005(http://www.s3c.org/TR/2005/WD-wsdl20-primer-20050803) 등을 참조한다.

이에 반해, 전자문서 보관소 서버(130)는 보관소 엔진 모듈(250)과 제2 연계 인터페이스 모듈(260)로 구분된다. 보관소 엔진 모듈(250)은 본 발명의 실시예에서 이용자 단말기(110)의 요청을 파악하고, 이에 대해 처리결과를 생성하는 역할을 한다. 보관소 엔진 모듈(250)이 이러한 기능을 수행함을 참작할 때, 본 발명의 실시예에서 전자문서를 등록하고 이에 대한 증적을 생성하는 등록 관리부, 전자문서 원본을 발급하고 이 사실에 대한 증적을 생성하는 발급 관리부, 발급 증명서, 이관 증명서, 폐기 증명서, 시점확인 증명서 등 각종 전자문서 증명서를 생성하는 증명서 관리부, 증명의 대상이 되는 증적을 검색하는 증적 검색부 등으로 구현시킬 수 있다.

제2 연계 인터페이스 모듈(260)은 SOAP 프로토콜을 참고하여 수신된 요청 메시지에서 요청내용을 추출하며, 이에 대한 응답결과를 SOAP 프로토콜에 적합하게 정형화시킴으로써 응답 메시지를 생성하는 역할을 한다. 대체적인 기능이 제1 연계 인터페이스 모듈(210)과 유사한 바, 모듈을 구성하는 구성부는 아래에서 비교하여 설명하기로 한다. 비교대상에서 전자는 제1 연계 인터페이스 모듈(210)에 구비되 며, 후자는 제2 연계 인터페이스 모듈(260)에 구비됨에 유의한다.

요청 메시지 생성부(211)는 본 발명의 실시예에서 이용자 단말기(110)의 요청을 토대로 하여 요청 메시지를 SOAP 메시지의 바디 부분에 생성하는 기능을 수행한다. 반면, 응답 메시지 생성부(261)는 본 발명의 실시예에서 상기 요청에서 얻어진 결과를 토대로 하여 응답 메시지를 SOAP 메시지의 바디 부분에 생성하는 기능을 수행한다.

헤더 작성부는 본 발명의 실시예에서 메시지의 보안구조(security structure)를 SOAP 메시지의 헤더 부분에 작성하는 기능을 수행한다. 이 헤더 작성부 또한 양 서버(120, 130)에 각각 구비되는 바, 이하 설명에서는 제1 헤더 작성부(212)와 제2 헤더 작성부(262)로 구분한다.

패키징부는 본 발명의 실시예에서 요청 메시지 생성부(211)와 헤더 작성부의 작용에 따라 생성된 SOAP 메시지 및 첨부파일을 Multi-MIME 형식으로 패키징시키는 기능을 수행한다. 이 패키징부는 양 서버(120, 130)에 각각 구비되는 바, 이하 설명에서는 이용자 서버(120)에 구비되는 제1 패키징부(213)와 전자문서 보관소 서버(130)에 구비되는 제2 패키징부(263)로 구분한다.

통신부는 본 발명의 실시예에서 패키징을 통해 생성된 메시지를 송수신하는 기능을 수행한다. 통신부 또한 양 서버(120, 130)에 각각 구비되는 바, 이하 설명에서는 제1 통신부(214)와 제2 통신부(264)로 구분한다.

보안 처리부는 본 발명의 실시예에서 수신한 메시지에 대해 이용자 인증, 복호화, 전자서명 검증 등을 실행하여 유효한 메시지인지 여부를 판별하는 기능을 수 행한다. 보안 처리부 또한 양 서버(120, 130)에 각각 구비되는 바, 이하 설명에서는 제1 보안 처리부(215)와 제2 보안 처리부(265)로 구분한다.

메시지 검증부는 본 발명의 실시예에서 스키마, 권한 등을 참작하여 메시지를 검증하는 기능을 수행한다. 자세한 내용은 후술할 것인 바 여기서는 생략한다. 메시지 검증부 또한 양 서버(120, 130)에 각각 구비되는 바, 이하 설명에서는 제1 메시지 검증부(218)과 제2 메시지 검증부(268)로 구분한다.

데이터 추출부는 본 발명의 실시예에서 수신된 SOAP 메시지의 SOAP body에서 메시지의 내용이나 첨부파일을 추출하는 기능을 수행한다. 데이터 추출부 또한 양 서버(120, 130)에 각각 구비되는 바, 이하 설명에서는 제1 데이터 추출부(216)와 제2 데이터 추출부(266)로 구분한다. 한편, 상기에서 언급한 스키마는 본 발명의 경우 XML로 데이터를 정의한 구조로 이해하면 충분할 것이다.

제어부는 본 발명의 실시예에서 서버를 구성하는 모든 구성부의 전체 작동을 제어하는 기능을 수행한다. 제어부 또한 양 서버(120, 130)에 각각 구비되는 바, 이하 설명에서는 제1 제어부(217)와 제2 제어부(267)로 구분한다.

다음으로, 도 2에서 설명한 두 연계 인터페이스 모듈(210, 260)의 기능을 참작하여 이용자 서버(120)와 전자문서 보관소 서버(130) 사이에서 이루어지는 전자문서 증명서 발급방법을 설명한다. 일반적으로 전자문서 관리 시스템(100)의 운용 방법은 SOAP 바인딩에 의한 처리절차에 따라 진행된다. 이하, 도면을 참조하여 이에 대해 상세하게 설명한다. 도 3은 본 발명의 바람직한 실시예에 따른 전자문서 관리 시스템의 운용 방법을 설명한 순서도이다.

도 3을 참조하면, 이용자 단말기(110)를 통해 이용자의 요청이 접수되면, 이용자 서버(120)의 내부 시스템 모듈(200)은 이 요청을 근거로 인터페이스를 호출한다(S300). 예컨대, 이용자의 요청이 전자문서 등록일 경우, 내부 시스템 모듈(200)은 보관할 전자문서가 발생한 사실을 근거로 전자문서 보관소 서버(130)에 연계 요구를 하기 위해 보관이 필요한 전자문서와 이 전자문서에 대한 속성정보를 전달인자(즉, 요청 정보)로 하여 문서보관 요청 인터페이스를 호출한다. 한편, 내부 시스템 모듈(200)은 S300 단계 이행 이전에 이용자 단말기(110)로부터 이용자에 대한 정보를 제공받는다. 이때에 제공되는 이용자 정보는 요청 데이터에 포함되며, 추후 전자문서 보관소 서버(130)의 제2 보안 처리부(265)가 이용자 인증을 실행할 경우에 이용된다. 이용자 인증에 대한 자세한 설명은 제2 보안 처리부(265) 기능 수행 단계에서 하기로 한다.

이후, 제1 연계 인터페이스 모듈(210)의 요청 메시지 생성부(211)는 내부 시스템 모듈(200)에서 제공된 요청 정보를 토대로 요청 메시지를 SOAP 메시지의 바디 부분에 생성시킨다(S305). 한편, S305 단계에서 요청 메시지 생성부(211)는 내부 시스템 모듈(200)의 조회부와 연동하여 요청 메시지에 담을 내용을 조회함도 가능하다. 한편, 연계 인터페이스의 유형에 따른 요청 메시지의 스키마 구조 설정은 도 5 series를 참조하여 후술한다.

이후, 제1 헤더 작성부(212)가 전송보안을 고려하여 SOAP 메시지의 SOAP Header를 보안처리되도록 작성한다(S310). 이때, 제1 헤더 작성부(212)는 메시지에 대한 전자서명을 SOAP Header에 포함시켜 작성함도 가능하다. 제1 헤더 작성부(212)가 작성하게 될 SOAP Header에 대해서는 도 4 series를 참조하여 후술하는 요청 메시지와 응답 메시지의 전체 패키징 구조에 기재된 내용을 참고한다. 한편, 모든 요청 메시지는 보안 규약에 따라 보안이 적용됨이 필요하다. 보안요구에 따른 처리방안(전송보안)은 예컨대 "Web Service Security V1.1, OASIS, 2004(http://www.oasis-open.org /committees/download.php/16790/wss-v1.1-spec-os-SOAPMessageSecurity.pdf)"의 내용을 적용할 수 있으며, 이에 대한 보다 자세한 내용은 후술할 것이므로 여기서는 생략한다.

이후, 제1 패키징부(213)가 생성된 SOAP 메시지 및 첨부파일을 Multi-MIME 형식으로 패키징시킨다(S315). 본 발명에 따른 요청 메시지의 처리 프로세스 및 메시지 구조는 연계 인터페이스를 위한 표준 메시지 구조(표 1 내지 표 53 내용 참조)를 HTTP 통신 프로토콜 상의 SOAP 프로토콜에 적용시킨 것이다. 전체 패키징 구조에 대한 보다 자세한 설명은 이후 도 4 series를 참조하여 설명하기로 하고, 여기서는 그 설명을 생략한다.

S315 단계가 완료되면 본 발명에 따른 이용자 요청 메시지가 완성되며, 제1 통신부(214)는 제1 제어부(217)의 제어에 따라 완성된 이용자 요청 메시지를 전자문서 보관소 서버(130)로 전송한다(S320). 이때, 이용자 요청 메시지는 HTTP 기반으로 전송됨은 물론이다.

이후, 제2 연계 인터페이스 모듈(260)의 제2 통신부(264)가 상기 이용자 요청 메시지를 수신하면, 상기 이용자 요청 메시지는 제2 제어부(267)의 제어에 따라 제2 보안 처리부(265)에 제공된다. 그러면, 제2 보안 처리부(265)는 보안처리된 이용자 요청 메시지를 이용자 인증, 복호화, 전자서명 검증 등을 거쳐서 유효한 메시지인지 여부를 판별한다(S325). 제2 보안 처리부(265)가 이용자 요청 메시지의 유효성 여부를 판별하는 방법은 도 6 series를 참조하여 후술한다.

제2 보안 처리부(265)가 이용자 요청 메시지를 유효한 메시지로 판별하면, 제2 데이터 추출부(266)는 이용자 요청 메시지에서 SOAP body에 기재된 요청 메시지를 추출한다(S330). 이와 동시에, 제2 메시지 검증부(268)가 제2 데이터 추출부(266)에 연동되어 추출된 요청 메시지를 검증하게 된다(S335). 추출된 요청 메시지가 검증을 통과하면, 첨부파일이 존재하는 경우에 한해 제2 데이터 추출부(266)는 이용자 요청 메시지에서 첨부파일을 추출한다. 한편, 제2 메시지 검증부(268)가 추출된 요청 메시지를 검증하는 방법은 후술할 것이므로 여기서는 생략한다.

추출 검증된 요청 메시지(및 첨부파일)는 제2 제어부(267)에 의해 보관소 엔진 모듈(250)에 제공되며, 보관소 엔진 모듈(250)은 문서등록, 검색, 문서발급 등 요청을 처리한다(S340).

이후, 응답 메시지 생성부(261)는 보관소 엔진 모듈(250)의 처리결과를 토대로 응답 메시지를 SOAP 메시지의 바디 부분에 생성한다(S345). 제2 헤더 작성부(262) 및 제2 패키징부(263)에 의해 상기 응답 메시지를 포함하는 보관소 응답 메시지가 생성되며, 이 보관소 응답 메시지가 이용자 서버(120)에 제공되어 응답 메시지(및 첨부파일)가 추출 검증되기까지의 과정(S350 ~ S375)은 상술한 S310 단계 내지 S335 단계와 동일하므로 상세한 설명을 생략한다. 한편, S345 단계에서 생 성된 응답 메시지의 구조, 특히 연계 인터페이스의 유형에 따른 응답 메시지의 스키마 구조 설정은 도 7 series를 참조하여 후술한다.

이후, 응답 메시지(및 첨부파일)가 추출 검증되면 제1 제어부(217)는 내부 시스템 모듈(200)에 처리결과를 통지하며(S380), 내부 시스템 모듈(200)은 처리결과를 확인하고 이 사실을 이용자 단말기(110)에 제공한다.

다음으로, 이용자가 자신의 단말기를 이용하여 전자문서 보관소 서버(130)의 서비스를 이용할 경우 요구되는 연계 인터페이스를 위한 표준 메시지 구조를 설명한다. 연계 인터페이스를 위한 표준 메시지 구조는 전자문서 보관소 서버(130)가 외부 시스템과의 연계를 위한 통신 시스템 구축시 메시지에 반드시 포함하여야 하는 필수 인자들을 구조화한 것으로서, 본 발명에서 연계 인터페이스를 위해 사용될 SOAP 프로토콜도 이 메시지 구조를 준용한다. 이 메시지 구조는 각 서비스의 요청 및 응답 메시지 내의 필수 인자들을 계층화 표현하며, 추가 인자들을 확장 가능하도록 하여 통신 프로토콜이나 개발 언어에 관계없이 각 전자문서 보관소 서버(130)가 구축하는 통신 시스템에 적용 가능하도록 한 특징이 있다.

이미 언급하였듯이, 전자문서 보관소 서버(130) 서비스 이용시 생성 및 처리되는 송수신 메시지는 이용자 서버(120)가 생성하여 전자문서 보관소 서버(130)에 송신하는 요청 메시지와 서비스 요청에 대한 응답으로 전자문서 보관소 서버(130)가 생성하여 이용자 서버(120)로 송신하는 응답 메시지로 구분된다. 이하, 요청 메시지와 응답 메시지의 구조를 차례대로 설명한다.

요청 메시지는 크게 MessageHeader와 MessageBody로 이루어진다. MessageHeader에는 작업 종류, 요청/응답 구분, 메시지 식별자, 타임스탬프 등 요청 메시지에 대한 일반적인 정보를 나타내는 필드들이 포함되며, 이러한 MessageHeader의 구조는 응답 메시지에서도 동일하다. MessageBody는 처리 요청 건수를 포함하는 RequestHeader와 실제 요청 내용이 포함된 RequestBody로 이루어진다. 동일 작업에 대하여 복수개의 데이터 처리가 가능하도록 RequestBody는 RequestData가 반복적으로 추가될 수 있는 구조를 지닌 RequestDataList를 포함하며, RequestData의 구조는 연계 유형별 요청 메시지 구조에서 각 서비스 유형에 따른 이름과 구조로 재정의된다. RequestBody에는 확장 필드를 의미하는 Slot이 반복적으로 추가될 수 있는 구조를 지닌 SlotList를 RequestDataList의 다음에 포함할 수 있다.

요청 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명, 슬롯(slot) 구조 등에 대한 자세한 설명은 표 1 내지 표 3에 제시한다.

응답 메시지도 요청 메시지와 같이 MessageHeader와 MessageBody로 이루어진다. MessageHeader의 구조는 요청 메시지와 동일하다. MessageBody는 전체 처리결과, 전체 처리건수, 성공한 처리건수, 실패한 처리건수를 포함하는 ResponseHeader와 실제 응답 내용이 포함된 ResponseBody로 이루어진다. ResponseBody는 전체 처리결과인 TotalResultCode의 값에 따라 ResponseDataList나 FailReason으로 대치되는 ResponseResult를 포함한다.

이때 복수의 요청건수에 대한 처리결과가 부분 성공일 경우나 전체 실패일 경우라도 전체 처리결과를 성공으로 처리할지 실패로 처리할지에 대한 결정은 전자문서 보관소 서버(130) 정책을 따른다. 예를 들어, 전자문서 보관소 서버(130)는 복수의 요청에 대한 처리결과가 모두 실패이나, 각 요청에 대한 개별적인 실패사유를 이용자에게 전달하기 위하여 전체 처리결과를 성공으로 설정할 수 있다. 전체 처리결과가 성공인 경우 요청 메시지와 마찬가지로 복수개의 요청에 대한 응답이 가능하도록 ResponseDataList는 복수개의 ResponseData를 포함할 수 있는 구조로 되어 있으며, ResponseData의 구조는 연계 인터페이스 유형별 응답 메시지 구조에서 각 서비스 유형에 따른 이름과 구조로 재정의된다. 전체 처리결과가 실패인 경우, 실패 사유인 FailReason이 ResponseResult를 대신하게 된다. ResponseBody에서도 RequestBody와 마찬가지로, 확장 필드를 의미하는 Slot이 반복적으로 추가될 수 있는 구조를 지닌 SlotList를 ResponseResult의 다음에 포함할 수 있다.

응답 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명은 표 4 ~ 표 5에 제시한다.

한편, 요청 메시지와 응답 메시지의 전체 구조는 거의 동일하나, 메시지에 포함되어 서비스 요청 및 응답에 필요한 실제 데이터를 전달하는 RequestData 구조체와 ResponseData 구조체는 각 서비스 유형에 따라 이름 및 구조가 달라지게 된다. 이하, 이를 참작한 연계 인터페이스 유형별 요청 메시지 구조와 응답 메시지 구조를 설명한다.

① 문서 등록(SubmitDocument)

전자문서 등록 요청 메시지(SubmitDocumentRequest)는 SIP에 대한 정보를 포함한다. SIP는 요청 메시지 내에 포함될 수도 있고, 요청 메시지의 외부에 파일 형태로 첨부될 수도 있으며, SIP가 요청 메시지 외부에 첨부되는 방식이나 구조는 전자문서 보관소 서버(130)의 구현 방식을 따른다. 요청 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명은 표 6 ~ 표 7에 제시한다.

전자문서 등록 요청에 대한 응답 메시지(SubmitDocumentResponse)는 해당 SIP에 대한 처리 결과가 포함하는데, 등록 작업의 처리 결과가 성공인 경우는 SIP를 등록한 후 발급된 등록증명서에 대한 정보를 포함하며, 실패인 경우는 실패의 사유를 포함한다. 처리 결과가 성공인 경우에 포함되는 등록증명서는 요청 메시지의 SIP와 마찬가지로 응답 메시지 내에 첨부될 수도 있고, 응답 메시지의 외부에 파일 형태로 첨부될 수도 있으며, 등록증명서가 응답 메시지 외부에 첨부되는 방식이나 구조는 전자문서 보관소 서버(130)의 구현 방식을 따른다. 응답 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명은 표 8 ~ 표 9에 제시한다.

② 문서 발급(GetDocument)

전자문서 보관소 서버(130)에 보관 중인 전자문서를 발급받을 때 이용하는 전자문서 발급 서비스에 대한 요청 및 응답 메시지를 정의한다. 이용자는 전자문서를 열람하거나 기타 활용을 목적으로 전자문서 보관소 서버(130)에 보관 중인 전자문서를 발급해줄 것을 요청할 수 있고, 전자문서 보관소 서버(130)는 이에 대한 응답으로 DIP의 형태로 전자문서를 발급한다.

전자문서 발급 요청 메시지(GetDocumentRequest)는 발급받고자 하는 전자문서가 속한 AIP의 식별자와 AIP 내의 전자문서의 식별자를 포함한다. 수신한 DIP를 발급 요청자가 특정인에게만 배포할 목적으로 특정인의 인증서 공개키로 암호화하여 발급해줄 것을 요청할 수 있으며, 발급 요청자가 문서의 내용을 열람해야 할 필요가 있을 때는 반드시 특정인의 인증서 리스트에 발급 요청자의 인증서도 포함시켜야 한다. 이용자가 전자문서 발급 요청을 하기 위해서는 미리 AIP 패키지 식별자 및 패키지 내의 전자문서의 식별자를 검색하여 요청 메시지에 해당 식별자를 설정하여야 한다. 요청 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명은 표 10 ~ 표 11에 제시한다.

전자문서 발급 요청에 대한 응답 메시지(GetDocumentResponse)는 해당 전자문서에 대한 발급 작업의 처리 결과가 성공인 경우는 DIP에 대한 정보를 포함하며, 실패인 경우는 실패의 사유를 포함한다. 처리 결과가 성공인 경우에 포함되는 DIP는 응답 메시지의 내에 첨부될 수도 있고, 응답 메시지의 외부에 파일 형태로 첨부될 수도 있으며, DIP가 응답 메시지 외부에 첨부되는 방식이나 구조는 전자문서 보관소 서버(130)의 구현 방식을 따른다. 응답 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명은 표 12 ~ 표 13에 제시한다.

③ 문서 3자발급(DeliverDocument)

전자문서 보관소 서버(130)에 보관 중인 전자문서를 제3자에게 발급하도록 요청할 때 이용하는 전자문서 3자 발급 서비스에 대한 요청 및 응답 메시지를 정의한다. 이용자는 전자문서 보관소 서버(130)에 보관 중인 전자문서를 제3자에게 발급해줄 것을 요청할 수 있고, 전자문서 보관소 서버(130)는 이에 대한 응답으로 전자문서 발급의 가능 여부만을 확인한 후, 확인 결과에 대한 응답 메시지를 리턴한다. 전자문서의 수신자에게 전자문서가 송신되는 작업은 요청 및 응답 작업과는 비동기적으로 수행되며, 수신자는 반드시 제3자가 아닌 요청자 본인이어도 무방하다. 전자문서 3자 발급 작업을 완료한 후, 전자문서 보관소 서버(130)는 작업의 결과 및 실패시 오류 메시지를 요청자의 E-mail로 송신하여야 한다. 문서 3자 발급 기능에 대한 구현은 전자문서 보관소 서버(130)의 정책상 선택적으로 구현 가능한 기능이다.

전자문서 3자 발급 요청 메시지(DeliverDocumentRequest)는 전자문서 수신자의 E-mail과 전자문서를 암호화하는데 사용할 전자문서 수신자의 인증서 정보를 포함한다. 전자문서 수신자의 인증서는 요청 메시지의 내에 첨부될 수도 있고, 요청 메시지의 외부에 파일 형태로 첨부될 수도 있으며, 인증서가 요청 메시지 외부에 첨부되는 방식이나 구조는 전자문서 보관소 서버(130)의 구현 방식을 따른다. 이용자가 전자문서 3자 발급 요청을 하기 위해서는 미리 AIP 패키지 식별자 및 패키지 내의 전자문서의 식별자를 검색하여 요청 메시지에 해당 식별자를 설정하여야 한다. 요청 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명은 표 14 ~ 표 15에 제시한다.

전자문서 보관소 서버(130)가 전자문서를 제3자에서 송신하는 작업은 요청 및 응답 작업 시점과 비동기적으로 이루어지므로, 전자문서 3자 발급 요청에 대한 응답 메시지(DeliverDocumentResponse)에는 해당 전자문서에 대한 발급 가능 여부의 확인 결과가 포함된다. 실제 전자문서는 비동기적으로 발급되어 요청 메시지에 포함된 수신자의 E-mail로 직접 전송되거나, 이용자와 사전에 협의된 방식으로 수신자에게 전달된다. 전자문서 보관소 서버(130)는 전자문서를 비동기적으로 전달하는 절차 또는 방식을 제한하지는 않는다. 즉, HTTP나 FTP, 또는 자체 구현한 송수신 프로토콜 등을 이용한 ON-LINE 방식이나, CD나 TAPE 등의 저장매체를 통한 OFF-LINE 방식도 가능하다. 이때는 수신자의 E-mail로 처리결과의 전달과 관련된 통지 메시지를 전송하도록 한다. 전자문서가 수신자의 E-mail로 전달되는 과정은 안전하지 않을 수 있으므로, 반드시 요청 메시지에 첨부된 전자문서 수신자의 인증서를 사용하여 DIP 내의 전자문서를 암호화하여 송신하여야 하며, 이때 요청 메시지에 첨부된 전자문서 수신자의 인증서에 대한 검증 여부는 전자문서 보관소 서버(130)의 정책에 따른다. 전자문서를 이용자와 사전에 협의된 방식으로 수신자에게 전달하는 경우는 비동기식 처리시에 고려하여야 하는 후술하는 전송보안의 내용을 준용한다. 응답 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명은 표 16 ~ 표 17에 제시한다.

④ 증명서를 사용한 문서 발급(GetDocumentByCert)

등록증명서에 수임자(nominee)로 설정되어 있는 이용자가 등록증명서를 사용하여 전자문서를 발급받을 때 이용하는 증명서를 사용한 전자문서 발급 서비스에 대한 요청 및 응답 메시지를 정의한다. 이용자는 증명서 및 자신의 인증서를 사용하여 자신이 전자문서에 대한 정당한 수임자임을 증명하게 된다. 증명서를 사용한 문서 발급 기능에 대한 구현은 전자문서 보관소 서버(130)의 정책상 선택적으로 구현 가능한 기능이다.

증명서를 사용한 전자문서 발급 요청 메시지(GetDocumentByCertRequest)는 발급받고자 하는 전자문서를 등록한 후 발급된 등록증명서에 대한 정보와 부가적으로 요청자의 실명 및 식별번호를 포함한다. 등록증명서는 요청 메시지의 내에 첨부될 수도 있고, 요청 메시지의 외부에 파일 형태로 첨부될 수도 있으며, 등록증명서가 요청 메시지 외부에 첨부되는 방식이나 구조는 전자문서 보관소 서버(130)의 구현 방식을 따른다. 요청자의 실명 및 식별번호는 등록증명서에 포함된 수임자 정보(nomineeInfo 필드)에 실명 및 주민번호가 사용된 경우에 이를 식별하기 위하여 반드시 포함하여야 하며, 수임자 정보로 요청자의 인증서만 사용되었다면 포함하지 않아도 된다. 증명서를 사용하여 전자문서 발급 서비스를 요청하는 이용자는 등록증명서와 함께 자신의 인증서 및 서명을 함께 전달하여 자신이 정당한 수임자임을 증명하여야 하는데, 이때의 인증서 및 서명의 전달 방법은 본 요청 메시지 구조에서는 제시하지 않으며, 전자문서 보관소 서버(130)에서 구현하는 송수신 프로토콜 상의 부인방지 및 무결성 증명의 방법으로 전달하는 인증서 및 서명을 사용하도록 한다. AIP 패키지 식별자는 등록증명서에 포함되어 있으므로 별도로 설정할 필요가 없으며, 패키지 내 전자문서의 식별자 또한 증명서를 사용하여 전자문서를 발급하는 경우에는 반드시 장기보존본 전자문서를 포함한 DIP를 발급하여야 하므로 설정할 필요가 없다. 요청 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명은 표 18 ~ 표 19에 제시한다.

증명서를 사용한 전자문서 발급 요청에 대한 응답 메시지(GetDocumentByCertResponse)는 해당 전자문서에 대한 발급 작업의 처리 결과가 성공인 경우는 DIP에 대한 정보를 포함하며, 실패인 경우는 실패의 사유를 포함한다. 처리 결과가 성공인 경우에 포함되는 DIP는 응답 메시지의 내에 첨부될 수도 있고, 응답 메시지의 외부에 파일 형태로 첨부될 수도 있으며, DIP가 응답 메시지 외부에 첨부되는 방식이나 구조는 전자문서 보관소 서버(130)의 구현 방식을 따른다. 발급된 DIP에 포함된 전자문서의 유형은 반드시 장기보존본으로 변환된 전자문서이어야 한다. 응답 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명은 표 20 ~ 표 21에 제시한다.

⑤ 문서 이관(TransferDocument)

전자문서 보관소 서버(130)에 보관 중인 전자문서를 타 전자문서 보관소 서버(130)에 이관할 것을 요청할 때 이용하는 전자문서 이관 서비스에 대한 요청 및 응답 메시지를 정의한다. 이용자는 전자문서 보관소 서버(130)에 보관 중인 전자문서를 타 전자문서 보관소 서버(130)에 이관해줄 것을 요청할 수 있고, 전자문서 보관소 서버(130)는 이에 대한 응답으로 전자문서를 타 전자문서 보관소 서버(130)에 이관할 수 있는가에 대한 여부만을 확인한 후, 확인 결과에 대한 응답 메시지를 리턴한다. 전자문서를 타 전자문서 보관소 서버(130)에 이관하는 작업은 요청 및 응답 작업과는 비동기적으로 수행된다. 전자문서 이관 작업을 완료한 후, 전자문서 보관소 서버(130)는 작업의 결과 및 실패시 오류 메시지를 요청자의 E-mail로 송신하여야 한다.

전자문서 이관 요청 메시지(TransferDocumentRequest)는 이관 대상인 전자문서의 AIP 패키지 식별자와 전자문서를 수관할 전자문서 보관소 서버(130)의 식별자를 포함한다. 이용자가 전자문서 이관 요청을 하기 위해서는 미리 AIP 패키지 식별자 및 수관 전자문서 보관소 서버(130)의 식별자를 검색하여 요청 메시지에 해당 식별자를 설정하여야 한다. 요청 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명은 표 22 ~ 표 23에 제시한다.

전자문서 보관소 서버(130)가 전자문서를 타 전자문서 보관소 서버(130)에 이관하는 작업은 요청 및 응답 작업 시점과 비동기적으로 이루어지므로, 전자문서 이관 요청에 대한 응답 메시지(TransferDocumentResponse)에는 해당 전자문서에 대한 이관 가능 여부의 확인 결과가 포함된다. 응답 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명은 표 24 ~ 표 25에 제시한다.

⑥ 문서 폐기(DeleteDocument)

전자문서 보관소 서버(130)에 보관중인 전자문서를 폐기 요청할 때 이용하는 전자문서 폐기 서비스에 대한 요청 및 응답 메시지를 정의한다. 이용자는 전자문서의 보관 만료일 전에 전자문서 보관소 서버(130)에 보관중인 전자문서를 폐기해줄 것을 요청할 수 있고, 전자문서 보관소 서버(130)는 이에 대한 응답으로 전자문서를 폐기한 후 이용자의 요청이 있을시 원본 전자문서를 포함한 DIP를 생성하여 이용자에게 전송한다. 물론 전자문서를 폐기한 후 원본 전자문서를 발급해주는 경우에 전자문서 보관소 서버(130)는 먼저 DIP를 생성한 후 전자문서를 폐기하도록 한다.

전자문서 폐기 요청 메시지(DeleteDocumentRequest)는 폐기하고자 하는 전자문서가 속한 AIP 패키지 식별자를 포함한다. 이용자가 전자문서 폐기 요청을 하기 위해서는 미리 AIP 패키지 식별자를 검색하여 요청 메시지에 해당 식별자를 설정하여야 한다. 요청 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명은 표 26 ~ 표 27에 제시한다.

전자문서 폐기 요청에 대한 응답 메시지는 해당 전자문서에 대한 폐기 작업의 처리 결과가 성공인 경우는 폐기된 전자문서의 원본을 포함한 DIP에 대한 정보를 포함하며, 실패인 경우는 실패의 사유를 포함한다. 처리 결과가 성공인 경우에 포함되는 DIP는 응답 메시지의 내에 첨부될 수도 있고, 응답 메시지의 외부에 파일 형태로 첨부될 수도 있으며, DIP가 응답 메시지 외부에 첨부되는 방식이나 구조는 전자문서 보관소 서버(130)의 구현 방식을 따른다. 응답 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명은 표 28 ~ 표 29에 제시한다.

⑦ 문서 보관연장(ExtendRetention)

전자문서 보관소 서버(130)에 보관 중인 전자문서의 보관 기간을 연장 요청할 때 이용하는 전자문서 보관 연장 서비스에 대한 요청 및 응답 메시지를 정의한다. 본 기능은 이용자가 전자문서 보관 기간을 연장하겠다는 의사를 전자문서 보관소 서버(130)에 전달하여 전자문서 보관소 서버(130)가 가능 여부에 대한 응답을 주는 프로세스만을 정의하며, 운영상의 구체적인 절차는 여기서는 다루지 않는다. 문서 보관 연장 기능에 대한 구현은 전자문서 보관소 서버(130)의 정책상 선택적으로 구현 가능한 기능이다.

전자문서 보관 연장 요청 메시지(ExtendRetentionRequest)는 대상 전자문서의 AIP 패키지 식별자와 연장 기간을 포함한다. 이용자가 전자문서 보관 연장 요청을 하기 위해서는 미리 AIP 패키지 식별자를 검색하여 요청 메시지에 해당 식별자를 설정하여야 한다. 요청 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명은 표 30 ~ 표 31에 제시한다.

전자문서 보관 연장 응답 메시지(ExtendRetentionResponse)는 이용자의 보관 기간 연장 요청에 대한 전자문서 보관소 서버(130)의 연장 가능 여부의 확인 결과가 포함된다. 응답 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명은 표 32 ~ 표 33에 제시한다.

⑧ 증명서 발급(IssueCert)

전자문서 보관소 서버(130)가 수행한 전자문서 등록, 전자문서 발급, 전자문서 이관, 전자문서 폐기 서비스를 수행한 사실을 증명하는 제증명서 및 시점확인 증명서를 발급받기 위하여 이용하는 증명서 발급 서비스에 대한 요청 및 응답 메시지를 정의한다. 이용자는 전자문서 보관소 서버(130)가 수행한 각 서비스에 대한 증명서를 발급해줄 것을 요청할 수 있고, 전자문서 보관소 서버(130)는 이에 대한 응답으로 증명서를 발급한다.

증명서 발급 요청 메시지(IssueCertRequest)는 복수개의 IssueCertRequestData를 식별하기 위한 식별자와 증명요청서에 대한 정보를 포함한다. IssueCertRequestData의 식별자로서, 시점확인 증명서 이외의 증명서를 발급받고자 하는 경우는 증명서 발급대상 증적의 식별자를 사용하도록 하고, 시점확인 증명서를 발급받고자 하는 경우는 복수개의 IssueCertRequestData를 식별할 수 있는 유일한 식별자를 생성하여 사용하도록 한다. 증명서 요청자가 개인이라면 증명요청서의 증명서 요청자 정보를 생성할 때 사용한 난수값을 증명요청서와 함께 전자문서 보관소 서버(130)에 전달해야 한다.

이용자가 시점확인 증명서 이외의 등록증명서, 발급증명서, 이관증명서, 폐기증명서를 발급받고자 한다면 증명서 발급대상 증적의 식별자를 포함한 증명요청서를 생성하기 위하여 미리 대상 증적의 식별자(serialNo)를 검색하여야 한다. 증명요청서는 요청 메시지의 내에 첨부될 수도 있고, 요청 메시지의 외부에 파일 형태로 첨부될 수도 있으며, 증명요청서가 요청 메시지 외부에 첨부되는 방식이나 구조는 전자문서 보관소 서버(130)의 구현 방식을 따른다. 요청 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명은 표 34 ~ 표 35에 제시한다.

증명서 발급 요청에 대한 응답 메시지(IssueCertResponse)는 해당 증적에 대한 증명서 발급 작업의 처리 결과가 성공인 경우는 증명서에 대한 정보를 포함하며, 실패인 경우는 실패의 사유를 포함한다. 처리 결과가 성공인 경우에 포함되는 증명서는 응답 메시지의 내에 첨부될 수도 있고, 응답 메시지의 외부에 파일 형태로 첨부될 수도 있으며, 증명서가 응답 메시지 외부에 첨부되는 방식이나 구조는 전자문서 보관소 서버(130)의 구현 방식을 따른다. 응답 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명은 표 36 ~ 표 37에 제시한다.

⑨ 증명서 갱신발급(UpdateCert)

발급된 증명서가 효력 만기일 내에 있으나, 증명서에 서명한 전자문서 보관소 서버(130) 인증서의 유효기간이 곧 만료되거나 이미 만료되어 더이상 증명서의 유효성을 보증하지 못하는 경우에 이용자는 증명서의 갱신을 전자문서 보관소 서버(130)에 요청할 수 있고, 전자문서 보관소 서버(130)는 이에 대하여 갱신된 전자문서 보관소 서버(130)의 인증서를 사용하여 증명서를 갱신 발급하여야 한다. 갱신된 증명서의 내용은 갱신전 증명서의 내용과 동일하며, 다만 증명서의 이전 서명 정보를 갱신된 전자문서 보관소 서버(130)의 인증서를 사용하여 생성된 새로운 서명으로 교체하여 발급하도록 한다.

증명서 갱신발급은 새로운 증명서를 발급받는 것이 아니라 증명서의 서명 정보만을 교체하는 것이므로 요청 메시지에 증적이나 증명요청서가 포함되는 대신 갱신발급 대상인 증명서의 정보가 포함된다. 증명서는 요청 메시지(UpdateCertRequest)의 내에 첨부될 수도 있고, 요청 메시지의 외부에 파일 형태로 첨부될 수도 있으며, 증명서가 요청 메시지 외부에 첨부되는 방식이나 구조는 전자문서 보관소 서버(130)의 구현 방식을 따른다. 요청 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명은 표 38 ~ 표 39에 제시한다.

전자문서 보관소 서버(130)는 이용자가 제출한 증명서에 대하여 전자문서 보관소 서버(130)가 발급한 증명서인가의 여부를 포함한 확인과정을 수행한 후, 증명서의 서명을 교체하여 이용자에게 전송한다. 처리 결과가 성공인 경우에 포함되는 증명서는 응답 메시지(UpdateCertResponse)의 내에 첨부될 수도 있고, 응답 메시지의 외부에 파일 형태로 첨부될 수도 있으며, 증명서가 응답 메시지 외부에 첨부되는 방식이나 구조는 전자문서 보관소 서버(130)의 구현 방식을 따른다. 응답 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명은 표 40 ~ 표 41에 제시한다.

⑩ 증명서 검증(VerifyCert)

이용자가 전자문서 보관소 서버(130)에 증명서의 폐지 여부에 대한 검증을 요청할 때 이용하는 증명서 검증 서비스에 대한 요청 및 응답 메시지를 정의한다. 전자문서 보관소 서버(130)는 검증 대상 증명서에 대하여 폐지 여부를 확인한 후 이용자에게 검증 결과를 전송해야 한다.

증명서 검증 요청 메시지(VerifyCertRequest)는 대상 증명서에 대한 정보와 증명서 발급시 증명서 요청자 개인인 경우에 생성하여 전자문서 보관소 서버(130)가 보관중인 난수값에 대한 요청 여부를 포함한다. 난수값은 증명서 검증 과정 중에 증명서 요청자에 대한 검증을 수행할 경우에만 요청하도록 한다. 증명서는 요청 메시지의 내에 첨부될 수도 있고, 요청 메시지의 외부에 파일 형태로 첨부될 수도 있으며, 증명서가 요청 메시지 외부에 첨부되는 방식이나 구조는 전자문서 보관소 서버(130)의 구현 방식을 따른다. 요청 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명은 표 42 ~ 표 43에 제시한다.

증명서 검증 요청에 대한 응답 메시지(VerifyCertResponse)에는 해당 증명서의 폐지 여부에 대한 검증 작업의 결과가 포함된다. 유효한 증명서인 경우는 요청 메시지에서 난수값을 요청한 경우는 난수값이 포함되며, 요청하지 않은 경우는 Null값이 포함된다. 그리고, 폐지된 증명서이거나 유효하지 않은 증명서인 경우는 해당 사유를 응답 메시지에 포함한다. 응답 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명은 표 44 ~ 표 45에 제시한다.

⑪ 증명서 다운로드(GetCert)

전자문서 보관소 서버(130)가 이미 발급한 증명서에 대하여 이용자가 다운로드를 요청할 때 이용하는 증명서 다운로드 서비스에 대한 요청 및 응답 메시지를 정의한다. 유효기간 만료전인 증명서를 분실한 경우나 기타 사유에 의해서 과거에 발급된 증명서를 다운로드할 필요가 있을 때, 이용자는 전자문서 보관소 서버(130)에 기발급된 증명서를 요청할 수 있고, 전자문서 보관소 서버(130)는 해당 증명서를 검색하여 이용자에게 전송한다.

증명서 다운로드 요청 메시지(GetCertRequest)는 다운로드하고자 하는 증명서의 식별자를 포함한다. 이용자가 증명서 다운로드 요청을 하기 위해서는 미리 증명서의 식별자를 검색하여 요청 메시지에 해당 식별자를 설정하여야 한다. 요청 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명은 표 46 ~ 표 47에 제시한다.

증명서 다운로드 요청에 대한 응답 메시지(GetCertResponse)는 해당 증명서에 대한 검색 작업 등의 처리 결과가 성공인 경우는 증명서에 대한 정보를 포함하며, 실패인 경우는 실패의 사유를 포함한다. 처리 결과가 성공인 경우에 포함되는 증명서는 응답 메시지의 내에 첨부될 수도 있고, 응답 메시지의 외부에 파일 형태로 첨부될 수도 있으며, 증명서가 응답 메시지 외부에 첨부되는 방식이나 구조는 전자문서 보관소 서버(130)의 구현 방식을 따른다. 응답 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명은 표 48 ~ 표 49에 제시한다.

⑫ 검색(Search)

이용자가 전자문서 보관소 서버(130) 내의 전자문서, 증적 데이터, 증명서 등을 검색할 때 이용하는 검색 서비스에 대한 요청 및 응답 메시지를 정의한다. 이용자는 전자문서 발급, 전자문서 이관, 전자문서 폐기, 증명서 발급, 증명서 다운로드 등의 서비스를 요청하기 전에 대상 전자문서의 식별자, 대상 증적의 식별자, 대상 증명서의 식별자 등을 검색하여야 하며, 이외에도 이용자가 전자문서 보관소 서버(130) 내의 기타 데이터에 대한 검색 및 조회 서비스를 요청할 필요가 있을 경우 본 검색 요청 및 응답 메시지 구조를 사용하도록 한다.

검색 요청 메시지(SearchRequest)는 다른 요청 메시지와는 달리 단일 요청만 가능하며, 따라서 RequestHeader의 TotalCount 필드의 값은 반드시 1로 고정되어야 하고 결과적으로 RequestDataList 필드 내의 SearchRequestData 필드의 개수는 1개가 되어야 한다. SearchRequestData 필드에는 검색에 필요한 데이터로 구성된 QueryContent가 포함되는데, 각 전자문서 보관소 서버(130)의 시스템 환경이나 검색 대상, 검색 조건에 따라 자체 구현이 가능하도록 QueryContent의 구조나 형식을 제한하지 않는다. 요청 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명은 표 50 ~ 표 51에 제시한다.

검색 응답 메시지(SearchResponse)에서도 ResponseHeader의 TotalCount 필드의 값은 반드시 1로 고정되어야 하고, 결과적으로 ResponseDataList 필드 내의 SearchResponseData 필드의 개수는 1개가 되어야 한다. 또한, 다른 응답 메시지가 개별 요청(RequestData)에 대한 성공/실패 여부 및 실패시의 오류 메시지를 개별 응답(ResponseData)에 포함한 것과는 달리 검색 응답 메시지(SearchResponseData)에서는 개별 응답에 처리 결과 및 실패시의 오류 메시지를 포함하지 않는다. 대신, 검색의 결과로서 여러 개의 레코드가 리턴될 수 있으므로 레코드의 개수와 레코드 리스트를 포함한다. 검색 요청 메시지에서와 마찬가지로 QueryResult의 구조나 형식을 제한하지 않으므로 각 전자문서 보관소 서버(130)가 QueryResult의 구조나 형식을 자체 구현하여 사용할 수 있다. 응답 메시지를 형성하는 메시지의 구조, 메시지 구조에 분포하는 각 필드에 대한 설명은 표 52 ~ 표 53에 제시한다.

다음으로, 도 4 series를 참조하여 요청 메시지와 응답 메시지의 전체 패키징 구조를 설명한다. 먼저, 요청 메시지의 패키징 구조를 설명하고, 다음으로, 응답 메시지의 패키징 구조를 설명한다.

도 4a를 참조하면, 요청 메시지의 기본 구조는 HTTP 프로토콜과 SOAP 프로토콜 사이에 Multi-MIME 형식이 삽입되어 있는 구조이며, 실제로 SOAP 구조는 Multi-MIME의 첫번째 MIME에 위치하고 첨부파일들이 두번째 MIME부터 반복적으로 추가된다. 구체적인 특징은 다음과 같다. 첫째, 메시지의 기본 패키징은 Multi-MIME으로 구성된다. 둘째, 요청 메시지와 응답 메시지의 내용은 SOAP 메시지 구조에 적용되어 첫번째 MIME에 포함된다. 세째, 요청 메시지와 응답 메시지에서 언급된 첨부파일(문서 패키지, 증명서, 인증서 등)은 두번째 이후 MIME으로 추가된다. 네째, 각 연계 인터페이스별 요청 메시지 및 전달 문서의 구조는 도 5 series를 참조하여 설명하는 연계 인터페이스의 유형에 따른 요청 메시지의 스키마 구조 설정을 참조하면 된다.

SOAP Header는 WS-Security V1.1 규약에서 정의하는 <Security> 항목과 전자문서 보관소 서버(130)에서 추가적으로 정의하는 <MessageHdeader> 항목으로 구성된다. 전체 구조는 도 4b와 같다. Security 구조는 후술하는 전송보안을 참조하면 되므로 여기서는 생략하며, 이후 MessageHeader 구조에 대해 설명한다.

MessageHeader 구조에 있어서, 표준 메시지 구조의 MessageHeader 부분은 그대로 SOAP Header의 MessageHeader 부분에 적용되어 사용된다. MessageHeader의 스키마 구조는 도 4c에 도시된 바와 같으며, 그 항목 설명은 다음을 참고한다.

- Version: 1..1: 연계 인터페이스 메시지 스키마의 버전으로서, 본 발명을 준용한 연계 인터페이스 메시지는 "1.1"로 설정해야 한다.

- OperationType: 1..1: 요청의 유형에 대한 구분값이 들어간다. 예를 들어, 문서 보관인지 검색 요청인지 이용자 인증 요청인지에 따라 고유의 값이 들어간다. 고유값에 따른 서비스는 표 60과 같다.

- MessageType: 1..1: 전송하는 메시지가 요청(Request)인지, 응답(Response)인지에 따라 이를 구분하기 위한 값이 들어간다. 자세한 내용은 표 61에 도시된 바와 같다.

- MessageId: 1..1: 메시지에 대한 Unique ID

- TimeStamp: 1..1: 메시지 전송된 GMT 시각으로서 "yyyymmddhhmiss" +"Z" 형태로 기술.

- EndPointforResponse: 0..1: 응답 메시지가 비동기식인 경우 전자문서 보관소 서버(130)가 전송하는 응답 메시지를 받을 수 있는 e-mail 주소를 설정하도록 하며, 사용하지 않은 경우는 이용자의 등록 정보에 등록된 e-mail로 전송하여 확인할 수 있도록 한다.

SOAP Body는 표준 메시지 구조의 MessageBody 부분을 포함하는 구조로 되어 있으며, SOAP 표준 구조에서는 요청 메시지인 경우는 RequestMessage 구조가, 응답 메시지의 경우는 ResponseMessage 구조가 MessageBody에 해당되어 SOAP Body 내에 포함된다. 전체 구조는 도 4d와 같다.

ⓐ 요청 메시지(RequestMessage)의 구조

모든 요청 메시지는 아래의 요청 메시지 기반구조를 확장하는 형태로 정의된다. 요청 메시지의 기반구조는 RequestHeader와 RequestBody로 구분되며, RequestBody에 각각의 서비스 유형에 따른 메시지 구조가 중복적으로 포함될 수 있는 RequestDataList가 포함된다. 또한, RequestBody에는 추가로 SlotList를 포함할 수 있도록 정의함으로써 규격의 변경시 유연하게 확장될 수 있도록 하였으나, 본 발명을 준용하여 구현된 전자문서 보관소 서버(130)와 이용자 서버(120)에서는 별도의 확장요소를 정의하여 사용하지 않도록 한다. 요청 메시지의 스키마 구조는 도 4e에 도시된 바와 같으며, 그 항목 설명은 다음을 참고한다.

- RequestHeader: 1..1: 요청 메시지의 공통항목을 기술하고 있는 영역.

- TotalCount: nonNegativeInteger: 1..1: 요청하는 데이터의 전체 건수. 문서등록, 문서발급 등의 요청시 동시에 여러 건의 데이터를 요청하는 경우 요청건수를 기술함. 문서검색 등과 같이 요청하는 내용이 하나인 경우에는 그 값을 반드시 1로 설정함.

- RequestBody: 1..1: 각 유형별 연계 인터페이스에 따라 요청 메시지가 수록되는 영역으로 필수항목인 RequestDataList를 포함하며, 선택항목인 SlotList가 포함될 수 있는 구조임.

- RequestDataList: 1..1: 아래와 같은 요청메시지가 올 수 있음. 각 요청메시지의 상세 구조는 각 유형별 연계 인터페이스의 요청메시지 구조를 참조바람.

- SubmitDocumentRequestData: 1..∞: 문서등록 요청메시지

- GetDocumentRequestData: 1..∞: 문서발급 요청메시지

- DeliverDocumentRequestData: 1..∞: 문서3자발급 요청메시지

- GetDocumentbyCertRequestData: 1..∞: 증명서를 사용한 문서발급 요청메시지

- TransferDocumentRequestData: 1..∞: 문서이관 요청메시지

- DeleteDocumentRequestData: 1..∞: 문서폐기 요청메시지

- ExtendRetentionRequestData: 1..∞: 문서보관연장 요청메시지

- IssueCertRequestData: 1..∞: 증명서발급 요청메시지

- UpdateCertRequestData: 1..∞: 증명서갱신발급 요청메시지

- VerifyCertRequestData: 1..∞: 증명서검증 요청메시지

- GetCertRequestData: 1..∞: 증명서 다운로드 요청메시지

- SearchRequestData: 1..1: 검색 요청메시지

- SlotList: : 0..1: 규격의 업데이트시, 요청메시지에 추가할 내용이 있는 경우 스키마를 바꾸지 않고 필요한 항목을 추가하기 위한 구조를 제공함.

- Slot: 1..∞: 추가할 항목을 기술할 수 있는 구조이며 Slot의 구조는 미정임.

ⓑ 응답 메시지(ResponseMessage)의 구조

모든 응답 메시지는 아래의 응답 메시지 기반구조를 확장하는 형태로 정의된다. 응답 메시지의 기반구조는 ResponseHeader와 ResponseBody로 구분되며, ResponseBody에 각각의 서비스 유형에 따른 메시지 구조가 중복적으로 포함될 수 있는 ResponseDataList나 실패의 원인을 담은 FailReason이 포함된다. 또한, ResponseBody에는 추가로 SlotList를 포함할 수 있도록 정의함으로써 규격의 변경시 유연하게 확장될 수 있도록 하였으나, 본 발명을 준용하여 구현된 전자문서 보관소 서버(130)와 이용자 서버(120)에서는 별도의 확장요소를 정의하여 사용하지 않도록 한다. 응답 메시지의 스키마 구조는 도 4f에 도시된 바와 같으며, 그 항목 설명은 다음을 참고한다.

- ResponseHeader: 1..1: 응답메시지의 공통항목을 기술하고 있는 영역.

- TotalResultCode: string: 1..1: 서비스 처리 결과에 따라 성공("1"), 실패("2") 여부를 기록

- TotalCount: nonNegativeInteger: 1..1: 응답하는 데이터의 전체 건수이며 요청메시지의 전체 건수와 동일하여야 함.

- SuccessCount: nonNegativeInteger: 1..1: 전체 데이터 건수 중에서 성공한 데이터의 건수임.

- FailCount: nonNegativeInteger: 1..1: 전체 데이터 건수 중에서 실패한 데이터의 건수임.

- ResponseBody: 1..1: 각 유형별 연계 인터페이스에 따라 응답메시지가 수록되는 영역으로 ResponseDataList 또는 FailReason이 반드시 포함되며, 선택항목인 SlotList가 포함될 수 있는 구조임.

- ResponseDataList: 1..1: 아래와 같은 요청메시지가 올 수 있음. 각 요청메시지의 상세 구조는 각 연계인터페이스의 요청메시지 구조를 참조바람.

- SubmitDocumentResponseData: 1..∞: 문서등록 응답메시지

- GetDocumentResponseData: 1..∞: 문서발급 응답메시지

- DeliverDocumentResponseData: 1..∞: 문서3자발급 응답메시지

- GetDocumentbyCertResponseData: 1..∞: 증명서를 사용한 문서발급 응답메시지

- TransferDocumentResponseData: 1..∞: 문서이관 응답메시지

- DeleteDocumentResponseData: 1..∞: 문서폐기 응답메시지

- ExtendRetentionResponseData: 1..∞: 문서보관연장 응답메시지

- IssueCertResponseData: 1..∞: 증명서발급 응답메시지

- UpdateCertResponseData: 1..∞: 증명서갱신발급 응답메시지

- VerifyCertResponseData: 1..∞: 증명서검증 응답메시지

- GetCertResponseData: 1..∞: 증명서 다운로드 응답메시지

- SearchResponseData: 1..1: 검색 응답메시지

- FailReason string: 1..1: 서비스 요청에 대한 처리 결과인 TotalResultCode가 'false'인 경우, ResponseDataList 대신 FailReason이 ResponseBody에 포함되며, 실패의 원인이 기술됨.

- SlotList: : 0..1: 규격의 업데이트시, 응답메시지에 추가할 내용이 있는 경우 스키마를 바꾸지 않고 필요한 항목을 추가하기 위한 구조를 제공함.

다음으로, 연계 인터페이스의 유형에 따른 요청 메시지의 스키마 구조 설정을 설명한다. 요청 메시지의 스키마 구조는 제시하는 기본 구조가 변형되지 않는한 다양한 확장이 가능하다.

① 전자문서 등록(SubmitDocument)

전자문서 등록요청시의 요청 메시지(SubmitDocumentRequestData)의 처리절차와 스키마 구조는 각각 도 5a, 도 5b와 같으며, 전달인자 각각에 대한 설명은 다음과 같다.

- SipId: string: 1..1: 첨부된 SIP의 식별자 값을 사용

- SipInfo: string: 1..1: Multi-MIME 형식으로 첨부된 SIP의 위치정보를 기술(MIME으로 패키징된 SOAP 연계 인터페이스에서는 첨부된 SIP파일의 c-id 값을 사용)

- SipHashAlgorithm: string: 1..1: 첨부된 SIP 패키지 파일의 무결성을 확인하기 위하여 사용한 Hash 알고리즘

- SipHashValue: base64Binary: 1..1: 첨부된 SIP 패키지 파일을 Hash한 값

② 전자문서 발급(GetDocument)

이용자가 전자문서 보관소 서버(130)에 보관된 전자문서를 발급받고자 하는 경우, 전자문서 보관소 서버(130)는 요청된 전자문서에 대한 이용자의 접근권한을 확인한 후 권한이 있는 경우에 한해 해당하는 전자문서를 DIP 형태로 패키징하여 전달한다. 이용자가 자신을 포함하여 특정인만 전자문서를 열람할 수 있도록 전자문서 보관소 서버(130)에 문서 암호화를 요청할 수 있으며, 이 경우 전자문서 암호화를 위해서는 자신의 인증서 및 특정인의 인증서를 보내게 된다. 그러면, 전자문서 보관소 서버(130)는 이용자들의 인증서로 전자문서를 암호화한 DIP를 생성하여 이용자에게 전송하게 된다.

전자문서 발급요청시의 요청 메시지(GetDocumentRequestData)의 처리절차와 스키마 구조는 각각 도 5c, 도 5d와 같으며, 전달인자 각각에 대한 설명은 다음과 같다.

- AipId: string: 1..1: 발급 요청하는 AIP의 식별자 값을 사용

- DocumentId: string: 1..1: 발급 요청하는 AIP 내의 문서 식별자 값을 사용

- FileIdList: : 0..1: 전자문서 내의 첨부파일 식별자 리스트로서, 전자문서 내의 모든 첨부파일을 발급받고자 한다면 본 요소 생략

- [속성]fileIdCount: nonNegativeInteger: 필수: FileId의 개수

- FileId: string: 1..∞: 전자문서 내의 첨부파일 식별자

- Encryption: string: 1..1: AIP 내의 전자문서 파일의 암호화 여부로서 평문("0") 또는 암호화("1")를 나타냄

- UserPubKeyCertList: 1..1: 암호화된 문서를 이용할 이용자들의 인증서 리스트

- [속성]userPubKeyCertCount: nonNegativeInteger: 필수: UserPubKeyCert의 개수

- PubKeyCert: 1..∞: 이용자 인증서 정보

- PubKeyCertnfo: string: 1..1: 이용자 인증서의 위치 정보를 기술(MIME으로 패키징된 SOAP 연계 인터페이스에서는 첨부파일의 c-id 값을 사용)

- PubKeyCertHashAlgorithm: string: 1..1: 첨부된 인증서 파일의 무결성을 확인하기 위하여 사용한 Hash 알고리즘

- PubKeyCertHashValue: base64Binary: 1..1: 첨부된 인증서 파일을 Hash한 값

③ 전자문서 제3자 발급(DeliverDocument)

문서발급에 대한 적합한 권한이 있는 전자문서 보관소 서버(130) 이용자(전자문서 보관소 서버(130)에 등록된 이용자)가 문서를 제3자에게 발급을 요청하기 위한 구조로서, 문서발급의 행위는 요청과 비동기적으로 수행되므로 응답 메시지에는 요청 메시지에 대한 수신 확인의 결과만을 포함하여 리턴하고, 실제 문서발급의 처리결과는 발급작업 완료이후 요청자의 E-mail로 전송하도록 한다. 문서의 수신자는 요청자 본인이어도 무방하며, 문서는 요청 메시지의 전달인자 중의 하나인 수신자의 E-mail로 직접 전송되거나 이용자와 사전에 협의된 방식으로 수신자에게 전달된다. 문서가 수신자의 E-mail로 직접 전달될 때는 문서 내용의 기밀성을 보장하기 위하여 수신자의 인증서 공개키로 암호화되어 전송하도록 하고, 이용자와 사전에 협의된 방식으로 수신자에게 전달되는 경우는 비동기식 처리시에 고려하여야 하는 전송보안의 내용을 준용하도록 한다. 전송보안에 대해서는 제2 보안 처리부(265) 기능 수행시 설명할 것이므로 여기서는 생략한다. 문서 제3자 발급 기능에 대한 구현은 전자문서 보관소 서버(130)의 정책상 선택적으로 구현될 수 있는 기능이다.

전자문서 제3자 발급요청시의 요청 메시지(DeliverDocumentRequestData)의 처리절차와 스키마 구조는 각각 도 5e, 도 5f와 같으며, 전달인자 각각에 대한 설명은 다음과 같다.

- AipId: string: 1..1: 발급 요청하는 AIP의 식별자 값을 사용

- [속성]fileIdCount: nonNegativeInteger: 필수: FileId의 개수

- FileId: string: 1..∞: 전자문서 내의 첨부파일 식별자

- ReceiverList: 1..1: 수신자 리스트

- [속성]receiverCount: nonNegativeInteger: 필수: Receiver의 개수

- Receiver: 1..∞: 수신자의 E-mail과 인증서 정보를 포함

- EMail: string: 1..1: 문서 또는 문서전달과 관련된 통지 메시지가 전송될 수신자의 EMail

- PubKeyCertnfo: string: 1..1: 수신자 인증서의 위치정보를 기술(MIME으로 패키징된 SOAP 연계 인터페이스에서는 첨부파일의 c-id 값을 사용)

④ 증명서를 사용한 전자문서 발급(GetDocumentByCert)

문서발급 권한을 일시적으로 부여하는 등록 증명서를 바탕으로 문서발급을 요청하는 경우로서, 요청자는 반드시 등록 증명서의 수임자 필드에 본인의 정보가 포함되어 있어야 한다. 또한, 요청자는 수임자가 본인임을 증명하기 위하여 자신의 인증서 및 전자서명을 등록 증명서와 함께 전송해야 하는데, 본 SOAP을 사용한 규격에서는 SOAP Header의 Security 항목에 포함된 요청자의 인증서 및 서명을 사용하도록 한다. 발급받고자 하는 AIP(Archival Information Package) 패키지의 식별자는 등록 증명서에 포함되어 있으므로 별도로 설정할 필요가 없으며, 패키지 내 전자문서의 식별자 또한 증명서를 사용하여 전자문서를 발급하는 경우에는 반드시 장기보존본 전자문서를 포함한 DIP를 발급하여야 하므로 설정할 필요가 없다. 요청자의 한글실명 및 식별번호는 등록 증명서의 수임자 필드에 한글실명 및 식별번호가 사용되었을 때만 전달하는 전달인자이다. 증명서를 사용한 문서발급 기능에 대한 구현은 전자문서 보관소 서버(130)의 정책상 선택적으로 구현될 수 있는 기능이다.

한편, 상기에서 AIP는 보존 정보 패키지를 말하며, 전자문서 보관소 서버(130)가 전자문서를 보관할 때 구성하는 구조로 이용된다. 즉, 본 발명의 실시예에서 보관소 엔진 모듈(250)은 이용자 서버(120)에서 전달된 SIP를 AIP로 변환시켜 전자문서 보관소 데이터베이스(132)에 저장시키게 된다.

증명서를 사용한 전자문서 발급요청시의 요청 메시지(GetDocumentByCertRequestData)의 처리절차와 스키마 구조는 각각 도 5g, 도 5h와 같으며, 전달인자 각각에 대한 설명은 다음과 같다.

- CertId: string: 1..1: 수임자 정보가 포함된 등록 증명서 식별자 값을 사용

- Certnfo: string: 1..1: 등록 증명서의 위치정보를 기술(MIME으로 패키징된 SOAP 연계 인터페이스에서는 첨부파일의 c-id 값을 사용)

- CertHashAlgorithm: string: 1..1: 첨부된 등록 증명서 파일의 무결성을 확인하기 위하여 사용한 Hash 알고리즘

- CertHashValue: base64Binary: 1..1: 첨부된 증명서 파일을 Hash한 값

- RealName: string: 0..1: 요청자의 한글실명으로서 등록 증명서의 수임자 정보에 한글실명이 포함되어 있을 경우 첨부함

- Idn: string: 0..1: 요청자의 식별번호로서 등록 증명서의 수임자 정보에 식별번호가 포함되어 있을 경우 첨부함

⑤ 전자문서 이관(TransferDocument)

전자문서 이관에 대한 적합한 권한이 있는 전자문서 보관소 서버(130) 이용자(전자문서 보관소 서버(130)에 등록된 이용자)가 문서를 다른 전자문서 보관소 서버(130)에 이관해줄 것을 요청하기 위한 구조로서, 문서이관의 행위는 요청과 비동기적으로 수행되므로 응답 메시지에는 요청 메시지에 대한 수신확인의 결과만을 포함하여 리턴하고, 실제 문서이관의 처리결과는 이관작업 완료이후 요청자의 E-mail로 전송하도록 한다.

전자문서 이관요청시의 요청 메시지(TransferDocumentRequestData)의 처리절차와 스키마 구조는 각각 도 5i, 도 5j와 같으며, 전달인자 각각에 대한 설명은 다음과 같다.

- AipId: string: 1..1: 이관 요청하는 AIP의 식별자 값을 사용

- ImportArc: string: 1..1: 수관 전자문서 보관소 서버(130)의 식별자 값을 사용

⑥ 전자문서 폐기(DeleteDocument)

전자문서 보관소 서버(130)에 보관중인 전자문서의 폐기를 요청하기 위한 구조로서, 전자문서 폐기 요청시 이용자는 전자문서 폐기와 함께 전자문서 원본을 발급해줄 것을 요청할 수 있고, 이 경우에 전자문서 보관소 서버(130)는 폐기 요청에 대한 응답 메시지에 전자문서 원본을 포함한 DIP를 생성한 후 포함하여 이용자에게 전송하여야 한다.

전자문서 폐기요청시의 요청 메시지(DeleteDocumentRequestData)의 처리절차와 스키마 구조는 각각 도 5k, 도 5l과 같으며, 전달인자 각각에 대한 설명은 다음과 같다.

- AipId: string: 1..1: 폐기 요청하는 AIP의 식별자 값을 사용

- IssueOrgDocument: string: 1..1: 폐기 후, 원본 전자문서의 발급여부. 발급("0"), 발급하지 않음("1")의 값을 가짐

⑦ 전자문서 보관연장(ExtendRetention)

전자문서 보관소 서버(130)에 보관중인 전자문서의 보관기간 만료시에 이용자가 전자문서 보관소 서버(130)에 보관기간을 연장해줄 것을 요청하기 위한 구조로서, 요청 메시지에는 보관기간을 연장하고자 하는 AIP 식별자와 연장기간에 대한 인자가 포함되며, 응답 메시지에는 연장 가능여부에 대한 전자문서 보관소 서버(130)의 확인결과가 포함된다. 전자문서 보관연장 기능에 대한 구현은 전자문서 보관소 서버(130)의 정책상 선택적으로 구현 가능한 기능이다.

전자문서 보관연장 요청시의 요청 메시지(ExtendRetentionRequestData)의 처리절차와 스키마 구조는 각각 도 5m, 도 5n과 같으며, 전달인자 각각에 대한 설명은 다음과 같다.

- AipId: string: 1..1: 이관 요청하는 AIP의 식별자 값을 사용

- RetentionExpiredDate: string: 1..1: 연장하고자 하는 보관 만료일(GMT)로서 "yyyymmddhhmiss" +"Z"로 표현

⑧ 증명서 발급(IssueCert)

전자문서 보관소 서버(130)가 수행한 전자문서 등록, 전자문서 발급, 전자문서 이관, 전자문서 폐기 서비스를 수행한 사실을 증명하는 제증명서를 발급받기 위하여 이용하는 증명서 발급 서비스에 대한 구조이다. 증명서 발급 요청 메시지에는 대상 증적의 식별자와 증명 요청서, 그리고 증명서 요청자가 개인인 경우 난수값을 포함하며, 응답 메시지에는 발급된 증명서가 포함된다. 한편, 본 증명서 발급 서비스를 수행하기 전에 이용자는 미리 증명서 발급대상 증적을 검색하여 증명 요청서를 생성하게 된다. 증적의 검색은 검색 인터페이스를 사용하여 수행하도록 한다.

전자문서 증명서 발급요청시의 요청 메시지(IssueCertRequestData)의 처리절차와 스키마 구조는 각각 도 5o, 도 5p와 같으며, 전달인자 각각에 대한 설명은 다음과 같다.

- TargetRecordId: string: 1..1: 시점확인 증명서 이외의 증명서 발급요청인 경우는 증명 요청서의 targetRecord 필드의 serialNo 필드의 값을 string으로 변환시킨 값이며 시점확인 증명서의 경우는 IssueCertRequestData를 식별할 수 있는 유일한 값

- CertRequestInfo: string: 1..1: Multi-MIME 형식으로 첨부된 증명 요청서의 위치정보를 기술(MIME으로 패키징된 SOAP 연계 인터페이스에서는 첨부파일의 c-id 값을 사용)

- CertRequestHashAlgorithm: string: 1..1: 첨부된 증명 요청서 파일의 무결성을 확인하기 위하여 사용한 Hash 알고리즘

- CertRequestHashValue: base64Binary: 1..1: 첨부된 증명 요청서 파일을 Hash한 값

- RandomNumber: base64Binary: 0..1: 증명서 요청자가 개인인 경우, 증명 요청서의 요청자 정보를 생성할 때 사용한 160 비트의 난수값

⑨ 증명서 갱신발급(UpdateCert)

발급된 증명서가 효력 만기일 내에 있으나, 증명서에 서명한 전자문서 보관소 서버(130) 인증서의 유효기간이 곧 만료되거나 이미 만료되어 더이상 증명서의 유효성을 보증하지 못하는 경우에, 이용자는 증명서의 갱신을 전자문서 보관소 서버(130)에 요청할 수 있고, 전자문서 보관소 서버(130)는 이에 대하여 갱신된 전자문서 보관소 서버(130)의 인증서를 사용하여 증명서를 갱신발급하여야 한다. 갱신된 증명서의 내용은 갱신전 증명서의 내용과 동일하며, 다만 증명서의 이전 서명정보를, 갱신된 전자문서 보관소 서버(130)의 인증서를 사용하여 생성된 새로운 서명으로 교체하여 발급하도록 한다. 갱신발급 요청 메시지에는 갱신발급 대상 증명서의 정보가 포함되고, 응답 메시지에는 갱신 발급된 증명서의 정보가 포함된다.

전자문서 증명서 갱신발급 요청시의 요청 메시지(UpdateCertRequestData)의 처리절차와 스키마 구조는 각각 도 5q, 도 5r과 같으며, 전달인자 각각에 대한 설명은 다음과 같다.

- CertId: string: 1..1: 갱신발급 대상 증명서의 SerialNumber 필드의 값을 string으로 변환한 값

- CertInfo: string: 1..1: Multi-MIME 형식으로 첨부된 증명서의 위치정보를 기술(MIME으로 패키징된 SOAP 연계 인터페이스에서는 첨부파일의 c-id 값을 사용)

- CertHashAlgorithm: string: 1..1: 첨부된 증명서 파일의 무결성을 확인하기 위하여 사용한 Hash 알고리즘

- CertHashValue: base64Binary: 1..1: 첨부된 증명서 파일을 Hash한 값

⑩ 증명서 검증(VerifyCert)

이용자가 증명서의 폐지여부에 대한 검증을 전자문서 보관소 서버(130)에 요청하기 위한 메시지 구조이다. 이용자는 검증대상 증명서와 함께 전자문서 보관소 서버(130)에 보관중인 증명서 요청자가 생성한 난수값을 요청할 수 있다. 난수값은 증명서 검증과정 중에 증명서 요청자에 대한 검증을 수행할 경우에만 요청하도록 한다.

전자문서 증명서 검증요청시의 요청 메시지(VerifyCertRequestData)의 처리절차와 스키마 구조는 각각 도 5s, 도 5t와 같으며, 전달인자 각각에 대한 설명은 다음과 같다.

- CertId: string: 1..1: 검증대상 증명서의 SerialNumber 필드의 값을 string으로 변환한 값

- CertHashValue: base64Binary: 1..1: 첨부된 증명서 파일을 Hash한 값

- GetRandomNumber: string: 1..1: 난수값의 요청여부를 기록. 요청("1"), 요청하지 않음("2")

⑪ 증명서 다운로드(GetCert)

증명서 분실 등의 사유로 과거에 발급된 증명서를 다운로드할 필요가 있을 때 이용하는 구조이다.

전자문서 증명서 다운로드 요청시의 요청 메시지(GetCertRequestData)의 처리절차와 스키마 구조는 각각 도 5u,도 5v와 같으며, 전달인자 각각에 대한 설명은 다음과 같다.

- CertId: string: 1..1: 다운로드 대상인 증명서의 SerialNumber 필드의 값을 string으로 변환한 값

⑫ 검색(Search)

이용자가 전자문서 보관소 서버(130) 내의 전자문서, 증적 데이터, 증명서, 이용자 등을 검색할 때 이용하는 구조이다. 검색 요청 메시지 및 응답 메시지는 다른 메시지 구조와는 달리 단일 요청 및 단일 응답만 가능하므로, SearchRequestData 요소 및 SearchResponseData 요소의 개수는 1로 설정됨이 바람직하다. 검색시의 요청 메시지(SearchRequestData)의 처리절차는 도 5w와 같다.

한편, 검색시의 요청 메시지는 검색대상에 따라 전자문서 검색요청 메시지, 증적 검색요청 메시지, 증명서 검색요청 메시지, 이용자 검색요청 메시지 등으로 구분된다. 각 검색요청 메시지의 하위요소들, 즉 검색조건은 선택적 생성이 가능하며, 만약 전자문서 보관소 서버(130)가 검색조건이 없는 검색요청 메시지를 수신하였다면 이용자에게 모든 데이터를 리턴하도록 한다. 각 요청 메시지에 대한 스키마 구조는 도 5xa 내지 도 5xd와 같으며, 전달인자 각각에 대한 설명은 다음과 같다.

ⓐ 전자문서 검색요청 메시지(DocumentPackageQueryCondition) 경우

- DocumentPackageQueryCondition: 1..1: 전자문서 검색조건

- [속성]startIndex: nonNegativeInteger: 필수: 검색결과 중 몇번째 record부터 결과를 받고자 하는지를 명시. 기본값은 0으로 이 값이 0인 경우에는 응답 메시지에 검색결과의 첫번째 record부터 기술

- [속성]maxResults: integer: 필수: 검색결과 중 startIndex부터 전체 몇건의 record를 응답 메시지에 담아서 응답할 것인지를 기술. 기본값은 -1로서 이 값이 -1인 경우에는 검색결과를 모두 응답 메시지에 담아서 응답함

- MainTitle: string: 0..1: 전자문서의 내용을 대표할 수 있는 문구로서 본제목(MainTitle) 요소의 값을 사용

- ClassificationCode: string: 0..1: 분류체계 내에서의 고유값으로서 분류코드(ClassificationCode) 요소의 값을 사용

- KeyWord: string: 0..1: 전자문서의 내용을 대표할 수 있는 주제어로서 키워드(KeyWord) 요소의 값을 사용

- RegisteredDate: 0..1: 등록된 SIP를 전자문서 보관소 서버(130)에서 AIP로 생산하여 저장한 일시로서 등록일시(RegisterDateTime) 요소의 값을 기준으로 검색하기 위한 기간

- TimeFrom: string: 1..1: 검색을 위한 시작 시간, (예)"20060918160955Z"

- TimeTo: string: 1..1: 검색을 위한 끝 시간, (예)"20060918160955Z"

- ExpiredDate: 0..1: 전자문서의 보관기간 만료일을 기준으로 검색하기 위한 기간

- TimeTo: string: 1..1: 검색을 위한 끝 시간, (예)"20060918160955Z"

- RegistrationRequester: 0..1: 문서등록 요청자 정보

- Organizatioin: 1..1: 기관 정보

- ID: string: 1..1: 기관 ID

- Name: string: 1..1: 기관 실명

- DN : string: 1..1: 기관 인증서 DN

- Person: 1..1: 개인 정보

- ID: string: 1..1: 개인 ID

- Name: string: 1..1: 개인 실명

- DN : string: 1..1: 개인 인증서 DN

ⓑ 증적 검색요청 메시지(OpRecordQueryCondition) 경우

- OpRecordQueryCondition: 1..1: 증적 검색조건

- SerialNo: 0..1: 증적의 식별번호로서 target 필드 내의 serialNo 필드의 값을 기준으로 검색하기 위한 범위

- NoFrom: string: 1..1: 검색을 위한 시작 번호, (예)"102f"

- NoTo: string: 1..1: 검색을 위한 끝 번호, (예)"102f"

- OperationDate: 0..1: 이용자의 요청에 의한 전자문서 보관소 서버(130)의 작업시간을 기준으로 검색하기 위한 기간

- TimeTo: string: 1..1: 검색을 위한 끝 시간, (예)"20060918160955Z"

- OperationRequester: 0..1: 작업 요청자 정보

- Organizatioin: 1..1: 기관 정보

- ID: string: 1..1: 기관 ID

- Name: string: 1..1: 기관 실명

- DN : string: 1..1: 기관 인증서 DN

- Person: 1..1: 개인 정보

- ID: string: 1..1: 개인 ID

- Name: string: 1..1: 개인 실명

- DN : string: 1..1: 개인 인증서 DN

- OperationType: string: 0..1: 전자문서 보관소 서버(130)가 제공한 서비스 종류, 즉 작업 종류로서 opType 필드의 값을 사용, (예)"0"

- AipId: string: 0..1: AIP의 패키지 식별자로서 패키지 식별자(PackageID) 요소의 값을 사용

- DipId: string: 0..1: DIP의 패키지 식별자로서 패키지 식별자(PackageID) 요소의 값을 사용

- CertificateQueryCondition: 1..1: 증명서 검색조건

- DateOfIssue: 0..1: 증명서의 발급일로서 증명서 발급일(DateOfIssue) 필드의 값을 기준으로 검색하기 위한 기간

- TimeTo: string: 1..1: 검색을 위한 끝 시간, (예)"20060918160955Z"

- DateOfExpiration: 0..1: 증명서의 효력만기일로서 증명서 효력만기일(DateOfExpiration) 필드의 값을 기준으로 검색하기 위한 기간

- TimeTo: string: 1..1: 검색을 위한 끝 시간, (예)"20060918160955Z"

- CertRequester: 0..1: 증명서 요청자 정보

- Organizatioin: 1..1: 기관 정보

- ID: string: 1..1: 기관 ID

- Name: string: 1..1: 기관 실명

- DN : string: 1..1: 기관 인증서 DN

- Person: 1..1: 개인 정보

- ID: string: 1..1: 개인 ID

- Name: string: 1..1: 개인 실명

- DN : string: 1..1: 개인 인증서 DN

- CertType: string: 0..1: 증명서의 종류로서 등록증명서("0"), 발급증명서("1"), 이관증명서("2"), 폐기증명서("3"), 원본증명서("4")의 값을 가짐

- UsageType: string: 0..1: 증명서의 용도로서 증명서 용도(usageType) 확장필드의 값을 BIT STRING 표현방식과 유사한 방법으로 표현, (예)online(0)과 paperEnable(2)이 설정되었다면 "101"로 표기, mobile(1)만 설정되었다면 "01"로 표기

- Nominee: 0..1: 증명서의 수임자 정보

- ID: string: 1..1: 수임자 ID

- Name: string: 1..1: 수임자 실명

- DN : string: 1..1: 수임자 인증서 DN

- IsRevoked: string: 0..1: 증명서의 폐지여부로서 정상("0"), 폐지("1")의 값을 가짐

ⓓ 이용자 검색요청 메시지(UserQueryCondition) 경우

- UserQueryCondition: 1..1: 이용자 검색조건

- Organizatioin: 0..1: 기관 정보

- ID: string: 1..1: 기관 ID

- Name: string: 1..1: 기관 실명

- DN : string: 1..1: 기관 인증서 DN

- Person: 0..1: 개인 정보

- ID: string: 1..1: 개인 ID

- Name: string: 1..1: 개인 실명

- DN : string: 1..1: 개인 인증서 DN

다음으로, 연계 인터페이스 모듈에 구비되는 보안 처리부가 메시지의 유효성 여부를 판별하는 방법, 즉 전송보안에 대해 설명한다.

일반적으로 전자문서 보관소 서버(130)와 이용자 서버(120)를 연계시킬 경우 송수신되는 문서는 보안처리됨이 필요하다. 이를 감안할 경우, 전송보안이 적용된 메시지의 처리흐름은 도 6a에 도시된 바와 같이 정의될 수 있다. 본 발명에 따른 보안 처리부도 도 6a에 도시된 바를 참작하여 메시지의 유효성 여부를 판별함은 물론이다. 그런데, 연계 인터페이스 구성시 고려해야 하는 보안은 크게 3가지로 나뉜다. 전자문서의 기밀성을 보장하는 네트워크 전송보안, 정당한 이용자임을 확인시켜 주는 이용자 인증, 전송문서에 대한 송수신 부인방지 및 무결성을 보장하는 송수신 문서에 대한 보안이 바로 그것인데, 이하 이에 대해 설명한다.

ⓐ 네트워크 전송보안

전자문서 보관소 서버(130)는 이용자에게 요청과 응답 메시지를 주고 받는 과정에서 전송보안을 제공하기 위해 반드시 SSL(Secure Socket Layer)V3.0을 이용한 HTTP/S(Secure Hypertext Transfer Protocol)를 지원하여야 하며, 반드시 클라이언트와 서버간의 상호인증을 기반으로 하여야 한다.

ⓑ 이용자 인증

이용자 인증을 위한 방법으로 WS-Security 규약(WS-Security V1.1)을 참조한다. 이용자 인증은 공인인증서를 통한 전자서명을 사용하여 동시에 처리되며, 주요 처리절차는 도 6b에 도시된 바와 같다.

한편, 전자문서 보관소 서버(130)는 이용자 인증을 위해 WS-Security에 정의된 "Binary Security Token" 방식을 사용하여 이용자에 대한 인증정보를 넘겨주도록 하며, 사용 가능한 Binary Security Token으로는 X.509 Certificate V.3만으로 한정한다. 이용자는 매 요청 메시지 전송시 이용자 인증정보를 같이 전송함으로써 전자문서 보관소 서버(130)가 요청 메시지 처리 전에 항상 이용자 인증 과정을 거치도록 한다.

송수신 메시지에 대한 보안을 위한 방법으로 이용자 인증의 경우와 마찬가지로 WS-Security 규약(WS-Security V1.1)을 참조한다. 마찬가지로, 송수신 메시지에 대한 보안은 공인인증서를 통한 전자서명을 사용하여 동시에 처리되며, 주요 처리절차는 도 6b에 도시된 바와 같다.

송수신 메시지 보안 중 송수신 메시지에 대한 기밀성 유지는 네트워크 전송보안에서 처리하도록 하며, 여기에서는 전송 과정에서의 메시지 위변조 방지 및 송신자 또는 수신자의 메시지 송수신에 대한 부인 방지 방안을 다루도록 한다.

메시지에 대한 위변조 방지 및 부인 방지를 위해 이용자 서버(120) 및 전자문서 보관소 서버(130)는 요청/응답 메시지에 송신자의 전자서명을 추가하게 된다. 전자서명은 W3C에서 권고하는 "XML Signature Syntax and Processing" 규약을 준수한 WS-Security v1.1에 기술된 형식으로 생성함이 바람직하며, 전자서명 정보를 담은 <Signature> 항목은 SOAP Header의 하위 항목으로 기술된다. 서명 대상은 실제 송수신 메시지를 포함하는 SOAP BODY 부분으로, 전자서명된 메시지의 구조는 도 6c에 도시된 바와 같다.

한편, 본 발명에서는 첨부문서에 대한 보안도 고려됨이 바람직하다. 첨부문서 보안에 대해서는 이용자가 문서를 등록요청하거나 저장된 문서를 열람 또는 발급요청하는 경우, 문서를 암호화하거나 문서 생성자의 서명을 추가하여 송수신 메시지 단위가 아닌 문서 자체에 보안 처리를 하는 경우가 있다. 그러나, 문서 자체에 대한 이와 같은 보안처리는 증명서 내에서 정의하여 처리함이 바람직하므로, 본 발명에서는 보안이 적용된 경우이거나 아닌 경우이거나 동일하게 전달해야 하는 하나의 정보증명서로 인식하여 처리하도록 한다.

다음으로, 연계 인터페이스 모듈의 메시지 검증부가 추출된 메시지를 검증하는 방법(구체적으로, 제2 메시지 검증부(268)가 요청 메시지를 검증하는 방법 또는 제1 메시지 검증부(218)가 응답 메시지를 검증하는 방법)을 설명한다.

이용자 서버(120)와 전자문서 보관소 서버(130)는 연계 인터페이스 메시지를 수신하여 메시지로부터 필요한 데이터를 추출하는 과정 중에 수신한 연계 인터페이스 메시지에 대한 검증 작업을 수행하여야 한다. 이러한 연계 인터페이스 메시지의 세부 검증 과정은 메시지의 종류에 따라 약간의 차이가 있으나, 크게 구조 검증, 인증 및 무결성 검증, 내용 검증 등으로 구분할 수 있다. 다만, 각 검증 과정은 필요에 따라 순서가 바뀌거나 통합 또는 세분화될 수 있다. 한편, 메시지에 대한 기밀성 보장을 위하여 사용된 네트워크 전송보안이 적용된 상태의 메시지에 대한 검증은 적용된 기밀성 보장 기술의 자체 검증 절차에 따라 검증하도록 한다.

ⓐ 구조 검증

연계 인터페이스 메시지의 구조 검증은 검증 대상인 메시지가 본 발명에서 정의하고 있는 메시지 구조와 각 요소의 type 및 값의 제약 범위 등을 준수하고 있음을 확인하는 작업이다. 검증 대상 메시지의 구현 프로토콜에 따라서, 표준 메시지 구조 및 HTTP 기반의 SOAP 메시지 구조를 적절하게 적용하여 검증하도록 한다. 즉, 검증 시스템은 모든 연계 인터페이스 메시지에 대하여 표준 메시지 구조 및 제약 조건을 준수하였는가를 검증하여야 하며, 구현 프로토콜이 HTTP 기반의 SOAP 인 경우에는 추가적으로 정의한 SOAP 메시지 구조 및 제약 조건을 준수하였는가를 검증하여야 한다.

자체 송수신 프로토콜을 사용하여 연계 인터페이스를 구성한 경우에는 표준 메시지 구조 및 제약 조건에 따라 메시지 구성 요소들의 계층구조, 필수 요소들의 누락여부, type, 반복수, 값의 범위, 생성규칙 중 표현방식 등을 확인하도록 한다. HTTP 기반의 SOAP을 사용하여 연계 인터페이스를 구성한 경우에는 추가적으로 정의한 SOAP 메시지의 전체 구조 및 제약 조건에 따라 하기와 같은 항목들을 검증하도록 한다. 단, HTTP 송수신 프로토콜에 대한 준수 여부는 해당 프로토콜에 정의된 규칙에 따라서 검증하도록 한다.

검증 시스템은 전체 메시지의 구조가 SOAP 메시지와 첨부파일들로 이루어진 Multi-MIME 형식이며 관련 제약사항을 준수하였음을 확인하여야 한다. 검증 시스템은 SOAP 메시지의 내부구조가 본 발명에서 정의한 구조를 준수하였는가를 확인하여야 하는데, SOAP Header의 Security Header 및 MessageHeader와 SOAP Body의 RequestMessage 또는 ResponseMessage의 구조, 그리고 각 메시지의 종류별 하부 구조가 상기에 정의된 구조와 동일함을 확인하도록 한다.

마지막으로, 검증 시스템은 각 메시지의 종류별로 정의된 하위 요소들이 본 발명에 정의된 type과 반복수, 값의 범위, 생성규칙 중 표현방식 등을 준수하고 있는가를 확인하여야 한다. 만약 연계 인터페이스 메시지의 구조 검증이 실패한다면, 검증 시스템 또는 통신 시스템은 해당 오류의 원인을 출력한 후 상대 시스템과의 연결을 종료하도록 한다.

ⓑ 인증 및 무결성 검증

연계 인터페이스 메시지에 대한 인증 및 보안을 위하여 본 발명에서는 연계 인터페이스 메시지의 구현 프로토콜에 따라 자체 구현한 인증 및 보안 방식을 이용하거나 또는 WS-Security 규약에 정의된 방법을 준용하도록 하고 있다. 따라서, 이에 대한 검증도 자체 구현한 인증 및 보안 방식이나 WS-Security 규약에 정의된 방법을 기반으로 수행하여야 하는데, 어떤 경우이든 검증 과정 및 각 단계별 목적은 하기와 같이 거의 동일하다.

먼저, 메시지에 첨부된 전자서명을 검증하고 첨부파일이 전자서명 대상 데이터에 포함되지 않았다면, 첨부파일에 대한 무결성 검증을 별도로 수행하여 전체 메시지에 대한 무결성 검증을 수행한다. 그리고, 메시지의 전자서명에 사용된 인증서의 유효성 검증을 수행한다. 마지막으로, 메시지 서명자에 대한 인증 작업을 수행하여 메시지 서명자가 적법한 통신 상대임을 확인한다.

자체 구현 송수신 프로토콜을 사용하여 생성된 연계 인터페이스 메시지에 대하여 인증 및 무결성 검증을 수행하는 과정은 하기에 기술되는 HTTP 기반의 SOAP을 사용한 연계 인터페이스 메시지에 대한 인증 및 무결성 검증 절차를 참조하여 수행하도록 한다. HTTP 기반의 SOAP을 사용한 연계 인터페이스 메시지에 대한 무결성 검증을 위하여 먼저 검증 시스템은 SOAP 메시지에 적용된 WS-Security에 대한 검증, 즉 전자서명 검증을 수행하여야 하는데, 이는 위에 기술한 것처럼 해당 규약을 참조하여 수행한다. 물론, 이 과정은 Signature 요소에 대한 검증 뿐만 아니라, 연계인터페이스 메시지의 본문이라 할 수 있는 SOAP Body의 내용을 해쉬한 값인 DigestValue 요소에 대한 검증을 반드시 포함해야 한다. WS-Security 검증 과정을 수행하기 전에, Security 요소의 하부 구조에 대한 물리적인 검증을 수행하여야 하는데, 이 과정은 연계 인터페이스 메시지의 구조 검증 과정에서 수행할 수도 있다.

WS-Security의 내용 검증은 Multi-MIME 중에서 첫번째 MIME의 내용인 SOAP 메시지의 무결성만을 보장하는 것이므로, 두번째 MIME부터 첨부파일이 존재한다면 반드시 SOAP 메시지에 포함된 첨부파일 해쉬값과 실제 첨부파일의 해쉬값을 비교하여 Multi-MIME 전체의 무결성을 검증하여야 한다. 이는 SOAP 메시지에 기재된 첨부파일의 식별값과 일치하는 첨부파일이 첨부되었는가를 확인하기 위한 것이므로, 증명서나 전자문서 정보 패키지처럼 첨부파일 자체에 행해진 보안처리 여부에 관계없이 무조건 수행되어야 한다. 연계 인터페이스 메시지의 무결성 검증 과정 중 또는 전후에 반드시 SOAP 메시지의 전자서명에 사용된 인증서의 유효성 확인 작업도 수행되어야 한다. 인증서 유효성 확인 작업은 예컨대 한국정보보호진흥원이 2004년 5월 공개한 "[KCAC.TS.CERTVAL] 공인인증서 경로검증 기술규격 v1.00"이 준용될 수 있다. 여기에서, 공인인증서 경로검증 기술규격이라 함은 전자서명 인증체계 공인인증 서비스의 신뢰성을 보장하기 위해 인증서의 인증경로 구축방법과 검증절차를 명시한 기술규격을 말한다.

연계 인터페이스 메시지의 생성과 검증은 거의 실시간으로 이루어지기 때문에, 생성시에는 서명 인증서가 유효하지만 검증시에는 서명 인증서가 유효하지 않을 수 있는 경우는 거의 발생하지 않을 것이나, 추후 부인 방지 등을 위하여 보관 중이었던 과거의 연계 인터페이스 메시지에 대하여 현재에 검증을 수행하는 경우라면 충분히 해당 경우가 발생할 가능성이 있다. 이런 경우, 서명 인증서의 유효성 검증에는 실패하였더라도 전자서명 장기검증 기술이 적용되었고 해당 검증 기술에 따라 검증하여 성공하였다면 서명 인증서의 유효성 검증의 결과와는 관계없이 연계 인터페이스 메시지의 전자서명 검증에 성공한 것으로 처리한다. 장기검증 기술은 한국전자거래진흥원 또는 유관기관이 제정한 기술규격을 준용할 수 있으므로 여기서는 그 내용 설명을 생략한다.

무결성 검증은 연계 인터페이스 메시지가 전달되는 과정에서의 훼손 여부를 검증하는 것이며, 메시지 서명자에 대한 인증 과정을 통하여 반드시 메시지 서명자가 적법한 통신 상대임을 확인하여야 한다. 메시지 서명자에 대한 인증은 SOAP 메시지의 BinarySecurityToken 요소에 포함된 서명자의 인증서를 추출한 후, 통신 상대 신뢰 목록 내에 있음을 확인함으로써 이루어진다. 물론, 통신 상대 신뢰 목록은 검증 시스템이 안전하게 관리하여야 한다. 메시지 서명자에 대한 인증은 이용자 서버(120)와 전자문서 보관소 서버(130) 양측에서 모두 수행되어야 한다. 만약, 연계 인터페이스 메시지에 대한 인증 및 무결성 검증이 실패한다면, 검증 시스템은 해당 오류의 원인을 출력하도록 하고 상대 시스템과의 연결을 종료하도록 한다.

연계 인터페이스 메시지의 내용 검증은 메시지의 각 요소에 기재된 값이 본 발명에서 제시한 제약사항을 준수하고 있으며 모순은 없는가를 확인하는 작업이다. 본 발명에서는 메시지에 포함될 값을 생성할 때 적용해야 하는 규칙을 정의하고 있는데, 해당 생성규칙 중에서 표현방식에 대한 검증은 구조 검증 과정에서 수행하도록 하고, 연관관계나 논리적 모순, 불일치 등에 대한 검증은 본 내용 검증 과정에서 수행하도록 한다. 구분하기 힘든 경우, 어떤 과정에서 수행하여도 무방하다.

내용 검증의 예를 들자면 OperationType 요소의 값과 MessageBody의 하부구조가 일치하는가, TimeStamp 요소의 값이 타당한 현재 시간인가, TotalCount 요소의 값과 실제 RequestData 또는 ResponseData의 개수가 일치하는가, 응답메시지의 MessageID 요소에 기재된 값은 요청메시지에 기재된 random number를 사용하여 생성되었는가, 메시지에 사용된 패키지 식별자나 증명서 식별자 등은 실제로 첨부된 패키지나 증명서의 식별자를 사용하여 기재되었는가 등이며, 이외에도 각 요소의 생성규칙에 위배된 항목들이 있다면 모두 내용 검증 과정에서 오류로 확인되어야 한다. 예로 든 항목 중에서 OperationType 요소의 값과 MessageBody의 하부구조의 일치 여부는 구조 검증시에 수행될 수도 있다.

이용자 서버(120)는 연계 인터페이스 메시지 중 응답 메시지에 대한 검증을 수행하여야 하는데, 응답 메시지에 대한 내용 검증은 요청 메시지와의 비교 검증이 추가로 수행되어야 한다. 즉, 수신된 응답 메시지가 지정된 제약사항을 준수하고, 자체 모순이 없다 하더라도 송신했던 요청 메시지에 대한 올바른 응답 메시지가 아니라면 내용 검증 실패로 처리하여야 한다. 예를 들자면, 요청 메시지의 RequestData의 개수와 응답 메시지의 ResponseData의 개수가 일치하는가, 전자문서 등록시 전달했던 SipId 요소가 응답 메시지에도 동일하게 포함되어 있는가, 전자문서 폐기시 원본 전자문서를 요청한 경우 응답 메시지에 원본 전자문서가 포함되어 있는가 등이며, 이외에도 요청 메시지와 응답 메시지가 일관성이 없다면 모두 오류로 확인되어야 한다. 만약 연계 인터페이스 메시지의 내용 검증이 실패한다면 검증 시스템은 해당 오류의 원인을 출력하도록 하고 해당 작업은 실패로 처리한다.

다음으로, 연계 인터페이스의 유형에 따른 응답 메시지의 스키마 구조 설정을 설명한다. 응답 메시지의 스키마 구조는 제시하는 기본 구조가 변형되지 않는한 다양한 확장이 가능하다. 이하, 각 유형에 대한 개념은 도 5 series를 참조하여 상술한 연계 인터페이스의 유형에 따른 요청 메시지의 스키마 구조 설정 부분에 기재한 바 여기서는 생략하며, 응답 메시지의 스키마 구조 및 전달인자 각각에 대한 설명만을 언급하기로 한다.

① 전자문서 등록(SubmitDocument)

전자문서 등록요청에 대한 응답 메시지(SubmitDocumentResponseData)의 스키마 구조는 도 7a와 같으며, 전달인자 각각에 대한 설명은 다음과 같다.

- SipId: string: 1..1: 요청메시지에 기술된 SIP id값을 기술함

- ResultCode: string: 1..1: SIP 등록 처리 결과에 따라 성공("1"), 실패("2") 여부를 기록

- Success: : 1..1: 문서등록 처리결과가 성공인 경우 성공결과를 기록함

- AipId: string: 1..1: AIP 패키지 생성 시 부여된 패키지 식별자

- CertID: string: 1..1: 문서가 등록된 후 발급된 등록증명서의 일련번호

- CertInfo: string: 1..1: Multi-MIME 형식으로 첨부된 등록증명서의 위치정보를 기술(MIME으로 패키징된 SOAP 연계 인터페이스에서는 첨부파일의 c-id 값을 사용)

- CertHashAlgorithm: string: 1..1: 첨부된 등록증명서 파일의 무결성을 확인하기 위하여 사용한 Hash 알고리즘

- CertHashValue: base64Binary: 1..1: 첨부된 등록증명서 파일을 Hash한 값

- Fail: 1..1: 문서등록 처리결과가 실패인 경우 발생한 오류에 대한 부연설명이 기록됨

- Reason: string: 1..1: 오류코드 또는 오류메시지를 각 보관소의 자체 포맷으로 string 형태로 기술

② 전자문서 발급(GetDocument)

전자문서 발급요청에 대한 응답 메시지(GetDocumentResponseData)의 스키마 구조는 도 7b와 같으며, 전달인자 각각에 대한 설명은 다음과 같다.

- AipId: string: 1..1: 요청메시지에 기술된 AIP id값을 기술함

- ResultCode: string: 1..1: AIP에 대한 발급처리 결과에 따라 성공("1"), 실패("2") 여부를 기록

- Success: : 1..1: 문서발급 처리결과가 성공인 경우 성공결과를 기록함

- DipId: string: 1..1: DIP 패키지 생성시 부여된 패키지 식별자

- DipInfo: string: 1..1: Multi-MIME 형식으로 첨부된 DIP의 위치정보를 기술(MIME으로 패키징된 SOAP 연계 인터페이스에서는 첨부파일의 c-id 값을 사용)

- DipHashAlgorithm: string: 1..1: 첨부된 DIP 파일의 무결성을 확인하기 위하여 사용한 Hash 알고리즘

- DipHashValue: base64Binary: 1..1: 첨부된 DIP 파일을 Hash한 값

- Fail: 1..1: 문서발급 처리결과가 실패인 경우 발생한 오류에 대한 부연 설명이 기록됨

③ 전자문서 제3자 발급(DeliverDocument)

전자문서 제3자 발급요청에 대한 응답 메시지(DeliverDocumentResponseData)의 스키마 구조는 도 7c와 같으며, 전달인자 각각에 대한 설명은 다음과 같다. 설명에 포함되지 않은 전달인자는 전자문서 발급(GetDocument)의 경우를 적용시킨다.

- ResultCode: string: 1..1: 요청메시지의 수신 결과에 따라 성공("1"), 실패("2") 여부를 기록

- Success: string: 1..1: 요청메시지의 수신 결과가 성공인 경우 NULL("")을 포함

④ 증명서를 사용한 전자문서 발급(GetDocumentByCert)

증명서를 사용한 전자문서 발급요청에 대한 응답 메시지(GetDocumentByCertResponseData)의 스키마 구조는 도 7d와 같으며, 전달인자 각각에 대한 설명은 전자문서 발급(GetDocument)의 경우와 동일하다.

⑤ 전자문서 이관(TransferDocument)

전자문서 이관요청에 대한 응답 메시지(TransferDocumentResponseData)의 스키마 구조는 도 7e와 같으며, 전달인자 각각에 대한 설명은 전자문서 제3자 발급(DeliverDocument)의 경우와 동일하다.

⑥ 전자문서 폐기(DeleteDocument)

전자문서 폐기요청에 대한 응답 메시지(DeleteDocumentResponseData)의 스키마 구조는 도 7f와 같으며, 전달인자 각각에 대한 설명은 다음과 같다. 설명에 포함되지 않은 전달인자는 전자문서 발급(GetDocument)의 경우를 적용시킨다.

- Success: : 1..1: 문서폐기 처리결과가 성공인 경우 성공결과를 기록하며, 요청메시지에서 DIP 발급을 요청한 경우 DIP 정보가 첨부되고, 그렇지 않은 경우는 하위 요소가 생략됨

⑦ 전자문서 보관연장(ExtendRetention)

전자문서 보관연장 요청에 대한 응답 메시지(ExtendRetentionResponseData)의 스키마 구조는 도 7g와 같으며, 전달인자 각각에 대한 설명은 다음과 같다. 설명에 포함되지 않은 전달인자는 전자문서 발급(GetDocument)의 경우를 적용시킨다.

- ResultCode: string: 1..1: 요청메시지에 대한 연장보관 가능여부의 확인결과에 따라 성공("1"), 실패("2") 여부를 기록

- Success: string: 1..1: 요청메시지에 대한 연장보관 가능여부의 확인결과가 성공인 경우 NULL("")을 포함

- Fail: 1..1: 요청메시지에 대한 연장보관 가능여부의 확인결과가 실패인 경우 발생한 오류에 대한 부연 설명이 기록됨

⑧ 증명서 발급(IssueCert)

전자문서 증명서 발급요청에 대한 응답 메시지(IssueCertResponseData)의 스키마 구조는 도 7h와 같으며, 전달인자 각각에 대한 설명은 다음과 같다. 설명에 포함되지 않은 전달인자는 전자문서 발급(GetDocument)의 경우를 적용시킨다.

- TargetRecordId: string: 1..1: 요청메시지에 기술된 RequestId값을 기술함

- CertId: string: 1..1: 증명서 생성시 부여된 SerialNumber 필드의 값을 string으로 변환한 값

⑨ 증명서 갱신발급(UpdateCert)

전자문서 증명서 갱신발급 요청에 대한 응답 메시지(UpdateCertResponseData)의 스키마 구조는 도 7i와 같으며, 전달인자 각각에 대한 설명은 다음과 같다. 설명에 포함되지 않은 전달인자는 전자문서 등록(SubmitDocument)의 경우를 적용시킨다.

- CertId: string: 1..1: 요청메시지에 기술된 CertId값을 기술함

- ResultCode: string: 1..1: 증명서 갱신발급 요청에 대한 처리결과에 따라 성공("1"), 실패("2") 여부를 기록

- Success: : 1..1: 증명서 갱신발급 처리결과가 성공인 경우 성공결과를 기록함

- Fail: 1..1: 증명서 갱신발급 처리결과가 실패인 경우 발생한 오류에 대한 부연 설명이 기록됨

⑩ 증명서 검증(VerifyCert)

전자문서 증명서 검증요청에 대한 응답 메시지(VerifyCertResponseData)의 스키마 구조는 도 7j와 같으며, 전달인자 각각에 대한 설명은 다음과 같다. 설명에 포함되지 않은 전달인자는 전자문서 등록(SubmitDocument)의 경우를 적용시킨다.

- ResultCode: string: 1..1: 증명서 검증결과에 따라 성공("1"), 실패("2") 여부를 기록

- Success: string: 1..1: 증명서 검증결과가 성공인 경우에, 요청메시지에서 난수값을 요청하였다면 해당 난수값을 포함하고, 요청하지 않았다면 하위 요소가 생략됨

- RandomNumber: base64Binary: 0..1: 증명서 요청자가 생성하여 보관소에 보관중인 160 비트의 난수값

- Fail: 1..1: 증명서 검증결과가 실패인 경우 발생한 오류에 대한 부연 설명이 기록됨

⑪ 증명서 다운로드(GetCert)

전자문서 증명서 다운로드 요청에 대한 응답 메시지(GetCertResponseData)의 스키마 구조는 도 7k와 같으며, 전달인자 각각에 대한 설명은 다음과 같다. 설명에 포함되지 않은 전달인자는 전자문서 등록(SubmitDocument)의 경우를 적용시킨다.

- ResultCode: string: 1..1: 증명서 다운로드 요청에 대한 처리결과에 따라 성공("1"), 실패("2") 여부를 기록

- Success: : 1..1: 증명서 다운로드 처리결과가 성공인 경우 성공결과를 기록함

- Fail: 1..1: 증명서 다운로드 처리결과가 실패인 경우 발생한 오류에 대한 부연 설명이 기록됨

⑫ 검색(Search)

검색에 대한 응답 메시지는 검색 대상에 따라 전자문서 검색응답 메시지, 증적 검색응답 메시지, 증명서 검색응답 메시지, 이용자 검색응답 메시지로 구분된다. 이용자가 검색응답 메시지로부터 필요한 정보를 추출하여 이용할 수 있도록 검색응답 메시지에는 검색 대상 데이터에 대한 상세한 정보가 기술되어야 한다. 특히 선택적 생성 요소의 경우는 검색 대상 데이터에 해당 값이 존재한다면 해당 값을 사용하여 반드시 생성하도록 한다.

각 응답 메시지에 대한 스키마 구조는 도 7l 내지 도 7o와 같으며, 전달인자 각각에 대한 설명은 다음과 같다.

ⓐ 전자문서 검색응답 메시지(DocumentPackageList) 경우

- DocumentPackageList: 1..1: 전자문서 검색결과

- [속성]recordCount: nonNegativeInteger: 필수: DocumentPackage의 개수

- DocumentPackage: 0..∞: 검색된 전자문서 패키지

- AipId: string: 1..1: AIP의 패키지의 식별자로서 패키지 식별자(PackageID) 요소의 값을 사용

- DocumentList: 1..1: 패키지 내의 전자문서 리스트

- [속성]documentCount: nonNegativeInteger: 필수: Document의 개수

- Document: 1..∞: 패키지 내의 전자문서

- DocumentId: string: 1..1: 전자문서의 식별자로서 전자문서 식별자(DocumentID) 요소의 값을 사용

- FileList: 1..1: 전자문서 내의 첨부파일 리스트

- [속성]fileCount: nonNegativeInteger: 필수: File의 개수

- File: 1..∞: 전자문서 내의 첨부파일

- FileId: string: 1..1: 첨부파일의 식별자로서 첨부파일 식별자(FileID) 요소의 값을 사용

- FileName: string: 1..1: 첨부파일의 제목으로서 첨부파일명(FileName) 요소의 값을 사용

- FileFormat: string: 0..1: 첨부파일의 포맷으로서 첨부파일 포맷(FileFormat) 요소의 값을 사용

- MainTitle: string: 1..1: 전자문서의 내용을 대표할 수 있는 문구로서 본제목(MainTitle) 요소의 값을 사용

- KeyWordList: 1..1: 키워드 리스트

- [속성]keyWordCount: nonNegativeInteger: 필수: KeyWord의 개수

- KeyWord: 1..∞: 전자문서의 내용을 대표할 수 있는 주제어로서 키워드(KeyWord) 요소의 값을 사용

- ClassificationCode: string: 1..1: 분류체계 내에서의 고유값으로서 분류코드(ClassificationCode) 요소의 값을 사용

- RegisteredDateTime: string: 1..1: 등록된 SIP를 보관소에서 AIP로 생산하여 저장한 일시로서 등록일시(RegisterDateTime) 요소의 값을 사용, (예)"20060918160955Z"

- ExpiredDateTime: string: 1..1: 전자문서의 보관기간 만료일, (예)"20060918160955Z"

- RegistrationRequester: 1..1: 문서등록 요청자 정보

- Organizatioin: 0..1: 기관 정보

- ID: string: 1..1: 기관 ID

- Name: string: 0..1: 기관 실명

- DN : string: 0..1: 기관 인증서 DN

- Person: 1..1: 개인 정보

- ID: string: 1..1: 개인 ID

- Name: string: 0..1: 개인 실명

- DN : string: 0..1: 개인 인증서 DN

- IsEncrypted: string: 1..1: 전자문서의 암호화 보관 여부로서 암호화하지 않음("0"), 암호화("1")의 값을 가짐

ⓑ 증적 검색요청 메시지(OpRecordList) 경우

- OpRecordList: 1..1: 증적 검색 결과

- [속성]recordCount: nonNegativeInteger: 필수: OpRecord의 개수

- OpRecord: 0..∞: 검색된 증적

- RecordSerialNo: 1..1: 증적의 식별번호로서 target 필드 내의 serialNo 필드의 값을 사용, (예)"102f"

- OperationDateTime: string: 1..1: 이용자의 요청에 의한 보관소의 작업시간을 기준으로 검색하기 위한 기간, (예)"20060918160955Z"

- OperationRequester: 0..1: 작업 요청자 정보로서 작업 요청자 정보가 NULL인 증적에 대한 응답메시지인 경우는 생성하지 않도록 함

- ID: string: 0..1: 작업 요청자 ID

- Name: string: 1..1: 작업 요청자 실명

- DN : string: 0..1: 작업 요청자 인증서 DN

- OperationType: string: 1..1: 보관소가 제공한 서비스 종류, 즉 작업 종류로서 opType 필드의 값을 사용, (예)"0"

- Aip: 1..1: 관련 AIP 패키지 정보

- AipId: string: 1..1: AIP의 패키지 식별자로서 패키지 식별자(PackageID) 요소의 값을 사용

- DocumentId: string: 1..1: AIP의 패키지 내의 전자문서 식별자로서 전자문서 식별자(DocumentID) 요소의 값을 사용

- FileIdList : 1..1: FileId의 리스트

- [속성]FileIdCount: nonNegativeInteger: 필수: FileId의 개수

- FileId: string: 1..∞: 전자문서 내의 첨부파일의 식별자로서 첨부파일 식별자(FileID) 요소의 값을 사용

- Dip: 0..1: 관련 DIP 패키지 정보

- DipId: string: 1..1: DIP의 패키지 식별자로서 패키지 식별자(PackageID) 요소의 값을 사용

- DocumentId: string: 1..1: DIP의 패키지 내의 전자문서 식별자로서 전자문서 식별자(DocumentID) 요소의 값을 사용

- FileIdList : 1..1: FileId의 리스트

- [속성]FileIdCount: nonNegativeInteger: 필수: FileId의 개수

- PeerArcInfo: 0..1: 이수관시 상대 보관소 서버의 정보

- ID: string: 0..1: 상대 보관소 서버의 ID

- Name: string: 1..1: 상대 보관소 서버의 실명

- DN : string: 0..1: 상대 보관소 서버의 인증서 DN

- OperationReason: string: 0..1: 작업의 사유로서, 증적의 사유(reason) 필드의 값을 BIT STRING 표현방식과 유사한 방법으로 표현, (예)userRequest(0)과 expired(2)가 설정되었다면 "101"로 표기, arcRequest(1)만 설정되었다면 "01"로 표기

- CertificateList: 1..1: 증명서 검색 결과

- [속성]recordCount: nonNegativeInteger: 필수: Certificate의 개수

- Certificate: 0..∞: 검색된 증명서

- CertSerialNumber: string: 1..1: 증명서의 일련번호로서 serialNumber 필드의 값을 사용, (예)"102f"

- DateOfIssueTime: string: 1..1: 증명서의 발급일로서 증명서발급일(DateOfIssue) 필드의 값을 사용, (예)"20060918160955Z"

- DateOfExpirationTime: string: 1..1: 증명서의 효력만기일로서 증명서효력만기일(DateOfExpiration) 필드의 값을 사용, (예)"20060918160955Z"

- CertRequester: 0..1: 증명서 요청자 정보로서 증명서 요청자 정보가 NULL인 증명서에 대한 응답메시지인 경우는 생성하지 않도록 함

- ID: string: 0..1: 증명서 요청자 ID

- Name: string: 1..1: 증명서 요청자 실명

- DN : string: 0..1: 증명서 요청자 인증서 DN

- CertType: string: 1..1: 증명서의 종류로서 등록증명서("0"), 발급증명서("1"), 이관증명서("2"), 폐기증명서("3"), 원본증명서("4")의 값을 가짐

- Aip: 1..1: 관련 AIP 패키지 정보

- FileIdList : 1..1: FileId의 리스트

- [속성]FileIdCount: nonNegativeInteger: 필수: FileId의 개수

- Dip: 0..1: 관련 DIP 패키지 정보

- FileIdList : 1..1: FileId의 리스트

- [속성]FileIdCount: nonNegativeInteger: 필수: FileId의 개수

- UsageType: string: 0..1: 증명서의 용도로서 증명서 용도(usageType) 확장필드의 값을 BIT STRING 표현방식과 유사한 방법으로 표현, (예)online(0)과 paperEnable이 설정되었다면 "101"로 표기, mobile만 설정되었다면 "01"로 표기

- Nominee: 0..1: 증명서의 수임자 정보이며 Name과 DN중에 하나는 반드시 생성되어야 함

- ID: string: 0..1: 수임자 ID

- Name: string: 0..1: 수임자 실명

- DN : string: 0..1: 수임자 인증서 DN

- IsRevoked: string: 1..1: 증명서의 폐지여부로서 정상("0"), 폐지("1")의 값을 가짐

ⓓ 이용자 검색요청 메시지(UserList) 경우

- UserList: 1..1: 이용자 검색 결과

- [속성]recordCount: nonNegativeInteger: 필수: User의 개수

- User: 0..∞: 검색된 이용자

- OrganizationOrPerson: string: 1..1: 기관("0"), 개인("1")의 값을 가짐

- ID: string: 1..1: 이용자 ID

- Name: string: 1..1: 이용자 실명

- DN : string: 1..1: 이용자 인증서 DN

한편, 전자문서 보관소 서버(130)는 HTTP 기반의 SOAP을 사용한 연계 인터페이스 이외에, 이용자의 서비스 요청에 대하여 비동기식으로 처리하는 절차나 시스템을 추가적으로 구축할 수 있다. 물론 이 방식은 반드시 이용자와 사전에 협의가 되어야 하며, 연계 인터페이스를 위한 표준 메시지 구조를 준용하여야 한다. 일반적으로 비동기식 처리란, 이용자가 보내온 요청 메시지에 대하여 검증 작업만을 수행한 후 응답 메시지를 리턴하도록 하고, 실제 처리 작업은 비동기적으로 수행하여 이용자와 사전에 협의된 방식으로 처리 결과를 이용자에게 전달하는 절차를 의미한다. 이러한 비동기식 처리 방식은 메시지 송수신 과정에서의 기밀성, 무결성, 부인방지를 위한 기술 등의 적용이 요구된다.

비동기식 처리에 따른 전자문서 관리 시스템(100)의 운용 방법은 다음과 같이 진행된다. 이하, 도 8을 참조하여 설명한다. 먼저, 이용자 단말기(110)를 통해 이용자의 요청이 접수되면, 이용자 서버(120)의 내부 시스템 모듈(200)은 이 요청을 근거로 인터페이스를 호출한다(S800). 이후, 제1 연계 인터페이스 모듈(210)의 요청 메시지 생성부(211)는 내부 시스템 모듈(200)에서 제공된 요청 정보를 토대로 요청 메시지를 생성한다(S805). 이후, 제1 통신부(214)는 제1 제어부(217)의 제어에 따라 요청 메시지를 전자문서 보관소 서버(130)로 전송한다(S810).

이후, 제2 연계 인터페이스 모듈(260)의 제2 메시지 검증부(268)가 제2 통신부(264)를 통하여 상기 요청 메시지를 수신하고, 수신된 요청 메시지를 검증한다(S815). 검증결과 Success이면, 응답 메시지 생성부(261)는 요청 메시지에 대한 수신확인 메시지를 구성한다(S820). 그러면, 제2 통신부(264)는 제2 제어부(267)의 제어에 따라 상기 수신확인 메시지를 이용자 서버(120)로 전송한다(S825). 한편, 검증결과 fail이면, 응답 메시지 생성부(261)는 해당 사유를 토대로 에러 메시지를 구성한다(S830). 이후, S825 단계가 진행됨은 물론이며, 이후의 비동기식 처리과정은 더이상 수행되지 않는다.

한편, 검증된 요청 메시지는 제2 제어부(267)에 의해 보관소 엔진 모듈(250)에 제공되며, 보관소 엔진 모듈(250)은 문서등록, 검색, 문서발급 등 요청을 처리한다(S835). 이후, 응답 메시지 생성부(261)는 보관소 엔진 모듈(250)의 처리결과를 토대로 응답 메시지를 생성한다(S840). 그러면, 제2 제어부(267)는 제2 통신부(264)를 통하여 사전에 이용자와 협의된 방식으로 상기 응답 메시지를 이용자 서버(120)(또는 이용자 단말기(110))에 제공한다(S845). 본 발명의 실시예에서 전자문서 보관소 서버(130)가 처리결과를 포함하는 응답 메시지를 비동기적으로 전달하는 절차 또는 방식은 제한되지 않는다. 따라서, 이 경우 HTTP, FTP, E-mail, 자체 구현한 송수신 프로토콜 등을 이용한 ON-LINE 방식, CD나 TAPE 등의 저장매체를 통한 OFF-LINE 방식 등 어떠한 것이 적용되어도 무방하다. 한편, 상기에서 동기식 처리단계(S800~S830)나 비동기식 처리단계(S835~S845) 모두 상술한 연계 인터페이스를 위한 표준 메시지 구조에 따른 응답 메시지 포맷을 준용함은 물론이다.

한편, 전송보안을 고려할 경우, 전자문서 보관소 서버(130)가 이용자 서버(120)(또는 이용자 단말기(110))에 작업 처리결과를 전달할 때 해당 메시지에는 기밀성, 무결성, 부인방지를 위한 기술이 적용되어 있어야 한다. 특히, OFF-LINE 방식의 경우에는 전달 과정 중에 전달 메시지의 내용이 유출될 가능성이 크기 때문에 반드시 정당한 이용자만이 메시지의 내용을 확인할 수 있는 기밀성 유지 방법을 적용하여야 한다. 또한, ON-LINE 방식과는 달리 전달 과정에 대한 감사기록이 남지 않기 때문에 작업 처리결과를 정당한 수신자에게 전달하였음에 대한 증빙자료를 전자문서 보관소 서버(130) 측에서 확보하여 유지하여야 함은 물론이다.

한편, 상술한 본 발명의 실시예들은 컴퓨터에서 실행될 수 있는 프로그램으로 작성 가능하고, 컴퓨터로 읽을 수 있는 기록매체를 이용하여 상기 프로그램을 동작시키는 범용 디지털 컴퓨터에서 구현될 수 있다. 상기 컴퓨터로 읽을 수 있는 기록매체는 마그네틱 저장매체(예를 들면, ROM, 플로피 디스크, 하드 디스크 등), 광학적 판독 매체(예를 들면, CD-ROM, DVD 등) 및 캐리어 웨이브(예를 들면, 인터넷을 통한 전송)와 같은 저장매체를 포함한다.

이상의 설명은 본 발명의 기술사상을 예시적으로 설명한 것에 불과한 것으로서, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자라면 본 발명의 본질적인 특성에서 벗어나지 않는 범위 내에서 다양한 수정, 변경 및 치환이 가능할 것이다. 따라서, 본 발명에 개시된 실시예 및 첨부된 도면들은 본 발명의 기술사상을 한정하기 위한 것이 아니라 설명하기 위한 것이고, 이러한 실시예 및 첨부된 도면에 의하여 본 발명의 기술사상의 범위가 한정되는 것은 아니다. 본 발명의 보호범위는 아래의 청구범위에 의하여 해석되어야 하며, 그와 동등한 범위 내에 있는 모든 기술사상은 본 발명의 권리범위에 포함되는 것으로 해석되어야 할 것이다.

본 발명에 따르면 통신 보안이 더욱 고려됨에 따라 전자문서 보관소 측이 제공하는 서비스에 대한 이용자의 이용은 더욱 늘어날 것이며, 이에 따라 전자문서 보관소 측의 인지도는 향상될 것이다. 향후 각종 문서가 전자문서화됨이 더욱 가속화될 전망이므로 본 발명에 따르는 서비스는 큰 신뢰성 부여를 통해 많은 이용이 짐작되며, 더불어 표준으로써 자리잡게 된다면 업계 서비스의 동일성을 창출할 것 이며, 이에 따라 그 이용은 더욱 배가될 것이다.

도 1은 본 발명의 바람직한 실시예에 따른 전자문서 관리 시스템의 전체적인 구성을 개략적으로 설명한 개념도,

도 2는 본 발명의 바람직한 실시예에 따른 이용자 서버와 전자문서 보관소 서버의 내부구성을 도시한 블록도,

도 3은 본 발명의 바람직한 실시예에 따른 전자문서 관리 시스템의 운용방법을 설명한 순서도,

도 4a 내지 도 4f는 본 발명의 바람직한 실시예에 따른 전자문서 관리 시스템에 있어서, 요청 메시지와 응답 메시지의 패키징 구조를 설명하기 위한 도면,

도 5a 내지 도 5xd는 본 발명의 바람직한 실시예에 따른 전자문서 관리 시스템에 있어서, 연계 인터페이스의 유형에 따른 요청 메시지의 스키마 구조 설정을 설명하기 위한 도면,

도 6a 내지 도 6c는 본 발명의 바람직한 실시예에 따른 전자문서 관리 시스템에 있어서, 연계 인터페이스 모듈의 전송보안을 설명하기 위한 도면,

도 7a 내지 도 7o는 본 발명의 바람직한 실시예에 따른 전자문서 관리 시스템에 있어서, 연계 인터페이스의 유형에 따른 응답 메시지의 스키마 구조 설정을 설명하기 위한 도면,

도 8은 본 발명의 바람직한 또다른 실시예에 따른 전자문서 관리 시스템의 운용방법을 설명한 순서도이다.

< 도면의 주요 부분에 대한 부호의 설명 >

100 : 전자문서 관리 시스템 110 : 이용자 단말기

120 : 이용자 서버 122 : 이용자 데이터베이스

130 : 전자문서 보관소 서버 132 : 전자문서 보관소 데이터베이스

150 : 공인인증기관 서버 200 : 내부 시스템 모듈

250 : 보관소 엔진 모듈

210, 260 : (제1, 제2) 연계 인터페이스 모듈

211, 261 : (요청, 응답) 메시지 생성부

212, 262 : (제1, 제2) 헤더 작성부 213, 263 : (제1, 제2) 패키징부

214, 264 : (제1, 제2) 통신부 215, 265 : (제1, 제2) 보안 처리부

216, 266 : (제1, 제2) 데이터 추출부

217, 267 : (제1, 제2) 제어부 218, 268 : (제1, 제2) 메시지 검증부

Claims

SOAP(Simple Object Access Protocol) 프로토콜을 고려하여 전자문서 또는 전자문서 증명서에 대한 처리 요청을 담은 요청 메시지를 생성 전송하는 제1 연계 인터페이스 모듈, 상기 제1 연계 인터페이스 모듈이 상기 요청의 처리 결과를 담은 응답 메시지를 수신하면 상기 수신된 응답 메시지를 이용자에게 제공하는 내부 시스템 모듈, 상기 응답 메시지에 포함된 전자문서 증명서를 검증하는 전자문서 증명서 검증부, 및 상기 검증된 전자문서 증명서를 위변조 방지되게 출력시키는 전자문서 증명서 출력부를 포함하는 이용자 서버;

상기 이용자 서버와 연계되는 데이터베이스로서, 상기 생성된 요청 메시지 및 상기 수신된 응답 메시지를 미리 정해진 기간동안 삭제하거나 위변조 불가능하게 저장하는 이용자 데이터베이스;

상기 처리 결과를 생성하는 보관소 엔진 모듈, 및 상기 제1 연계 인터페이스 모듈로부터 상기 생성된 요청 메시지가 수신되면 상기 요청을 추출하여 상기 보관소 엔진 모듈로 전송하며 상기 SOAP 프로토콜을 고려하여 상기 생성된 처리 결과를 담은 응답 메시지를 생성하여 상기 제1 연계 인터페이스 모듈로 전송하는 제2 연계 인터페이스 모듈을 포함하는 전자문서 보관소 서버; 및

상기 전자문서 보관소 서버와 연계되는 데이터베이스로서, 상기 생성된 응답 메시지 및 상기 수신된 요청 메시지를 미리 정해진 기간동안 삭제하거나 위변조 불가능하게 저장하는 전자문서 보관소 데이터베이스

를 포함하며,

상기 제2 연계 인터페이스 모듈은, 상기 수신된 요청 메시지가 유효한 메시지인지 여부를 판별하는 보안 처리부; 상기 수신된 요청 메시지가 유효한 메시지로 판별되면, 상기 수신된 요청 메시지가 미리 정해진 메시지 구조를 만족하는지 여부를 판별하는 구조 검증, 상기 수신된 요청 메시지가 훼손되었는지 여부를 판별하는 무결성 검증, 상기 무결성 검증과 함께 수행되거나 상기 무결성 검증전 또는 상기 무결성 검증후 수행되며 상기 수신된 요청 메시지의 전자서명에 사용된 인증서의 유효성을 판별하는 인증, 및 상기 수신된 요청 메시지의 컴포넌트들이 미리 정해진 기준에 부합하는지 여부를 판별하는 내용 검증을 이용하여 상기 유효한 요청 메시지를 검증하는 메시지 검증부; 및 상기 유효한 요청 메시지가 검증된 것이면, 상기 유효한 요청 메시지로부터 상기 요청을 추출하는 데이터 추출부를 포함하고,

상기 제1 연계 인터페이스 모듈은, 상기 수신된 응답 메시지가 유효한 메시지인지 여부를 판별하는 보안 처리부; 상기 수신된 응답 메시지가 유효한 메시지로 판별되면, 상기 수신된 응답 메시지가 미리 정해진 메시지 구조를 만족하는지 여부를 판별하는 구조 검증, 상기 수신된 응답 메시지가 훼손되었는지 여부를 판별하는 무결성 검증, 상기 무결성 검증과 함께 수행되거나 상기 무결성 검증전 또는 상기 무결성 검증후 수행되며 상기 수신된 요청 메시지의 전자서명에 사용된 인증서의 유효성을 판별하는 인증, 및 상기 수신된 응답 메시지와 상기 요청 메시지를 비교하여 상기 수신된 응답 메시지의 컴포넌트들이 상기 요청 메시지에 적용된 기준에 부합하는지 여부를 판별하는 내용 검증을 이용하여 상기 유효한 응답 메시지를 검증하는 메시지 검증부; 및 상기 유효한 응답 메시지가 검증된 것이면, 상기 유효한 응답 메시지로부터 상기 처리 결과를 추출하는 데이터 추출부를 포함하는 것을 특징으로 하는 전자문서 관리 시스템.
제 1 항에 있어서,

상기 전자문서 증명서는 상기 전자문서 등록을 증명하는 등록 증명서, 상기 전자문서 발급을 증명하는 발급 증명서, 상기 전자문서 이관을 증명하는 이관 증명서, 상기 전자문서 폐기를 증명하는 폐기 증명서, 발급된 전자문서가 보관된 전자문서와 동일한 원본임을 증명하는 원본 증명서, 및 일정 데이터가 특정 시각에 보관되고 있었음을 증명하는 시점확인 증명서 중 하나 이상을 포함하는 것을 특징으로 하는 전자문서 관리 시스템.
제 1 항에 있어서,

상기 이용자 서버는,

상기 요청이 전자문서 원본 발급 요청일 때, 상기 전자문서 원본 발급 요청에 대한 정보를 담은 SIP(Submission Information Package)를 생성하는 SIP 생성부;

상기 SIP에 기인하여 암호화 발급된 DIP(Dissemination Information Package)를 수신하면 상기 DIP를 복호화시키는 DIP 복호화부; 및

상기 SIP와 상기 DIP를 포함하는 전자문서 패키지를 위변조 방지되게 출력시키는 전자문서 패키지 출력부

를 더욱 포함하는 것을 특징으로 하는 전자문서 관리 시스템.
제 1 항에 있어서,

상기 보관소 엔진 모듈이 생성하는 처리 결과는 상기 전자문서 등록, 상기 전자문서 발급, 상기 전자문서 폐기, 상기 전자문서 보관연장, 상기 전자문서 이관, 상기 전자문서 증명서 발급, 상기 전자문서 증명서 갱신발급, 상기 전자문서 증명서 검증, 상기 전자문서 증명서 다운로드, 상기 전자문서 검색, 및 상기 전자문서 증명서를 사용한 상기 전자문서의 발급 중 어느 하나인 것을 특징으로 하는 전자문서 관리 시스템.
제 1 항에 있어서,

상기 제1 연계 인터페이스 모듈은,

상기 요청을 SOAP 메시지의 바디 부분에 생성하는 요청 메시지 생성부;

메시지 보안 구조를 상기 SOAP 메시지의 헤더 부분에 삽입시키는 헤더 작성부;

상기 생성된 SOAP 메시지 및 첨부 파일을 Multi-MIME 형식으로 패키징시키는 패키징부; 및

상기 패키징을 통해 완성된 상기 요청 메시지를 상기 전자문서 보관소 서버로 송신하며, 상기 전자문서 보관소 서버로부터 상기 응답 메시지를 수신하는 통신부

를 포함하는 것을 특징으로 하는 전자문서 관리 시스템.
제 1 항에 있어서,

상기 제2 연계 인터페이스 모듈은,

상기 생성된 처리 결과를 SOAP 메시지의 바디 부분에 생성하는 응답 메시지 생성부;

메시지 보안 구조를 상기 SOAP 메시지의 헤더 부분에 삽입시키는 헤더 작성부;

상기 생성된 SOAP 메시지 및 첨부 파일을 Multi-MIME 형식으로 패키징시키는 패키징부; 및

상기 패키징을 통해 완성된 상기 응답 메시지를 상기 이용자 서버로 송신하며, 상기 이용자 서버로부터 상기 요청 메시지를 수신하는 통신부

를 포함하는 것을 특징으로 하는 전자문서 관리 시스템.
삭제
삭제
이용자의 요청에 따라 구동하는 이용자 서버;

상기 이용자 서버와 연계되는 데이터베이스인 이용자 데이터베이스;

상기 이용자 서버의 요청을 처리하는 전자문서 보관소 서버; 및

상기 전자문서 보관소 서버와 연계되는 데이터베이스인 전자문서 보관소 데이터베이스

를 포함하며,

(a) 전자문서 또는 전자문서 증명서에 대한 처리 요청이 수신되면, 상기 이용자 서버의 제1 연계 인터페이스 모듈이 SOAP(Simple Object Access Protocol) 프로토콜을 고려하여 상기 처리 요청을 담은 요청 메시지를 생성 전송하는 단계;

(b) 상기 이용자 서버가 상기 이용자 데이터베이스에 상기 생성된 요청 메시지를 미리 정해진 기간동안 삭제하거나 위변조 불가능하게 저장하는 단계;

(c) 상기 전자문서 보관소 서버의 제2 연계 인터페이스 모듈이 수신된 상기 요청 메시지가 유효한 메시지인지 여부를 판별하는 단계;

(d) 상기 수신된 요청 메시지가 유효한 메시지로 판별되면, 상기 제2 연계 인터페이스 모듈이 상기 수신된 요청 메시지가 미리 정해진 메시지 구조를 만족하는지 여부를 판별하는 구조 검증, 상기 수신된 요청 메시지가 훼손되었는지 여부를 판별하는 무결성 검증, 상기 무결성 검증과 함께 수행되거나 상기 무결성 검증전 또는 상기 무결성 검증후 수행되며 상기 수신된 요청 메시지의 전자서명에 사용된 인증서의 유효성을 판별하는 인증, 및 상기 수신된 요청 메시지의 컴포넌트들이 미리 정해진 기준에 부합하는지 여부와 상기 생성된 처리 결과가 상기 요청 내용에 부합하는지 여부를 판별하는 내용 검증을 이용하여 상기 유효한 요청 메시지를 검증하는 단계;

(e) 상기 유효한 요청 메시지가 검증된 것이면, 상기 제2 연계 인터페이스 모듈이 상기 유효한 요청 메시지로부터 상기 요청을 추출하는 단계;

(f) 상기 전자문서 보관소 서버의 보관소 엔진 모듈이 상기 추출된 요청에 대한 처리 결과를 생성하는 단계;

(g) 상기 제2 연계 인터페이스 모듈이 상기 SOAP 프로토콜을 고려하여 상기 생성된 처리 결과를 담은 응답 메시지를 생성 전송하는 단계;

(h) 상기 전자문서 보관소 서버가 상기 전자문서 보관소 데이터베이스에 상기 생성된 응답 메시지를 미리 정해진 기간동안 삭제하거나 위변조 불가능하게 저장하는 단계;

(i) 상기 제1 연계 인터페이스 모듈이 수신된 상기 응답 메시지가 유효한 메시지인지 여부를 판별하는 단계;

(j) 상기 수신된 응답 메시지가 유효한 메시지로 판별되면, 상기 제1 연계 인터페이스 모듈이 상기 수신된 응답 메시지가 미리 정해진 메시지 구조를 만족하는지 여부를 판별하는 구조 검증, 상기 수신된 응답 메시지가 훼손되었는지 여부를 판별하는 무결성 검증, 상기 무결성 검증과 함께 수행되거나 상기 무결성 검증전 또는 상기 무결성 검증후 수행되며 상기 수신된 요청 메시지의 전자서명에 사용된 인증서의 유효성을 판별하는 인증, 및 상기 수신된 응답 메시지와 상기 요청 메시지를 비교하여 상기 수신된 응답 메시지의 컴포넌트들이 상기 요청 메시지에 적용된 기준에 부합하는지 여부를 판별하는 내용 검증을 이용하여 상기 유효한 응답 메시지를 검증하는 단계;

(k) 상기 유효한 응답 메시지가 검증된 것이면, 상기 제1 연계 인터페이스 모듈이 상기 유효한 응답 메시지로부터 상기 처리 결과를 추출하는 단계;

(l) 상기 이용자 서버의 내부 시스템 모듈이 상기 응답 메시지를 이용자에게 제공하는 단계;

(m) 상기 이용자 서버의 전자문서 증명서 검증부가 상기 응답 메시지에 포함된 전자문서 증명서를 검증하는 단계; 및

(n) 상기 이용자 서버의 전자문서 증명서 출력부가 상기 검증된 전자문서 증명서를 위변조 방지되게 출력시키는 단계

를 포함하는 것을 특징으로 하는 전자문서 관리 시스템의 운용 방법.
제 9 항에 있어서,

상기 (a) 단계에서 상기 제1 연계 인터페이스 모듈이 상기 요청 메시지를 생성 전송하는 것은,

(aa) 상기 제1 연계 인터페이스 모듈의 요청 메시지 생성부가 상기 요청 내용을 SOAP 메시지의 바디 부분에 생성하는 단계;

(ab) 상기 제1 연계 인터페이스 모듈의 헤더 작성부가 메시지 보안 구조를 상기 SOAP 메시지의 헤더 부분에 삽입시키는 단계;

(ac) 상기 제1 연계 인터페이스 모듈의 패키징부가 상기 생성된 SOAP 메시지 및 첨부 파일을 Multi-MIME 형식으로 패키징시키는 단계; 및

(ad) 상기 제1 연계 인터페이스 모듈의 통신부가 상기 패키징을 통해 완성된 상기 요청 메시지를 상기 전자문서 보관소 서버로 전송하는 단계

를 포함하는 것을 특징으로 하는 전자문서 관리 시스템의 운용 방법.
제 9 항에 있어서,

상기 (a) 단계에서 수신되는 처리 요청은 상기 전자문서 등록, 상기 전자문서 발급, 상기 전자문서 폐기, 상기 전자문서 보관연장, 상기 전자문서 이관, 상기 전자문서 증명서 발급, 상기 전자문서 증명서 갱신발급, 상기 전자문서 증명서 검증, 상기 전자문서 증명서 다운로드, 상기 전자문서 검색, 및 상기 전자문서 증명서를 사용한 상기 전자문서의 발급 중 어느 하나인 것을 특징으로 하는 전자문서 관리 시스템의 운용 방법.
삭제
삭제
제 9 항에 있어서,

상기 (a) 단계에서 처리 요청하는 전자문서 증명서는 상기 전자문서 등록을 증명하는 등록 증명서, 상기 전자문서 발급을 증명하는 발급 증명서, 상기 전자문서 이관을 증명하는 이관 증명서, 상기 전자문서 폐기를 증명하는 폐기 증명서, 발급된 전자문서가 보관된 전자문서와 동일한 원본임을 증명하는 원본 증명서, 및 일정 데이터가 특정 시각에 보관되고 있었음을 증명하는 시점확인 증명서 중 적어도 하나를 포함하는 것을 특징으로 하는 전자문서 관리 시스템의 운용 방법.
삭제
삭제
삭제
삭제
컴퓨터로 판독 가능한 기록매체에 있어서,

제 9 항 내지 제 11 항, 및 제 14 항 중 어느 한 항에 따른 방법을 구현하는 프로그램이 저장되는 기록매체.