KR100969313B1 - 전자문서 증명서 발급 방법 및 이를 위한 전자문서 보관시스템, 상기 방법을 구현하는 프로그램이 저장된 기록매체 - Google Patents

Abstract

본 발명은 전자문서에 대한 각종 증명서를 발급하거나 검증하는 기술에 관련한 전자문서 증명서 발급 방법 및 이를 위한 전자문서 보관 시스템, 상기 방법을 구현하는 프로그램이 저장된 기록매체에 관한 것이다. 본 발명은 (a) 증명서 발급을 요청하는 증명서 요청 메시지를 생성하며, 증명서 요청 메시지를 전송하는 단계; (b) 증명서 요청 메시지에서 증명의 대상이 되는 증적을 검색하는 단계; (c) 증명서 요청 메시지와 검색된 증적을 근거로 증명서 발급을 시도하는 단계; 및 (d) 증명서 발급에 성공한 경우, 증명서를 포함하는 증명서 응답 메시지를 생성하고 증명서 응답 메시지를 전송하며, 증명서 발급에 실패한 경우, 원인을 포함하는 에러 메시지를 생성하고 에러 메시지를 전송하는 단계를 포함하는 것을 특징으로 하는 전자문서 증명서 발급 방법을 제공한다. 본 발명에 의하면, 전자문서 보관소가 증명서를 발급함에 있어서 투명하고 효율적인 발급 서비스를 제공하고, 증명서의 호환성 확보로 인한 증명 서비스의 확대 및 서비스의 신뢰성을 제공할 수 있게 된다.

전자문서 증명서, 전자문서, 증명서 발급, 증명서 검증, 전자문서 보관소, 공인인증기관(CA), 무결성 검증, 증적

Description

전자문서 증명서 발급 방법 및 이를 위한 전자문서 보관 시스템, 상기 방법을 구현하는 프로그램이 저장된 기록매체 {Method for issuing certificate of electric filing document, and system for storing certificate of electric filing document therefor, and the recording media storing the program performing the said method}

본 발명은 전자문서 증명서 발급 방법 및 이를 위한 전자문서 보관 시스템, 상기 방법을 구현하는 프로그램이 저장된 기록매체에 관한 것이다. 보다 상세하게는, 전자문서에 대한 각종 증명서(구체적으로, 등록 증명서, 발급 증명서, 이관 증명서, 폐기 증명서, 원본 증명서 및 시점확인 증명서)를 발급하거나 검증하는 기술에 관련한 전자문서 증명서 발급 방법 및 이를 위한 전자문서 보관 시스템, 상기 방법을 구현하는 프로그램이 저장된 기록매체에 관한 것이다.

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

그런데, 종래에는 이러한 전자문서에 대해 진위여부를 가늠할 수 있는 증명서가 제대로 갖추어지지 못했다. 이로 인해, 해킹 등을 통해 전자문서를 위조하거나 변조시키는 경우에는 적절한 대처가 이루어지지 못해 사용자로 하여금 전자문서 자체에 의구심을 가지게 하는 현상까지 발생하였다.

한편, 전자문서 증명서에 관한 선행발명으로는 대한민국 특허공개공보 제2006-110955호(발명의 명칭 : 전자문서 내용증명 시스템의 내용증명서 갱신방법 및 그 갱신된 내용증명서의 검증방법)가 있다. 그러나, 이 발명에 기재된 전반적인 내용은 전자문서의 효력을 연장시키기 위한 것으로서 전자문서의 진위여부를 판단하는 증명서 역할에 대해서는 언급된 바가 없다. 또한, 이 발명에는 검증 방법에 대한 내용도 담고 있는데, 이 검증 방법은 DVCS(Data Validation and Certification Server: 데이터 검증 및 인증 서버) 서비스를 고려한 것으로(상기 특허 청구항 제4항의 내용 참조), 데이터 유효성을 검증하는 데에 한정된다. 따라서, 이 검증 방법만으로 검증이 충분히 이루어졌다고 하기에는 곤란하다.

본 발명은 상술한 문제점을 해결하기 위해 안출된 것으로서, 전자문서의 진위여부를 판단하는 증명서를 발급하거나 검증하는 기술에 관련한 전자문서 증명서 발급 방법 및 이를 위한 전자문서 보관 시스템, 상기 방법을 구현하는 프로그램이 저장된 기록매체를 제공함을 목적으로 한다.

또한, 본 발명은 전자문서의 다양한 용도에 대한 증명서(구체적으로, 등록 증명서, 발급 증명서, 이관 증명서, 폐기 증명서, 원본 증명서 및 시점확인 증명서)를 발급하거나 검증하는 기술에 관련한 전자문서 증명서 발급 방법 및 이를 위한 전자문서 보관 시스템, 상기 방법을 구현하는 프로그램이 저장된 기록매체를 제공함을 목적으로 한다.

또한, 본 발명은 증명서 유효성 검증 절차와 증명서 내용 검증 절차를 통해 발급된 증명서를 검증하는 기술에 관련한 전자문서 증명서 발급 방법 및 이를 위한 전자문서 보관 시스템, 상기 방법을 구현하는 프로그램이 저장된 기록매체를 제공함을 목적으로 한다.

본 발명은 상술한 목적을 달성하기 위해 안출된 것으로서, 전자문서를 증명하는 증명서를 발급하는 방법에 있어서, (a) 상기 증명서 발급을 요청하는 증명서 요청 메시지를 생성하며, 상기 증명서 요청 메시지를 전송하는 단계; (b) 상기 증명서 요청 메시지에서 증명의 대상이 되는 증적을 검색하는 단계; (c) 상기 증명서 요청 메시지와 상기 검색된 증적을 근거로 상기 증명서 발급을 시도하는 단계; 및 (d) 상기 증명서 발급에 성공한 경우, 상기 증명서를 포함하는 증명서 응답 메시지를 생성하고 상기 증명서 응답 메시지를 전송하며, 상기 증명서 발급에 실패한 경우, 원인을 포함하는 에러 메시지를 생성하고 상기 에러 메시지를 전송하는 단계를 포함하는 것을 특징으로 하는 전자문서 증명서 발급 방법을 제공한다.

바람직하게는, 상기 증명서는 상기 전자문서 등록을 증명하는 등록 증명서, 상기 전자문서 발급을 증명하는 발급 증명서, 상기 전자문서 이관을 증명하는 이관 증명서, 상기 전자문서 폐기를 증명하는 폐기 증명서, 발급된 전자문서가 보관된 전자문서와 동일한 원본임을 증명하는 원본 증명서, 및 일정 데이터가 특정 시각에 존재하였음을 증명하는 시점확인 증명서 중 하나 이상인 것을 특징으로 한다.

바람직하게는, 상기 (c) 단계에서는 저장된 증명서 정책을 이용하는 것을 특징으로 한다.

더 바람직하게는, 상기 증명서가 상기 등록 증명서인 경우, 최초 발급에 한하여 상기 증명서 요청 메시지 수신 없이 상기 등록 증명서를 담은 상기 증명서 응답 메시지를 생성 전송하는 것을 특징으로 한다.

더 바람직하게는, 상기 증명서가 상기 원본 증명서인 경우 상기 (b) 단계에서는, 전자문서 원본 이외에 추가로 상기 원본과 동일한 구성을 가지는 변환본에 대한 원본 증명서를 발급하는 것을 특징으로 한다.

더 바람직하게는, 상기 증명서가 상기 원본 증명서인 경우, 상기 (d) 단계에서 생성되는 증명서 응답 메시지는 DIP(Dissemination Information Packages)에 포 함되는 형태인 것을 특징으로 한다.

더 바람직하게는, 상기 증명서가 상기 시점확인 증명서인 경우, 상기 (a) 단계에서의 증명서 요청 메시지는 데이터 해쉬값을 포함하는 것을 특징으로 한다.

더 바람직하게는, 상기 증명서가 상기 시점확인 증명서, 상기 발급 증명서, 상기 이관 증명서 및 상기 폐기 증명서 중 하나 이상인 경우 상기 (a) 단계와 상기 (b) 단계의 중간 단계에서, 상기 증명서 요청 메시지의 무결성을 검증하는 것을 특징으로 한다.

더 바람직하게는, 상기 증명서가 상기 발급 증명서, 상기 이관 증명서 및 상기 폐기 증명서 중 하나 이상인 경우 상기 (b) 단계에서는, 상기 증명서 요청 메시지를 근거로 기존 증적이 있는지를 검색하는 것을 특징으로 한다.

바람직하게는, 상기 (d) 단계에서의 상기 증명서 응답 메시지는 발급한 전자문서를 포함하는 것을 특징으로 한다.

또한, 본 발명은 전자문서와 상기 전자문서에 대한 증명서를 취급하는 전자문서 보관 시스템에 있어서, 전자문서의 등록을 요청하는 자가 접속하는 이용자 단말기; 상기 증명서를 요청하는 자가 접속하는 요청자 단말기; 상기 요청을 표시하는 증명서 요청 메시지에서 증명의 대상이 되는 증적을 검색하며, 상기 증명서 요청 메시지와 상기 검색된 증적을 근거로 상기 증명서를 포함하는 증명서 응답 메시지를 생성 전송하는 전자문서 보관소 서버; 및 상기 이용자 단말기 또는 상기 요청자 단말기와 상기 전자문서 보관소 서버 사이에서 공인인증을 하는 공인인증기관 서버를 포함하는 것을 특징으로 하는 전자문서 보관소 시스템을 제공한다.

바람직하게는, 상기 전자문서 보관소 시스템은 상기 전자문서나 상기 증명서를 수임하는 자가 접속하는 수임자 단말기를 더 포함하되, 상기 수임자 단말기는 상기 이용자 단말기, 상기 요청자 단말기 및 제3자가 접속하는 제3자 단말기 중 어느 하나인 것을 특징으로 한다.

바람직하게는, 상기 전자문서 보관소 서버는 상기 증명서 응답 메시지 생성에 실패할 경우 원인을 포함하는 에러 메시지를 생성 전송하는 것을 특징으로 한다.

바람직하게는, 상기 전자문서 보관소 서버가 생성하는 증명서는 상기 전자문서 등록을 증명하는 등록 증명서, 상기 전자문서 발급을 증명하는 발급 증명서, 상기 전자문서 이관을 증명하는 이관 증명서, 상기 전자문서 폐기를 증명하는 폐기 증명서, 발급된 전자문서가 보관된 전자문서와 동일한 원본임을 증명하는 원본 증명서, 및 일정 데이터가 특정 시각에 존재하였음을 증명하는 시점확인 증명서 중 하나 이상인 것을 특징으로 한다.

바람직하게는, 상기 전자문서 보관소 서버는 상기 증명서 응답 메시지에 발급한 전자문서를 포함시키는 것을 특징으로 한다.

바람직하게는, 상기 전자문서 보관 시스템은 상기 전자문서 보관소 서버에 의해 운용되며, 상기 전자문서, 상기 증명서 및 상기 증적 중 하나 이상을 저장하는 전자문서 보관소 데이터베이스를 더 포함하되, 상기 전자문서 보관소 데이터베이스는 WORM(Write Once Read Many) 기능을 구비하는 것을 특징으로 한다.

더 바람직하게는, 상기 전자문서 보관소 서버는 상기 증명서 요청 메시지를 수신하고, 상기 증명서 응답 메시지나 상기 에러 메시지를 송신하는 통신부; 상기 전자문서를 등록하고, 상기 전자문서 등록에 대한 증적을 생성하며, 상기 등록 증명서를 생성하는 등록 관리부; 상기 증명서 응답 메시지나 상기 에러 메시지를 생성하는 메시지 생성부; 상기 전자문서를 발급하고, 상기 전자문서 발급사실에 대한 증적을 생성하며, 상기 원본 증명서를 생성하는 발급 관리부; 상기 증명서 요청 메시지의 무결성을 검증하는 무결성 검증부; 상기 증명서 요청 메시지에 포함된 데이터 해쉬값을 근거로 상기 시점확인 증명서를 생성하는 시점확인 관리부; 상기 증명서 요청 메시지를 근거로 기존 증적이 있는지를 검색하는 증적 검색부; 상기 증적 검색부가 검색한 증적을 근거로 상기 발급 증명서, 상기 이관 증명서 및 상기 폐기 증명서 중 하나 이상을 생성하는 기타 관리부; 및 상기 전자문서 보관소 데이터베이스를 연동시키며, 상기 통신부와 상기 등록 관리부와 상기 메시지 생성부와 상기 발급 관리부와 상기 무결성 검증부와 상기 시점확인 관리부와 상기 증적 검색부와 상기 기타 관리부의 전체 작동을 제어하는 중앙처리부를 포함하는 것을 특징으로 한다.

바람직하게는, 상기 전자문서 보관소 서버가 처리하는 상기 증명서 요청 메시지와 상기 전자문서 보관소 서버가 생성하는 상기 증명서 응답 메시지는 ASN.1(Abstract Syntax Notation One), BER(Basic Encoding Rules) 및 DER(Distinguished Encoding Rules) 중 어느 하나의 방식으로 인코딩하는 IETF RFC 3852 CMS(Cryptographic Message Syntax) 구조를 형성하는 것을 특징으로 한다.

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

본 발명은 상술한 목적 및 구성에 따라 다음과 같은 효과를 발생시킨다. 첫째, 표준화된 증명 요청서 및 증명서의 프로파일을 정의함으로써 전자문서 보관소가 증명서를 발급함에 있어서 투명하고 효율적인 발급 서비스를 제공하고, 증명서의 호환성 확보로 인한 증명 서비스의 확대 및 서비스의 신뢰성을 제공할 수 있게 한다. 둘째, 증명서의 표준화된 검증 방법을 정의함으로써 증명서의 활용을 활성화시키고, 나아가 편리하면서도 검증력 향상을 통해 신뢰할 수 있는 시스템의 구축을 실현시킨다.

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

도 1은 본 발명의 바람직한 실시예에 따른 전자문서 보관 시스템의 전체 구성을 개략적으로 도시한 개념도이다. 상기 도 1에 도시된 바에 따르면, 본 발명의 바람직한 실시예에 따른 전자문서 보관 시스템(100)은 이용자(user)가 접속하는 이용자 단말기(110), 증명서 요청자(requester)가 접속하는 증명서 요청자 단말기(115), 증명서 수임자(nominee)가 접속하는 증명서 수임자 단말기(120), 상기 단말기들(110 내지 120)과 네트워크 연결되는 전자문서 보관소 서버(130), 전자문서 보관소 데이터베이스(135) 및 공인인증기관(CA; Certificate Authority) 서버(150)를 포함하여 이루어진다.

상기에서, 편의상 특정 업무을 요청하는 주체에 따라 이용자 단말기(110), 증명서 요청자 단말기(115), 증명서 수임자 단말기(120) 등으로 구분하였으나, 이용자나 증명서 요청자가 동시에 증명서 수임자가 될 수도 있으므로 이들 단말기를 통일시켜 단일한 사용자 단말기로써 구현할 수 있음은 물론이다. 이는 곧, 하나의 사용자 단말기에서 이용자, 증명서 요청자, 증명서 수임자 각각이 전자문서 보관소 서버(130)에 업무를 요청하고 제공받을 수 있음으로 이해하면 될 것이다.

이용자 단말기(110)는 이용자가 접속하는 단말기로서, 전자문서 보관소 서버(130)에 전자문서 보관 등 업무를 이용하는 주체 역할을 한다. 구체적으로, 이용자 단말기(110)는 전자문서의 등록, 폐기, 이관, 발급 등의 일반적인 보관소 서버(130)의 업무를 이용하게 된다. 한편, 이용자 단말기(110)는 요청된 업무의 종류 및 행위에 따라서 증명서 요청자 단말기(115)와 증명서 수임자 단말기(120)로의 전이도 가능하다. 상기에서, 전자문서(electric filing document)라 함은 정보처리 시스템에 의하여 전자적 형태로 작성된 정보로서, 신호로써 송수신이 가능하며 전자문서 보관소 서버(130)에 의해 전자문서 보관소 데이터베이스(135)에 저장된다.

증명서 요청자 단말기(115)는 증명서 요청자가 접속하는 단말기로서, 증명서를 요청하는 주체 역할을 한다. 구체적으로, 증명서 요청자 단말기(115)는 증명 요청서를 작성하여 보관소 서버(130)에 제출하고 증명서를 발급받는 기능을 수행한다.

증명서 수임자 단말기(120)는 증명서 수임자가 접속하는 단말기로서, 증명서를 받아 이용하는 주체 역할을 한다. 구체적으로, 증명서 수임자 단말기(120)는 발급받은 증명서를 검증하거나 위임된 권한을 사용하는 기능을 수행한다. 따라서, 증명서 수임자 단말기(120)는 본 발명의 실시예에서 상술한 두 단말기(110, 115) 중 어느 하나가 될 수 있다. 물론, 증명서 수임자 단말기(120)는 제3자가 접속하는 제3자 단말기인 것도 가능하다.

이상, 상술한 이용자 단말기(110), 증명서 요청자 단말기(115) 및 증명서 수임자 단말기(120)는 본 발명의 실시예에서 터미널(terminal) 기능을 하는 휴대폰, PDA, 컴퓨터 등으로 구현될 수 있다. 그러나, 반드시 이에 한정될 필요는 없으며, 입력신호를 발생시키는 키입력부와 출력신호를 표시하는 디스플레이부를 구비하는 소정 형상의 장치라면 충분할 것이다.

전자문서 보관소 서버(130)는 전자문서 증명 업무를 수행하는 주체로서, 본 발명의 실시예에서 그 주된 기능이 증명서의 발급이다. 전자문서 보관소 서버(130)는 요청자 단말기(115)에 의한 증명서 요청에 대하여 증명서를 발급하게 되는데, 증명서의 요청은 요청 및 응답의 프로토콜을 사용한다. 증명서 발급을 포함하여 전자문서 보관소 서버(130)가 본 발명의 실시예에서 수행하는 구체적인 기능은 다음 과 같다.

첫째, 보관소 서버(130)는 전자문서의 등록, 폐기, 이관, 발급 등에 대해 요청 업무를 수행하며, 이에 대한 기록을 증적의 형태로 생성하는 기능을 수행한다. 기록은 무결성을 보장하기 위해 안전하게 보관되며, 등록 기능의 경우에는 추가로 등록 증명서를 발급하게 된다.

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

한편, 보관소 서버(130)가 상술한 증명서들을 발급하는 절차는 도 2 내지 도 6을 참조하여 후술한다.

세째, 보관소 서버(130)는 상술한 각종 증명서를 검증하는 데에 필요한 정보를 제공하는 기능을 수행한다. 증명서 검증은 증명서 검증자(verifier)가 접속하는 증명서 검증자 단말기(미도시)에 의해 이루어지는데, 증명서 검증자 단말기는 본 발명의 실시예에서 요청자 단말기(115) 또는 수임자 단말기(120)일 수 있다. 한편, 검증자 단말기는 필요에 따라 보관소 서버(130)에 특정 데이터를 추가 요청할 수 있다. 이 경우, 보관소 서버(130)는 검증자 단말기가 권한이 있다고 판단되는 경우에 한해 특정 데이터를 제공함이 바람직하다. 한편, 증명서 검증 방법은 후술한다.

전자문서 보관소 데이터베이스(135)는 본 발명의 실시예에서 전자문서 보관소 서버(130)가 증적의 형태로 생성한 각종 기록(전자문서 포함)을 저장 보관하는 기능을 한다. 이를 위해 이 데이터베이스(135)를 구현하는 저장매체는 WORM(Write Once Read Many) 기능을 가지도록 함이 바람직하다. 그러면, 설정된 보존 기간동안에는 삭제나 위조, 변조 등이 불가능하게 되어 신뢰성이 제고될 수 있다.

공인인증기관 서버(150)는 본 발명의 실시예에서 전자문서 보관소 서버(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" 등의 문헌을 참고할 수 있겠다.

다음으로, 전자문서 보관 시스템(100)을 구성하는 전자문서 보관소 서버(130)를 설명한다. 도 2는 본 발명의 바람직한 실시예에 따른 전자문서 보관 시스템에 있어서, 전자문서 보관소 서버의 내부 구성을 개략 설명한 블록도이다. 도 2를 참조하면, 본 발명의 바람직한 실시예에 따른 전자문서 보관소 서버(130)는 통신부(200), 등록 관리부(205), 메시지 생성부(215), 발급 관리부(220), 무결성 검증부(225), 시점확인 관리부(230), 증적 검색부(235), 기타 관리부(240) 및 중앙처리부(210)를 포함한다. 이에 더하여, 전자문서 보관소 서버(130)가 항시 구동될 수 있도록 전원을 공급하는 전원부(미도시)를 더 구비함은 물론이다. 또한, 전자문서 보관소 서버(130)는 특정 신호를 입력하거나 처리된 결과를 표시할 수 있도록 입력부와 출력부를 더 구비함도 가능하다.

전자문서 보관소 서버(130)는 비록 서버라는 명칭을 사용하였으나 서버 역할을 할 수 있는 통상의 컴퓨터로 구현됨도 가능하다. 따라서, 본 발명에서 사용되는 서버는 서버, 컴퓨터 등을 포함하는 정보처리 능력을 구비한 장치 개념으로 이해해야 할 것이다. 이는 공인인증기관 서버(150)의 경우도 마찬가지다. 한편, 전자문서 보관소 서버(130)를 구성하는 각 구성부(200 내지 240)의 기능은 도 3 내지 도 6에 따른 방법을 설명하면서 함께 기술할 것인 바 여기서는 상세한 설명을 생략한다.

다음으로, 이미 언급한 바와 같이 보관소 서버(130)가 각종 증명서들을 발급하는 절차를 설명한다. 도 3 내지 도 6은 본 발명의 바람직한 실시예에 따른 전자문서 보관 시스템에 있어서, 전자문서 보관소 서버의 증명서 발급 절차를 설명하기 위한 흐름도이다. 이하, 도 3 내지 도 6을 참조하여 설명한다.

① 등록 증명서의 발급

도 3을 참조하면, 제1 단계에서 이용자 단말기(110)는 전자문서 등록을 요청한다. 이 요청은 보관소 서버(130)의 통신부(200)에 수신된다(S300). 제2 단계에서, 보관소 서버(130)의 등록 관리부(205)는 이용자 단말기(110)의 요청에 따라 전자문서를 등록한다(S305). 이후, 등록 관리부(205)는 전자문서 등록에 대한 증적을 생성한다(S310).

제3 단계에서, 보관소 서버(130)의 중앙처리부(210)는 전자문서 및 증적을 보관소 데이터베이스(135)에 저장 보관시킨다(S315). 제4 단계에서, 등록 관리부(205)는 중앙처리부(210)의 제어에 따라 보관소 데이터베이스(135)에 연계된다(S320). 이후, 등록 관리부(205)는 보관소 데이터베이스(135)에 저장된 증명서 정책과 증적을 이용하여 등록 증명서를 생성한다(S325).

제5 단계에서, 메시지 생성부(215)는 등록 증명서를 포함시켜 전자문서 등록 요청에 대한 답신 메시지를 생성한다(S330). 제6 단계에서, 중앙처리부(210)는 생 성된 답신 메시지를 통신부(200)를 통하여 이용자 단말기(110)에 제공한다(S335).

한편, S325 단계에서 등록 관리부(205)가 등록 증명서 생성에 실패하게 되면, 메시지 생성부(215)는 그 원인을 포함하는 에러 메시지를 생성한다(S340). 이후, 중앙처리부(210)는 에러 메시지를 통신부(200)를 통해 이용자 단말기(110)에 전달한다(S345).

한편, 본 발명의 실시예에서 등록 증명서가 최초의 것인 경우에는 이용자 단말기(110)의 별도 요청이 없어도 자동으로 발급되도록 함이 바람직하다.

② 원본 증명서의 발급

도 4를 참조하면, 제1 단계에서 이용자 단말기(110)는 전자문서 발급을 요청한다. 이 요청은 통신부(200)에 수신된다(S400). 제2 단계에서, 보관소 서버(130)의 발급 관리부(220)는 이용자 단말기(110)의 요청에 따라 전자문서 원본을 발급한다(S405). 이후, 발급 관리부(220)는 전자문서 원본 발급 사실에 대한 증적을 생성한다(S410).

제3 단계에서, 중앙처리부(210)는 증적을 보관소 데이터베이스(135)에 저장 보관시킨다(S415). 제4 단계에서, 발급 관리부(220)는 중앙처리부(210)의 제어에 따라 보관소 데이터베이스(135)에 연계된다(S420). 이후, 발급 관리부(220)는 저장된 증명서 정책과 발급된 전자문서 원본을 이용하여 원본 증명서를 생성한다(S425). 한편, 전자문서 원본과 동일한 구성을 가지는 변환본(예컨대, 복사본)이 존재하는 경우, 필요에 따라서는 발급 관리부(220)가 이 변환본에 대한 원본 증명서도 추가로 발급할 수 있다.

제5 단계에서, 메시지 생성부(215)는 DIP에 발급 요청된 전자문서 원본(또는 전자문서 변환본까지 포함)과 원본 증명서를 첨부시킨다(S430). 여기에서, DIP란 배부 정보 패키지(Dissemination Information Packages)로서, 전자문서 보관소 서버(130)가 전자문서를 이용자 단말기(110)에 제공할 때 이용하는 구조를 말한다. 제6 단계에서, 중앙처리부(210)는 DIP를 통신부(200)를 통하여 이용자 단말기(110)에 제공한다(S435).

한편, S425 단계에서 발급 관리부(220)가 원본 증명서 생성에 실패할 경우, 그 이후 과정인 S440 단계와 S445 단계는 S340 단계 및 S345 단계와 동일하다.

한편, 본 발명의 실시예에서 원본 증명서는 각종 전자문서 발급시에 전자문서와 함께 DIP에 첨부되며, 별도의 증명 요청서 없이도 자동으로 이용자 단말기(110)에 발급되게 함이 바람직하다.

③ 시점확인 증명서의 발급

도 5를 참조하면, 제1 단계에서 요청자 단말기(115)는 데이터 해쉬값을 포함하는 증명 요청서를 생성한다(S500). 이후, 요청자 단말기(115)는 증명 요청서를 보관소 서버(130)에 전달한다. 그러면, 통신부(200)가 이를 수신한다(S505). 제2 단계에서, 보관소 서버(130)의 무결성 검증부(225)는 증명 요청서의 무결성을 검증한다(S510). 만약 무결성 검증부(225)가 증명 요청서의 무결성을 확인하지 못하면, 메시지 생성부(215)는 증명 요청서의 무결성을 부정한다는 메시지를 생성한다(S515). 이후, 중앙처리부(210)는 이 메시지를 통신부(200)를 통하여 요청자 단말기(110)에 전달한다(S520). 물론, 증명 요청서의 무결성 부정에 대해 전자문서 보관소 서버(130)가 아무런 조치를 취하지 않음도 무방하다.

제3 단계에서(이 단계를 비롯한 이후 단계는 증명 요청서의 무결성이 긍정됨을 전제로 한 것임), 보관소 서버(130)의 시점확인 관리부(230)는 증명 요청서와 증명 요청서에 기재된 데이터 해쉬값을 이용하여 시점확인 증명서를 생성한다(S525). 제4 단계에서, 중앙처리부(210)는 생성된 시점확인 증명서를 요청자 단말기(115)에 제공한다(S530).

한편, S525 단계에서 시점확인 관리부(230)가 시점확인 증명서 생성에 실패할 경우, 그 이후 과정인 S535 단계와 S540 단계는 S340 단계 및 S345 단계와 동일하다.

④ 기타 증명서(발급 증명서, 이관 증명서, 폐기 증명서 등)의 발급

도 6을 참조하면, 제1 단계에서 요청자 단말기(115)는 증명 요청서를 생성한다(S600). 이후, 요청자 단말기(115)는 증명 요청서를 보관소 서버(130)에 전달한다. 그러면, 통신부(200)가 이를 수신한다(S605). 제2 단계에서, 무결성 검증부(225)는 증명 요청서의 무결성을 검증한다(S610). 만약 무결성 검증부(225)가 증명 요청서의 무결성을 확인하지 못하면, 그 이후 과정인 S615 단계 및 S620 단계는 도 5의 경우와 동일하다.

제3 단계에서(이 역시 도 5의 경우와 동일함), 보관소 서버(130)의 증적 검색부(235)는 중앙처리부(210)의 제어에 따라 보관소 데이터베이스(135)에 연계된다(S625). 이후, 증적 검색부(235)는 증명 요청서를 근거로 증명의 대상이 되는 증적을 검색한다(S630). 제4 단계에서, 보관소 서버(130)의 기타 관리부(240)는 저장 된 증명서 정책, 검색된 증적 및 증명 요청서를 이용하여 기타 증명서를 생성한다(S635).

제5 단계에서, 중앙처리부(210)는 생성된 기타 증명서를 요청자 단말기(115)에 제공한다(S640).

한편, S635 단계에서 기타 관리부(240)가 기타 증명서 생성에 실패할 경우, 그 이후 과정인 S645 단계와 S650 단계는 S340 단계 및 S345 단계와 동일하다.

한편, 도 3 내지 도 6을 참조한 상기 설명에서 두 단말기(110, 115)와 전자문서 보관소 서버(130) 사이에는 3가지 메시지가 송수신된다. 증명서 요청 메시지, 증명서 응답 메시지, 에러 메시지가 바로 그것인데, 증명서 요청 메시지는 두 단말기(110, 115)가 증명서 발급을 위해 생성 또는 요청한 일련의 정보(예컨대, 증명 요청서)를 말한다. 그리고, 증명서 응답 메시지는 증명서 요청 메시지에 대해 그 처리 결과로 전자문서 보관소 서버(130)가 생성하는 일련의 정보(예컨대, 답신 메시지나 DIP)를 말한다. 마지막으로, 에러 메시지는 증명서 응답 메시지의 생성에 실패하였을 경우에 그 원인을 포함하여 생성하는 정보를 말한다. 이하, 이들 메시지에 대해 보다 상세하게 설명한다. 먼저, 증명서 요청 메시지를 설명한다.

증명서 요청 메시지는 전자서명 구조인 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 Abstract Syntax Notation One (ASN.1) : Specification of basic notation", "X690; ITU-T Recommendation X.690 | ISO/IEC 8825-1: Information Technology ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", "CMP; Internet X.509 Public Key Infrastructure Certificate Management Protocol(CMP)(RFC 4210), IETF, 2005", "CMS; Cryptographic Message Syntax(RFC 3852), IETF, 2004" 등의 문헌을 참고할 수 있겠다. 이는 증명서 응답 메시지와 에러 메시지의 경우도 마찬가지이다.

CMS의 signedData 구조는 서명 대상, 서명 인증서, 서명 정보 등으로 구성된다. 이에 따라, 메시지의 내용, 메시지를 생성한 증명서 요청자의 전자서명, 증명서 요청자의 인증서는 각각 encapContentInfo 필드, signerInfos 필드, certificates 필드에 포함되어 구성된다. encapContentInfo 필드는 메시지에서 실제 데이터를 형성하는 ARCCertRequest 구조체를 포함하는 부분으로 무결성의 제공을 위하여 전자서명 되어지는 부분이다. 메시지 컨텐츠의 구별을 위해서 식별자는 id-kiec-arcCertRequest를 사용하게 된다. certificates 필드는 certificate의 집 합으로 증명서 요청자가 메시지 서명에 사용한 인증서를 비롯하여 인증기관의 인증서와 최상위 인증기관 인증서를 포함할 수 있다. certificate의 형식은 공인인증 체계에서 발급하는 형식인 X.509 version 3 인증서를 의미한다. certificates 필드는 선택적으로 사용 가능하지만, 본 발명에서는 증명서 요청자의 인증서를 포함하여 메시지를 생성하도록 한다. signerInfos 필드는 signerInfo의 집합으로 서명자에 대한 정보를 나타내는 필드이다. 증명서 요청자는 메시지의 무결성을 위하여 signerInfo에 증명서 요청자의 전자서명을 포함시킨다. signerInfo는 전자서명, 전자서명 알고리즘 및 속성들을 포함하고 있으며, 증명서 요청자는 CMS 표준에서 언급하고 있는 속성들을 추가적으로 사용할 수 있다.

한편, 증명서 요청 메시지가 ARCCertRequest를 포함하는 signedData의 구조를 가짐은 이미 언급하였다. 이하, 이 구조 메시지의 기본 필드와 확장 필드를 살펴본다.

메시지의 기본 필드는 메시지의 확장 필드(extensions)를 제외한 부분으로 버전, 요청자, 요청 시간, 정책, 증적, 난수 등 메시지 생성에 필요한 필수 정보를 나타낸다. 기본 필드는 메시지에 반드시 포함되어야 하는 정보인데, 이를 위해 ARCCertRequest는 DER 인코딩 방식을 따른다.

다음으로, 기본 필드를 구성하는 각각의 정보를 살펴보면, 먼저 version 필드는 메시지의 버전을 표시한다. target 필드에 targetHash가 사용되면 버전 2를 사용하여야 하며, 그 외의 경우에는 버전 1을 사용하여야 한다.

requester 필드는 증명서 발급을 요청한 주체를 나타낸다. 증명서 요청자는 GeneralName 구조체의 otherName 필드를 이용하여, 증명서 요청자의 실명을 UTF8String으로 인코딩한 값과 증명서 요청자의 식별번호를 두 번 해쉬한 값을 사용하는 것을 기본으로 한다. 증명서 요청자가 사업자인 경우의 실명으로는 사업자명을 사용하며, 식별번호로는 사업자번호를 사용한다. 증명서 요청자가 개인인 경우 식별번호로 주민번호를 사용하게 되는데, 이때 주민번호의 도용을 방지하기 위하여 안전한 난수를 생성하여 주민번호와 연접하여 사용하도록 한다. requester 필드는 한국정보보호진흥원의 "[KCAC.TS.CERTPROF] 전자서명 인증서 프로파일 기술규격"에서 정의된 IdentifyData 구조를 사용하는 공인인증서의 subjectAltName과 비슷한 구조로 되어 있으나, IdentifyData의 userInfo에 한국정보보호진흥원의 "[KCAC.TS.SIVID] 식별번호를 이용한 본인확인 기술규격"에 정의된 VID 구조를 사용하지 않고 본 발명에 적용된 HashedIDNInfo 구조를 사용한다. 한편, 보관소 서버(130)는 증명 요청서를 수신하여 검증하는 과정에서 반드시 requester 필드의 IdentifyData에 대한 검증을 수행해야 한다.

requestTime 필드는 증명서 요청시간을 의미한다. 증명서 요청시간은 증명서 요청자가 메시지를 생성한 시점을 의미하므로 보관소의 업무 수행시점보다는 이후의 시간을 갖는다. 메시지의 증명서 요청시간값이 잘못된 시간이거나 보관소 서버(130)의 시간과 차이가 나는 경우에 보관소 서버(130)는 증명서 발급에 실패한 것으로 처리하고, 증명서 요청자에게 에러 메시지를 전송해야 한다. 증명서 요청시간은 GeneralizedTime 형식을 사용한다.

policy 필드는 증명서 정책을 나타낸다. 증명서 요청자는 발급받고 싶은 증 명서 정책을 선택하여 증명서를 요청할 수 있다. 이 필드는 보관소 서버(130)에 의하여 반드시 검토되어야 하며, 보관소 서버(130)가 정책을 알고 있어야 한다. 정의된 구조 중에 policyQualifiers는 사용하지 않는다.

target 필드는 증명서 요청자가 증명서를 통하여 증명받고자 하는 대상을 포함하는 필드이며, 요청하는 증명서의 종류에 따라 증적의 식별정보 또는 데이터의 해쉬정보로 구성될 수 있다.

targetRecord 필드는 보관소 서버(130)가 제공한 기능에 대한 기록이자 증명서 요청자가 증명서를 통하여 증명받고자 하는 증적의 식별자를 포함한다. 등록 증명서, 발급 증명서, 이관 증명서, 폐기 증명서 중 어느 하나 이상을 발급받기 위한 메시지인 경우는 targetRecord 필드를 사용하여 target 필드를 설정하여야 한다.

serialNo 필드는 보관소 서버(130)가 제공한 기능을 기록한 증적의 식별번호로서, 발급될 증명서의 target 필드에 포함되는 OperationRecord 구조체의 하위 필드인 serialNo 필드와 동일한 값이어야 한다. 보관소 서버(130)는 증적의 serialNo 생성시 순차적으로 증가하는 양의 정수를 사용하여 최대 20byte까지 생성할 수 있어야 하고, 이용자 소프트웨어는 최대 20byte 길이의 serialNo를 처리할 수 있어야 한다.

opType 필드는 보관소 서버(130)가 제공한 기능의 종류, 즉 작업 종류를 의미하며, 역시 발급될 증명서의 target 필드에 포함되는 OperationRecord 구조체의 하위 필드인 opType 필드와 동일한 값이어야 한다. 각 기능의 의미는 다음과 같다.

□ register : 전자문서 등록, issue : 전자문서 발급, transfer : 전자문서 이관, delete : 전자문서 폐기

targetHash 필드는 어떤 데이터가 특정 시각에 존재하였음에 대한 증명을 받고자 할 때 사용되는 필드로서 이는 HashedDataInfo 구조체 형식으로 표현된다. 시점확인 증명서를 발급받기 위한 메시지인 경우는 targetHash 필드를 사용하여 target 필드를 설정하여야 한다.

hashedData 필드는 해쉬 알고리즘인 hashAlg를 사용하여 증명받고자 하는 데이터를 한번 해쉬한 값이다.

nonce 필드는 증명서 요청자가 생성한 임시값을 나타낸다. nonce 필드는 기본적으로 재사용 공격 및 추측 공격 등을 방지하기 위하여 사용된다.

다음으로, 확장 필드를 살펴본다. 확장 필드는 다음과 같은 구조로 되어 있다.

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

Extension ::= SEQUENCE {

extnID OBJECT IDENTIFIER,

critical BOOLEAN DEFAULT FALSE,

extnValue OCTET STRING }

여기에서, Extension은 확장 필드의 종류를 나타내는 extnID와 중요도를 의미하는 critical 그리고 확장 필드의 값을 포함하는 extnValue로 구성된다. 확장 필드의 critical이 TRUE로 설정되어 있을 경우, 보관소 서버(130)는 확장 필드를 반드시 이해하고 처리할 수 있어야 한다.

이하, 확장 필드를 구성하는 각각의 필드에 대해 설명한다. Qualifications 확장필드는 자격부여에 관한 것으로 증명서를 전달받아 이용하는 주체와 위임될 역할에 대한 정보를 나타낸다. 증명서를 전달받아 이용하는 주체가 한정되어야 할 경우에 이 필드를 사용하여 증명서에 대한 수임자를 지정할 수 있다. 이 필드를 사용하여 특정인에게만 유효한 증명서를 생성할 수 있으며, 또한 특정인에게 문서에 대한 접근 권한을 부여할 수 있다. 특정인에게 문서에 대한 접근 권한을 부여하기 위하여 본 필드를 사용한다면 반드시 등록 증명서를 요청하여야 한다. Qualifications 확장필드는 증명서의 수임자 정보인 nomineeInfo와 위임될 역할 또는 권한인 nomineeRole로 이루어진 qualification 필드가 복수개로 나열될 수 있는 구조로 되어있다. 증명서 수임자 정보는 증명서 수임자인 nominee와 증명서 수임자의 인증서 정보인 nomineeCert로 이루어져 있으며, 두 필드 중 하나는 반드시 존재해야 한다. 증명서 수임자가 개인일 경우는 반드시 nomineeCert만을 사용해야 하며, 사업자일 경우는 nominee 필드 또는 nomineeCert 필드 둘다 사용 가능하다. nominee 필드는 수임자의 실명 및 식별번호를 사용하여 requester 필드와 동일한 방법으로 생성한다. nomineeCert 필드는 수임자의 인증서에서 추출한 정보를 사용하여 구성한다.

NomineeRole ::= BIT STRING {

onlyForNominee (0),

readDocument (1),

downloadDocument (2) }

nomineeRole 필드는 수임자의 역할 또는 권한을 나타낸다. 각 bit값의 의미는 다음과 같다.

□ onlyForNominee : 증명서의 정당한 수신자임을 나타낸다.

□ readDocument : 보관소 서버(130)에서 문서를 열람할 수 있음을 나타낸다.

□ downloadDocument : 보관소 서버(130)에서 문서를 다운로드할 수 있음을 나타낸다.

onlyForNominee 값의 경우, 모든 Qualification에 동시에 설정하거나 동시에 해제해야 함에 주의한다. nomineeRole 필드에 readDocument나 downloadDocument 값을 설정할 경우 반드시 targetRecord 필드의 하위 필드인 opType 필드의 값은 register로 설정되어야 한다. 반대로, targetRecord 필드의 하위 필드인 opType 필드의 값이 register가 아닌 경우 nomineeRole 필드에 readDocument나 downloadDocument 값을 설정하지 않아야 한다. 본 필드 생성시 critical의 값은 TRUE로 설정해야 한다.

UsageType 확장필드는 증명서 용도에 관한 것으로서, 증명서의 이용환경 또는 용도에 따른 분류방식을 나타낸다. 증명서 요청자는 UsageType 필드를 사용하여 증명서의 이용환경 또는 용도를 한정할 수 있다. 의미상으로 공존할 수 있다면, 동일한 증명서에 복수의 UsageType을 설정할 수도 있다.

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

UsageType ::= BIT STRING {

online (0),

mobile (1),

paperEnable (2) }

여기에서, 각 bit 값의 의미는 다음과 같다.

□ online : online 환경에서 사용할 수 있음을 나타낸다.

□ mobile : mobile 기기에서 사용할 수 있음을 나타낸다.

□ paperEnable : 종이 증명서로 출력하여 사용할 수 있음을 나타낸다.

이상, 본 필드 생성시 critical의 값은 FALSE로 설정해야 한다.

DateOfExpiration 필드는 증명서 요청자가 증명서의 효력 만기일을 지정할 때 사용한다. 이 필드를 사용하지 않을 경우 보관소 서버(130)가 증명서 정책에서 정의한 유효기간을 사용하여 효력 만기일이 설정된다. 또한, 본 필드의 critical 값이 FALSE이며, 요청한 증명서 효력 만기일이 정책상 효력 만기일을 초과하는 경우, 보관소 서버(130)는 정책상의 유효기간을 사용하여 증명서 효력 만기일을 설정한다. 증명서 효력 만기일은 증명서 요청시간보다 미래이어야 한다. 이상, 본 필드 생성시 critical 값은 TRUE 또는 FALSE가 가능하다.

CertifiedTime 필드는 보증 일시에 관한 것으로서, 전자문서가 등록 시점부터 일정 기간동안 보관소 서버(130)에 보관되어 있었음을 이용자가 보증받기를 원 할 경우, 해당 기간의 마지막 일시를 기술하도록 한다. 보증 일시는 증명서 요청시간보다 미래일 수는 없다. 만약, 본 필드가 포함된 메시지가 정상적으로 처리되어 본 필드와 동일한 값이 설정된 증명서가 발급되었다면, 해당 증명서는 전자문서 등록시점부터 본 필드에 기재된 시점까지 전자문서가 보관소에 보관되어 있었음을 보증하게 된다. 본 필드는 반드시 등록 증명서를 요청할 경우에만 생성되어야 하며, 다른 종류의 메시지에는 포함될 수 없다. 이상, 본 필드 생성시 critical 값은 TRUE로 설정해야 한다.

다음으로, 증명서 응답 메시지(이하, '응답 메시지'로 약칭함)를 설명한다. 증명서 요청에 대하여 보관소 서버(130)는 증명서 발급을 하거나 거부 또는 실패에 대한 정보를 증명서 요청자에게 전달한다. 이하 내용에서는, 증명서 요청에 대하여 증명서 요청자에게 전달하는 응답 메시지의 구조와 증명서 발급 실패에 대한 원인 분류를 한다.

먼저, 응답 메시지의 구조에서, 보관소 서버(130)가 보내는 응답 메시지도 증명서 요청 메시지와 같이 전자서명 구조인 IETF RFC 3852 CMS (Cryptographic Message Syntax)에서 제시하는 ContentInfo 구조체로 표현된 signedData를 사용한다. 따라서, 응답 메시지의 내용은 encapContentInfo에 포함되고, 응답 메시지를 생성한 보관소 서버(130)의 전자서명은 signerInfos에 포함되며, 보관소 서버(130)의 인증서는 certificates에 포함된다.

encapContentInfo 필드는 응답 메시지의 실제 데이터인 ARCCertResponse 구 조체를 포함하는 부분으로 무결성의 제공을 위하여 전자서명 되어지는 부분이다. 응답 메시지 컨텐츠의 구별을 위하여 식별자는 id-kiec-arcCertReseponse를 사용한다. ARCCertResponse 구조체는 증명 정보인 arcCertInfo 또는 에러 정보인 arcErrorNotice를 포함하며, 각각에 대한 정보는 후술한다.

certificates 필드는 certificate의 집합으로 보관소 서버(130)가 응답 메시지 서명에 사용한 인증서를 비롯하여 인증기관의 인증서와 최상위 인증기관 인증서를 포함할 수 있다. certificate의 형식은 공인인증 체계에서 발급하는 형식인 X.509 version 3 인증서를 의미한다. certificates 필드는 선택적으로 사용 가능하지만, 본 발명에서는 보관소 서버(130)의 인증서를 포함하여 응답 메시지를 생성하도록 한다.

signerInfos 필드는 signerInfo의 집합으로 서명자에 대한 정보를 나타내는 필드이다. 보관소 서버(130)는 응답 메시지의 무결성을 위하여 signerInfo에 보관소의 전자서명을 포함한다. signerInfo는 전자서명, 전자서명 알고리즘 및 속성들을 포함하고 있으며, 보관소 서버(130)는 CMS 표준에서 언급하고 있는 속성들을 추가적으로 사용할 수 있다.

응답 메시지에서의 증명서는 ARCCertResponse의 'arcCertInfo'를 포함한 signedData의 구조를 가지며, 증명서 요청 메시지의 경우와 마찬가지로 기본 필드와 확장 필드로 구성된다. 먼저, 기본 필드를 설명하고, 확장 필드는 후술한다.

증명서 기본 필드는 증명서의 확장 필드(extensions)를 제외한 부분으로 버전, 일련번호, 발급자, 발급시간, 만료시간, 정책, 요청자 정보, 증적 등 증명서 생성에 필요한 필수 정보를 나타낸다. 증명서 기본 필드는 증명서에 반드시 포함되어야 하는 정보이다.

ARCCertInfo ::= SEQUENCE {

version [0] EXPLICIT ARCVersion DEFAULT v1,

serialNumber SerialNumber,

issuer GeneralNames,

dateOfIssue GeneralizedTime,

dateOfExpiration DateOfExpiration,

policy ARCCertificatePolicies,

requestInfo RequestInfo,

target TargetToCertify,

extentions [1] EXPLICIT Extensions OPTIONAL }

ARCCertInfo는 DER 인코딩 방식을 따르며, 각각의 항목들은 다음과 같다.

version 필드는 증명서의 버전을 표시한다. target 필드에 dataHash가 사용되면 버전 2를 사용하여야 하며, 그 외의 경우에는 버전 1을 사용하여야 한다.

serialNumber 필드는 보관소 서버(130)가 발급하는 증명서의 일련번호(구체적으로, 식별번호)를 나타낸다. 일련번호는 동일한 번호로 발급되어지면 안되며, 양의 정수값만을 사용하여야 한다. 보관소 서버(130)는 증명서의 일련번호를 최대 20byte까지 생성할 수 있어야 하고, 이용자 소프트웨어는 최대 20byte 길이의 일련번호를 처리할 수 있어야 한다.

issuer 필드는 증명서를 발급하는 주체인 보관소 서버(130)를 의미하며, 작은 의미로는 증명서를 발급하는 증명 시스템을 의미한다. 이는 증명서 발급자 필드를 이용하여 검증하려는 증명서를 발급한 보관소 서버(130)를 식별할 수 있다. issuer 필드는 보관소 서버(130)의 실명 및 식별번호를 사용하여 증명서 요청 메시지의 requester 필드와 동일한 방법으로 생성한다.

dateOfIssue 필드는 보관소 서버(130)가 사용자의 증명서 발급 요청에 대하여 증명서를 생성한 시점(즉, 증명서 발급일)을 표현한다. 증명서 발급일은 GeneralizedTime 형식을 사용한다.

dateOfExpiration 필드는 증명서의 효력 만기일을 의미하며, 일반적으로 증명서 정책을 기반으로 증명서의 효력 만기일이 정해진다. 증명서 요청 메시지(이하, '요청 메시지'로 약술함)에 dateOfExpiration 확장 필드가 존재하고 critical 값이 TRUE인 경우, 보관소 서버(130)는 요청 메시지의 dateOfExpiration 필드의 값을 사용하여 본 필드의 값을 설정해야 한다. 요청 메시지의 dateOfExpiration 필드값이 TRUE이나, 어떤 사유로 요청 메시지의 dateOfExpiration 필드값과 동일하게 설정하지 못하는 경우는 증명서 발급에 실패한 것으로 처리하고, 증명서 요청자에게 에러 메시지를 전송해야 한다.

요청 메시지의 dateOfExpiration 필드의 critical 값이 FALSE로 설정되었고 필드값이 증명서 정책상 효력 만기일을 초과하는 경우, 보관소 서버(130)는 정책상의 유효기간을 사용하여 증명서 효력 만기일을 설정한다. 요청 메시지의 dateOfExpiration 필드의 critical 값이 FALSE로 설정되었고 필드값이 증명서 정책 상 효력 만기일 내에 있다면, 보관소 서버(130)는 해당값을 사용하거나 또는 정책상 유효기간을 사용하여 증명서 효력 만기일 설정하는 것이 모두 가능하다. 전자문서 등록시에 발급되어지는 최초 등록 증명서의 효력 만기일은 전자문서의 보존 만료일(RetentionExpiredDate)과 동일해야 함에 주의한다.

증명서의 사용에 있어서 증명서의 효력 기간은 증명서 발급일로부터 증명서 효력 만기일 사이이다. 단, 증명서 효력 만기일 내에 있으나 증명서 서명 인증서의 유효기간이 곧 만료되거나 이미 만료되어 증명서의 유효성을 보증하지 못하는 경우에, 이용자는 갱신된 인증서로 서명한 증명서를 다시 발급해 줄 것을 보관소 서버(130)에 요청할 수 있고, 보관소 서버(130)는 이에 대하여 동일한 효력 만기일의 증명서를 갱신 발급하여야 한다. 증명서 갱신발급의 의미는 증명서에 첨부된 서명 및 서명에 사용된 보관소 인증서의 정보를 갱신하여 증명서의 유효성을 연장하는 것으로서, 갱신 전 증명서의 내용과 갱신 후 증명서의 내용은 변경되지 않는다. 따라서, 보관소 서버(130)에 갱신발급을 요청하기 위하여 이용자가 별도의 요청 메시지를 생성할 필요는 없으며, 갱신 발급된 증명서의 arcCertInfo 필드의 내용은 이전 증명서의 arcCertInfo의 내용과 동일해야 한다. 증명서 갱신 발급을 위한 재서명시, 보관소 서버(130)는 증명서에 첨부된 이전 서명 정보를 제거하고 갱신된 보관소 인증서를 사용하여 생성된 새로운 서명 정보를 추가하도록 한다.

policy 필드는 증명서 정책을 나타낸다. 증명서의 정책은 증명서를 발급하는 보관소의 해당 증명서에 대한 운영 정책 및 이용자의 증명서 이용 범위를 포함한다. 보관소 서버(130)는 기본 증명서 정책으로 등록 증명서 정책, 발급 증명서 정 책, 이관 증명서 정책, 폐기 증명서 정책, 원본 증명서 정책 등을 정의하고 각 정책에 OID(Object IDentifier: 객체 식별자)를 부여하여야 하며, 필요에 따라 각 기본 증명서 정책의 하위에 세부적인 증명서 정책을 정의하여 사용할 수 있다. 또한, 보관소 서버(130)는 부가적으로 시점확인 증명서를 발급하기 위한 시점확인 증명서 정책을 정의하고 OID를 부여하여 사용할 수 있다. 증명서의 정책에 따라서 증명서의 용도 및 효력이 결정되므로 증명서를 이용하는 모든 주체는 증명서 정책에 기술된 정책 내용에 대하여 인지하여야 한다.

ARCCertificatePolicies는 PolicyInformation 구조의 집합으로 이루어져 있으며, 다시 PolicyInformation은 증명서 정책을 기술하는 policyIdentifier와 이를 보다 자세하게 기술하는 policyQualifiers로 구성된다. policyQualifiers에는 업무준칙에 대한 공시를 위한 URI 주소를 나타내는 cPSuri와 사용자에게 간단한 정책관련 정보를 제공하는 userNotice가 포함된다. 본 발명에서는 cPSuri를 사용하여 표현된 PolicyQualifierInfo 구조를 반드시 포함하여야 하며, userNotice를 사용하여 표현된 PolicyQualifierInfo 구조는 선택적으로 포함 가능하다. userNotice를 사용할 경우 noticeRef는 생성하지 않으며, explicitText의 형식은 BMPString을 사용하여야 한다.

requestInfo 필드는 증명서 요청자가 생성한 증명서 요청 메시지를 나타낸다. 증명서 요청자가 증명서를 요청하는 일반적인 증명서 요청은 반드시 요청 메시지의 ARCCertRequest를 사용하고, 최초 등록 증명서나 원본 증명서와 같이 요청 메시지가 존재하지 않는 경우는 null을 사용한다.

target 필드는 증명 대상에 관한 것으로서, 보관소 서버(130)가 제공한 기능에 대한 증적이나 보관소가 증명서를 통하여 보증하고자 하는 사실을 나타내는 필드이다. 보관소 서버(130)는 이용자들이 요청한 등록, 발급, 이관, 폐기 등의 업무에 대하여 처리가 완료된 시점을 기준으로 업무 내역을 OperationRecord 구조체의 형식으로 생성하여 증적으로서 기록하고, 증명서 발급시 증명의 대상으로서 증명서에 포함한다. 또한, 보관소 서버(130)는 전자문서 발급시 해당 전자문서의 내용이 보관중인 원본 전자문서와 동일함을 보증하기 위하여 원본 전자문서 및 발급된 전자문서의 정보를 증명대상으로 증명서에 포함할 수 있으며, 이렇게 발급된 원본 증명서는 DIP 내에 첨부되어 발급된다. 그리고, 보관소 서버(130)는 증명서에 증명서 요청자가 보내온 해쉬정보를 포함하여 발급할 수 있는데, 이는 어떤 데이터가 특정 시각에 존재하였음을 증명하는 기능을 제공한다.

opRecord 필드는 보관소 서버(130)가 일정 기능을 수행하고 기록한 증적 레코드로서 등록 증명서, 발급 증명서, 이관 증명서, 폐기 증명서 발급시에 설정하도록 하며, orgAndIssued 필드는 보관소 서버(130)에 보관중인 원본 전자문서 정보와 발급된 전자문서 정보로 구성된 필드로서 원본 증명서 발급시에 설정하도록 한다. dataHash 필드는 시점확인 증명서 발급시 요청 메시지에 기재된 데이터 해쉬정보를 사용하여 설정하도록 한다.

OperationRecord ::= SEQUENCE {

serialNo INTEGER,

opRequesterInfo OperationRequesterInfo,

opRequestTime GeneralizedTime,

opTime GeneralizedTime,

opType OperationType,

orgDocInfo PackageDocumentInfo,

issuedDocInfo [0] EXPLICIT PackageDocumentInfo OPTIONAL,

peerARCInfo [1] EXPLICIT PeerARCInfo OPTIONAL,

reason [2] EXPLICIT Reason OPTIONAL }

여기에서, 각 필드의 의미는 다음과 같다.

□ serialNo : 증적의 식별번호

□ opRequesterInfo : 전자문서 서비스 요청자 정보

□ opRequestTime : 전자문서 서비스 요청시간

□ opTime : 보관소 서버(130)의 서비스 제공시간, 즉 작업시간

□ opType : 보관소 서버(130)가 제공한 서비스 종류, 즉 작업 종류

□ orgDocInfo : 보관소 서버(130)에 보관중인 원본문서 관련정보

□ issuedDocInfo : 문서 발급시 발급된 문서관련 정보

□ peerARCInfo : 이관 또는 수관시 상대 보관소 서버(130)의 관련정보

□ reason : 작업 사유

serialNo 필드와 opType 필드의 값은 요청 메시지의 targetRecord 필드 내의 serialNo 필드와 opType 필드의 값과 동일해야 한다. opRequester 필드는 전자문서 관련 업무에 대한 요청자의 신원 정보로서, 등록, 발급, 이관, 폐기 등의 전자문서 업무를 요청한 이용자의 실명 및 식별번호를 사용하여 요청 메시지의 requester 필드와 동일한 방법으로 생성하며, 만약 업무 요청자가 개인일 경우에는 주민번호의 도용을 방지하기 위하여 보관소 서버(130)가 직접 160bit의 안전한 난수를 생성하여 requester 필드 생성시에 사용하도록 한다. 보관소 서버(130)는 생성한 난수를 증적 구조체와 함께 보관하여 업무 요청자에 대한 신원을 검증할 필요가 있을 때에 검증과정 중에 사용하도록 한다. 유효기간 만료시의 전자문서 자동 폐기 등의 경우처럼 전자문서 업무 요청자가 없는 경우에는 opRequester대신 null을 사용한다.

opRequestTime 필드에는 AIP의 ReceiveDateTime 필드에 기술된 시각값과 동일한 값이 설정되어야 한다. 마찬가지로, opTime 필드에는 AIP의 RegisterDateTime 필드에 기술된 시각값과 동일한 값이 설정되어야 한다. 여기에서, AIP는 보존 정보 패키지로서, 전자문서 보관소 서버(130)가 이용자의 문서를 보관할 때 구성하는 구조를 말한다.

orgDocInfo 필드는 보관소 서버(130)에 보관중인 원본 전자문서의 정보를 포함하며, issuedDocInfo 필드는 발급된 전자문서의 정보를 포함하는데, PackageDocumentInfo 구조체의 형식으로 표현된다. orgDocInfo 필드는 보관소 서버(130)가 수행하는 모든 기능에 대하여 원본 전자문서 정보로서 설정되어야 하며, issuedDocInfo는 보관소 서버(130)가 전자문서 발급 기능 수행시, 발급된 전자문서에 대한 정보로서 선택적으로 설정된다.

packageID 필드는 패키지 식별자를 UTF8String 형식으로 변환한 값을 설정하 며, docInfo 필드는 패키지 내의 전자문서의 참조 정보를 포함한다. docInfo 필드는 orgDocInfo 필드에서 사용될 때는 항상 AIP 내의 원본 전자문서의 참조 정보를 포함해야 하며, issuedDocInfo 필드에서 사용될 때는 DIP 내에 포함된 원본 또는 변환본 전자문서의 참조 정보를 포함하게 된다. docID 필드는 전자문서 식별자를 UTF8String 형식으로 변환한 값을 설정한다.

fileIDs 필드는 전자문서 내의 첨부파일 중에서 관련된 첨부파일의 ID를 나타내며, 첨부파일 식별자를 UTF8String 형식으로 변환한 값의 목록으로 표현한다. 만약 전자문서 내의 모든 첨부파일에 해당된다면 fileIDs 필드 자체를 생략하도록 한다. docHash 필드는 전자문서의 해쉬값을 포함하는 DocumentHash 구조체 형식으로 표현된다. hashedDocument 필드는 해쉬 알고리즘인 hashAlg를 사용하여 전자문서의 내용을 한번 해쉬한 값으로서, 전자문서 내에 포함된 실제 문서파일이 2개 이상인 경우는 각 문서파일의 내용을 연접하여 해쉬한다. 이때, 문서파일의 연접 순서는 관련된 전자문서 내에서의 순서와 동일하다.

peerARCInfo 필드는 전자문서 이관 또는 수관 발생시, 수관 보관소 서버의 등록 증명서 및 이관 보관소 서버의 이관 증명서 생성시에만 생성하는 필드이다. peerARC 필드와 peerARCPackageID 필드는 전자문서의 이관 또는 수관 기능을 수행한 경우, 이관을 수행한 보관소 서버가 발급한 이관 증명서에는 수관을 수행한 보관소 서버의 신원정보 및 수관 보관소 서버에서 부여한 AIP의 패키지 식별자를 포함하며, 수관을 수행한 보관소 서버가 발급한 등록 증명서에는 이관을 수행한 보관소 서버의 신원정보와 이관 보관소 서버에서 부여한 AIP의 패키지 식별자를 포함한 다. 만약 opType의 값이 0(register)이며 peerARCInfo 항목이 존재한다면, 타 보관소 서버로부터 이관된 전자문서에 대한 등록 증명서임을 알 수 있다. peerARC 필드는 상대 보관소 서버의 실명 및 식별번호를 사용하여 요청 메시지의 requester 필드와 동일한 방법으로 생성한다.

Reason 필드는 선택적 생성 필드로서, 작업이 발생한 사유를 설정하며 값의 의미는 아래와 같다.

□ userRequest : 이용자 요청에 의한 작업

□ arcRequest : 보관소 서버 내의 프로세스상 발생한 작업

□ expired : 보존기간 만료

원본증명서에 사용되는 orgAndIssued 필드는 OriginalAndIssuedDocumentInfo 구조체로 표현된다. orgAndIssued 필드에 포함되는 orgDocInfo 필드는 보관소 서버(130)에 보관중인 원본 전자문서의 정보를 포함하며, issuedDocInfo 필드는 발급된 전자문서의 정보를 포함하는데, PackageDocumentInfo 구조체의 형식으로 표현된다. DocumentInfo 구조체 내의 docInfo 필드는 생성해야 하며 각 패키지 내에 포함된 관련 전자문서의 참조 정보를 가지고 있다.

마찬가지 경우의 issuedDocOriginal 필드는 발급된 전자문서가 원본 전자문서인가 또는 변환본 전자문서인가를 나타내며, 만약 issuedDocOriginal 필드의 값이 TRUE이면 orgDocInfo 필드 내에 포함된 hashedDocument 필드의 값과와 issuedDocInfo 필드 내에 포함된 hashedDocument 필드의 값이 동일해야 하며, FALSE이면 두 값은 달라야 한다. 본 발명을 준용하여 증명서를 발급하는 전자문서 보관 시스템은 orgDocInfo 필드에서 hashedDocument 필드의 값을 생성할 때와 issuedDocInfo 필드에서 hashedDocument 필드의 값을 생성할 때 동일한 해쉬 알고리즘을 사용하여야 한다. 또한, issuedDocInfo 필드 내에 포함된 hashedDocument 필드의 값은 동일한 해쉬 알고리즘으로 원본 증명서가 첨부된 DIP 내의 전자문서에 포함된 모든 전자문서 파일을 전자문서에 포함된 순서대로 연접하여 해쉬한 값과 항상 동일하여야 한다.

시점확인 증명서를 발급받기 위한 요청 메시지인 경우는 target 필드가 targetHash 필드를 사용하여 설정되어 있으며, 보관소 서버(130)는 증명서 발급시 해당 필드 정보를 사용하여 증명서의 target 필드를 설정하여야 한다. 즉, 증명서의 target 필드는 dataHash 필드를 사용하여 설정하여야 하며, 이는 요청 메시지의 targetHash 필드에 설정된 값을 사용하여 동일하게 설정하도록 한다. 시점확인 증명서를 발급하기 전에 보관소 서버(130)는 증명서 요청자로부터 수신한 요청 메시지를 검증하는 과정에서, targetHash 필드의 하위 필드인 hashAlg 필드에 기재된 해쉬 알고리즘 OID와 해당 해쉬 알고리즘을 사용하여 생성된 해쉬값인 hashedData 필드값의 길이가 합리적인가를 확인하여야 한다.

다음으로, 확장 필드를 설명한다. 확장 필드는 다음과 같은 구조로 되어 있다.

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

Extension ::= SEQUENCE {

extnID OBJECT IDENTIFIER,

critical BOOLEAN DEFAULT FALSE,

extnValue OCTET STRING }

여기에서, Extension은 확장 필드의 종류를 나타내는 extnID와 중요도를 의미하는 critical 그리고 확장 필드의 값을 포함하는 extnValue로 구성된다. 확장 필드의 critical이 TRUE로 설정되어 있을 경우에 증명서 이용자 또는 검증자는 이 확장 필드를 반드시 이해하고 처리할 수 있어야 한다.

Qualifications 필드는 자격부여에 관한 것으로서, 증명서를 전달받아 이용하는 주체와 위임될 역할에 대한 정보를 나타낸다. 본 필드는 요청 메시지의 Qualifications 필드와 동일한 내용을 포함해야 하며, 요청 메시지 없이 발급되는 최초 등록 증명서와 원본 증명서에는 본 필드가 생성될 수 없다. 요청 메시지에 Qualifications 확장 필드가 존재하고 critical 값이 TRUE인 경우, 보관소 서버(130)는 반드시 본 필드를 생성해야 한다. 본 필드를 생성하지 못하는 경우는 증명서 발급에 실패한 것으로 처리하고, 증명서 요청자에게 에러 메시지를 전송해야 한다. 본 필드 생성시 critical의 값은 TRUE로 설정해야 한다.

UsageType 필드는 증명서 용도에 관한 것으로서, 증명서의 이용환경 또는 용도에 따른 분류방식을 나타낸다. 본 필드는 요청 메시지의 UsageType 필드와 동일한 내용을 포함한다. 요청 메시지에 UsageType 확장 필드가 존재하고 critical 값이 TRUE인 경우, 보관소는 반드시 본 필드를 생성해야 한다. 본 필드를 생성하지 못하는 경우는 증명서 발급에 실패한 것으로 처리하고, 증명서 요청자에게 에러 메 시지를 전송해야 한다. 본 필드 생성시 critical의 값은 FALSE로 설정해야 한다.

CertifiedTime 필드는 보증 일시에 관한 것으로서, 전자문서 등록시점부터 본 필드에 기재된 시점까지 전자문서가 보관소에 보관되어 있었음을 보증하는 필드이며, 등록 증명서에만 포함될 수 있다. 본 발명을 준수하여 생성된 등록 증명서는 CertifiedTime 필드를 필수적으로 생성하여야 한다. 단, 최초 등록 증명서에는 본 필드를 생성하지 않도록 한다. 요청 메시지에 CertifiedTime 확장 필드가 존재하고 critical 값이 TRUE로 설정되었다면, 보관소 서버(130)는 요청 메시지의 CertifiedTime 필드에 기재된 보증 일시까지 전자문서를 보관중이었음을 확인한 후, 해당값을 증명서의 CertifiedTime 필드에 기재하여 증명서를 생성하도록 한다. 전자문서의 등록시점부터 요청 메시지에 기재된 보증 일시까지 전자문서가 보관소 데이터베이스(135)에 보관되어 있지 않았다면, 보관소 서버(130)는 증명서 요청자에게 에러 메시지를 전송하여야 한다. 요청 메시지에 CertifiedTime 필드값이 존재하지 않으면, 보관소 서버(130)는 하기와 같은 절차로 CertifiedTime 확장 필드의 값을 설정한다.

□ 전자문서가 해당 전자문서의 보존 만료일 전에 폐기 또는 타 보관소 서버로 이관되었다면 해당 일시를 설정하도록 한다.

□ 전자문서가 해당 전자문서의 보존 만료일까지 정상적으로 보관되었다면 해당 일시를 설정하도록 한다.

□ 전자문서가 현재 보관소 데이터베이스에 보관중이라면 증명서 발급일 필드와 동일한 값을 설정하도록 한다.

본 발명은 요청 메시지에 CertifiedTime 확장 필드가 존재한다면, 반드시 critical 값을 TRUE로 설정해야 하므로, FALSE인 경우는 다루지 않는다. 기타 사유로 본 필드를 생성하지 못하는 경우는 증명서 발급에 실패한 것으로 처리하고, 증명서 요청자에게 에러 메시지를 전송해야 한다. 본 필드 생성시 critical의 값은 TRUE로 설정해야 한다.

다음으로, 에러 메시지를 설명한다. 본 발명을 준용하지 않은 요청 메시지를 수신하거나 본 발명을 준용한 증명서를 생성하지 못하는 경우에는 보관소 서버(130)는 증명서 대신 에러 메시지를 생성하여 증명서 요청자에게 송신하여야 한다. 에러 정보를 포함하는 메시지는 ARCErrorNotice를 이용하여 증명서 요청자에게 전달된다.

ARCErrorNotice ::= SEQUENCE {

transactionStatus PKIStatusInfo ,

transactionIdentifier GeneralName OPTIONAL }

상기에서, transactionIdentifier 필드는 사용하지 않는다. 그리고, PKIStatusInfo는 아래에서 보는 바와 같이 IETF RFC 4210에서 정의하고 있는 구조를 사용한다.

PKIStatusInfo ::= SEQUENCE {

status PKIStatus,

statusString PKIFreeText OPTIONAL,

failInfo PKIFailureInfo OPTIONAL }

PKIStatus ::= INTEGER {

accepted (0),

grantedWithMods (1),

rejection (2),

waiting (3),

revocationWarning (4),

revocationNotification (5),

keyUpdateWarning (6) }

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

상기에서, PKIStatus의 값은 항상 rejection만을 사용한다. PKIFreeText에는 상세한 오류 메시지를 포함할 수 있다. failInfo필드는 역시 RFC 4210에서 사용하는 PKIFailureInfo를 사용하며, 본 발명에서 사용하는 값들은 다음과 같다. 이 값들의 내용은 아래 [표 1]을 참조하기 바란다.

PKIFailureInfo ::= BIT STRING {

badAlg (0),

badMessageCheck (1),

badRequest (2),

badTime (3),

badDataFormat (5),

wrongAuthority (6),

incorrectData (7),

unacceptedPolicy (15),

unacceptedExtension (16),

badSenderNonce (18),

signerNotTrusted (20),

unsupportedVersion (22),

unAuthorized (23),

systemUnavail (24),

systemFailure (25) }

[표 1]

번호	메시지	내용
0	badAlg	정의되지 않았거나 지원되지 않는 알고리즘
1	badMessageCheck	요청 메시지 무결성 손상 (전자서명 검증 실패 등)
2	badRequest	인가되지 않았거나 지원되지 않는 작업 요청
3	badTime	요청 메시지의 시간이 시스템 시간과 다름 (정책상 허용범위 초과)
5	badDataFormat	잘못된 요청 메시지 포맷
6	wrongAuthority	잘못된 기관 (요청 메시지의 기관명이 응답 메시지 생성기관과 다름)
7	incorrectData	요청 메시지의 내용이 잘못됨
15	unacceptedPolicy	요청된 정책 미지원
16	unacceptedExtension	요청된 확장필드 미지원
18	badSenderNonce	잘못된 송신자 nonce
20	signerNotTrusted	요청 메시지 서명자의 신원확인 불가 또는 신뢰할 수 없음
22	unsupportedVersion	지원되지 않는 요청 메시지 버전
23	notAuthorized	인가되지 않은 송신자
24	systemUnavail	현재 시스템 이용 불가
25	systemFailure	시스템에서 치리중 실패

이외, 에러 메시지로는 다음도 있다. 그 내용은 [표 2]를 참조하기 바란다.

[표 2]

번호	메시지	내용
8	missingTimeStamp	타임스탬프가 필요하나 생성되지 않음
13	badRecipientNonce	잘못된 사용자 nonce

다음으로, 증명서 검증 방법을 설명한다. 도 7은 본 발명의 바람직한 실시예에 따른 전자문서 보관 시스템에 있어서, 증명서 검증자 단말기의 증명서 검증 방법을 설명하기 위한 순서도이다. 증명서 검증자 단말기는 상술한 바와 같이 증명서 요청자, 증명서 수임자, 증명서 수임자가 명시되어 있지 않은 증명서를 소유한 모든 이용자 중 어느 하나가 접속하는 단말기이다. 이러한 증명서 검증자 단말기는 본 발명의 실시예에서 보관소 서버(130) 및 보관소 데이터베이스(135)와 연동하여 증명서를 검증하는 기능을 수행하는데, 증명서 검증이 꼭 증명서 검증자 단말기에 한정되는 것은 아니다. 즉, 본 발명에서는 이러한 증명서 검증 방법을 보관소 서버(130)가 단독으로 구현하도록 하는 것도 가능하다. 이하, 도 7을 참조하여 증명서 검증 방법을 설명한다.

증명서 검증 방법은 크게 증명서 유효성 검증 절차와 증명서 내용 검증 절차로 구분된다. 여기에서, 증명서 유효성 검증 절차는 증명서로서의 효력을 가지기 위한 조건들의 만족 여부를 확인하는 절차이고, 증명서 내용 검증 절차는 증명서를 활용하기 위한 조건들을 만족하는가를 확인하는 절차이다.

상술한 증명서 검증 방법은 본 발명의 실시예에서 발급된 증명서 포맷을 검 증하는 단계(S700), S700 단계에서 오류가 없는 경우 발급된 증명서 유효기간을 검증하는 단계(S705), S705 단계에서 오류가 없는 경우 발급된 증명서 폐지여부를 검증하는 단계(S710), S710 단계에서 오류가 없는 경우 발급된 증명서의 전자서명을 검증하는 단계(S715), S715 단계에서 오류가 없는 경우 발급된 증명서의 서명 인증서를 검증하는 단계(S720), S720 단계에서 오류가 없는 경우 발급된 증명서를 요청 메시지에 포함된 증명 요청서와 비교 검증하는 단계(S725), S725 단계에서 오류가 없는 경우 발급된 증명서를 전자문서와 비교 검증하는 단계(S730), S730 단계에서 오류가 없는 경우 전자문서와 증명서를 발급받는 수임자를 검증하는 단계(S735), S735 단계에서 정당한 자인 경우 보관소 데이터베이스(135)에 저장된 증명서 정책을 검증하는 단계(S740), S740 단계에서 오류가 없는 경우 전자문서와 증명서의 용도를 검증하는 단계(S745), S745 단계에서 선의인 경우 증명서 요청자를 검증하는 단계(S750), S750 단계에서 정당한 자인 경우 검증 통과(pass)를 표시하고 검증을 완료하는 단계(S755) 등으로써 구현된다.

상기에서, S700 단계 내지 S720 단계가 증명서 유효성 검증 절차에 해당하며, S725 단계 내지 S750 단계가 증명서 내용 검증 절차에 해당한다. 한편, S700 단계 내지 S750 단계에서 오류가 있거나 정당한 자가 아니거나 악의인 경우에는 검증 실패(fail)를 표시하고 해당 과정을 종료시킨다(S760). 한편, S730 단계와 S735 단계 사이에는 증적 증명에 대한 검증 단계와 원본 증명에 대한 검증 단계가 부과될 수 있다. 자세한 내용은 후술한다. 이하, 증명서 검증 방법의 각 단계를 구체적으로 설명한다.

① 증명서 유효성 검증 절차 (S700 ~ S720)

증명서 유효성 검증은 증명서로서의 효력을 가지기 위한 조건들의 만족 여부를 확인하는 과정으로서, 유효성 검증에 실패하면 증명서에 포함된 내용을 신뢰할 수 없게 되므로, 더이상 증명서는 신뢰받는 기관이 발급한 보증서로의 역할을 수행할 수 없다. 증명서 유효성 검증은 증명서 포맷 검증, 증명서 유효기간 검증, 증명서 폐지여부 검증, 전자서명 검증, 서명 인증서 검증으로 구분되며, 한 단계에서 실패하면 다음 과정을 진행하지 않고 검증 실패로 처리한다.

② 증명서 포맷 검증 단계 (S700)

증명서 포맷 검증 단계에서는 검증 대상 증명서가 본 발명에 게시된 증명서 포맷을 준수하여 생성되었는가의 여부를 확인한다. 본 발명에서 정의한 증명서의 구조 및 강제하거나 금하는 필드생성 규칙의 준수여부를 검증한 후, 증명서 내 각 필드 간의 모순이 없음을 확인한다. 필드 간 모순에 대한 주요한 몇 가지 예를 들면 다음과 같다.

□ 증명서의 서명 인증서의 정보와 issuer 필드의 정보가 불일치

□ 증명서 정책 OID와 target 필드의 구조 및 내용이 의미상 불일치

□ requestInfo의 내용과 다른 필드의 내용의 불일치

□ 등록 증명서가 아닌데, nomineeRole 필드에 readDocument나 downloadDocument 값이 설정된 경우

□ Qualifications 필드 내의 복수개의 qualification 필드들 중에 일부만이 onlyForNominee로 설정된 경우

□ 최초 등록 증명서와 원본 증명서에 Qualifications 필드가 생성된 경우

□ 등록 증명서인데, CertifiedTime 필드가 생성되지 않은 경우

□ 등록 증명서가 아닌데, CertifiedTime 필드가 생성된 경우

□ 시점확인 증명서인데, Version 필드의 값이 2가 아닌 경우

□ 시점확인 증명서가 아닌데, Version 필드의 값이 1이 아닌 경우

이외에도 본 발명에서 정의한 필드생성 규칙을 준수하지 않았거나, 각 필드의 내용에 상호 모순이 있는 경우는 검증 실패로 처리하도록 한다. 검증 대상 증명서가 잘못된 포맷으로 생성되었다면, 이후의 과정을 더 진행하지 않고 검증 프로세스는 여기서 종료하도록 한다.

③ 증명서 유효기간 검증 단계 (S705)

증명서 유효기간이란 증명서 발급일(dateOfIssue)로부터 증명서 효력 만기일(dateOfExpiration)까지를 의미하며, 본 단계는 증명서 검증시점이 증명서 유효기간 내에 있음을 확인하는 단계이다. 증명서는 증명서의 유효기간 내에서만 유효성이 인정되므로 만약 검증시점이 증명서 발급일보다 과거이거나 또는 증명서 효력 만기일 이후라면 증명서의 효력은 상실된다. 검증시점(T)과 증명서 발급일 및 증명서 효력 만기일을 다음과 같이 비교한다.

ⅰ) dateOfIssue = T < dateOfExpiration 일 경우 : 검증 성공

ⅱ) T < dateOfIssue 또는 dateOfExpiration = T 일 경우 : 검증 실패

검증시점이 증명서의 유효기간 내에 있지 않으면 검증 실패로 처리하고 검증 프로세스를 종료한다.

④ 증명서 폐지여부 검증 단계 (S710)

본 단계에서 증명서 검증자는 검증 대상 증명서에 대한 폐지여부를 보관소 서버(130)에 요청하여 확인하게 된다. 신뢰기관으로서 보관소 서버(130)가 발급한 증명서는 유효 기간동안 폐지되지 않는 것이 원칙이나, 중대한 사유로 증명서를 폐지해야만 되는 경우가 발생하였다면, 예외적으로 보관소 서버(130)는 해당 증명서를 폐지한 후, 증명서 폐지여부 확인 서비스를 통하여 해당 증명서의 폐지 정보를 증명서 검증자에게 제공하여야 한다. 증명서 검증자는 검증 대상 증명서를 보관소 서버(130)에 송신하여 폐지여부에 대한 확인을 요청하고, 보관소 서버(130)는 해당 증명서에 대한 폐지여부를 확인한 후, 응답 메시지에 증명서의 폐지여부 및 폐지된 증명서인 경우에 폐지 사유 등을 증명서 검증자에게 전송한다.

증명서 검증자는 증명서 요청자 검증 단계(S750)를 수행할 필요가 있다면, 폐지여부를 확인하는 절차 중에 증명서 요청자가 생성하여 보관소 서버(130)에 보관중인 난수값을 요청할 수 있으며, 이에 대한 응답 메시지에는 폐지여부에 대한 확인결과와 함께 해당 난수가 포함되어 증명서 검증자에게 전달된다. 증명서가 폐지되었다는 보관소 서버(130)의 응답 메시지를 수신했다면 검증 실패로 처리하고 검증 프로세스를 종료한다.

⑤ 전자서명 검증 단계 (S715)

보관소 서버(130)가 발급하는 증명서는 무결성의 제공 및 부인방지를 위하여 전자서명을 포함하며, 전자서명 검증 단계에서 증명서에 포함된 전자서명을 검증한다. 전자서명의 검증은 일반적인 CMS의 signedData에 대한 전자서명 검증 방법을 따른다. 전자서명의 검증이 실패하였다면 증명서의 무결성이 훼손되었음을 의미하며, 더이상 증명서의 내용을 신뢰할 수 없어 이후의 과정이 무의미해지므로 여기서 검증 프로세스를 종료하도록 한다.

⑥ 서명인증서 인증 단계 (S720)

서명인증서 검증 단계는 증명서에 서명한 인증서가 보관소 서버(130)의 인증서임을 확인하는 단계와 해당 인증서의 유효성을 검증하는 단계로 이루어진다. 증명서 검증자는 소유하고 있는 보관소 서버(130)의 인증서 또는 인증서 식별정보와 증명서 서명인증서를 비교하여 증명서 서명인증서가 보관소 서버(130)의 인증서임을 확인한다. 증명서 검증자가 보관소 서버(130)의 인증서 또는 인증서 식별정보를 획득하는 과정은 당업자에 의해 용이설계 가능한 부분에 해당하므로 본 발명에서는 그 내용을 생략한다. 한편, 증명서 서명인증서의 경로구축 및 인증서의 유효성 검증은 공인인증 체계의 "공인인증서 경로검증 기술규격 [KCAC.TS.CERTVAL]"을 준용하여 검증한다.

증명서 서명인증서의 유효성 검증에 실패한 경우, 증명서의 효력도 상실된다. 단, 증명서 서명인증서의 유효성 검증에는 실패하였더라도 증명서의 유효기간 검증에 성공하였고 전자서명 장기검증 기술이 적용된 상태라면, 해당 검증 기술에 따라 검증하여 성공하였을 경우, 서명인증서의 유효성 검증의 결과와는 관계없이 증명서의 유효성 검증에 성공한 것으로 처리한다.

전자서명 장기검증 기술은 예컨대 한국전자거래진흥원 또는 유관 기관이 제정한 기술규격("KCAC.DN; 전자서명인증관리체계 DN(Distinguished Name: 식별명칭) 규격 v1.1, 한국정보보호진흥원, 2003", "KCAC.DSCP; 전자서명 인증서 프로파일 기술규격 v1.10, 한국정보보호진흥원, 2004", "KCAC.SIVID; 식별번호를 이용한 본인확인 기술규격 v 1.11, 한국정보보호진흥원, 2002" 등)을 준용하도록 한다.

⑦ 증명서 내용 검증 절차 (S725 ~ S750)

증명서의 내용 검증 절차는 증명서의 활용 주체나 외부 환경 등에 따른 효용성을 검증하는 과정으로서 내용 검증에 실패하였다 하더라도 증명서 자체의 유효성을 상실하지는 않는다. 단, 증명 요청서와 비교 검증, 전자문서 검증에 실패하였다면, 검증 실패 메시지를 보관소 서버(130)에 통보하여 보관소 서버(130)가 이를 확인하고 증명서를 폐지 처리하여 증명서의 유효성을 상실하도록 한다. 검증 실패 메시지를 보관소 서버(130)에 통보하는 방법은 당업자에 의해 용이하게 실시될 수 있는 바 여기서는 생략한다. 내용 검증에 실패한 증명서의 이용자는 해당 증명서를 활용할 수 없다.

증명서 내용 검증은 증명 요청서와 비교 검증, 전자문서 검증, 수임자 검증, 정책 검증, 용도 검증, 증명서 요청자 검증으로 구분되며, 한 단계에서 실패하면 다음 과정을 진행하지 않고 검증 실패로 처리한다. 각 검증의 순서는 필요에 따라 바뀔 수 있다.

⑧ 증명 요청서와 비교 검증 단계 (S725)

증명서 요청자는 보관소 서버(130)로부터 증명서를 발급받은 즉시, 발급받은 증명서가 보관소 서버(130)에 송신했던 증명 요청서에 대한 증명서인가의 여부를 확인해야 한다. 따라서, 증명 요청서와의 비교 검증은 증명 요청서를 생성한 증명 서 요청자만이 수행할 수 있다. 증명서 요청자는 보관소 서버(130)가 발급한 증명서의 증명서 요청 메시지 정보인 requestInfo 필드의 arcCertRequest가 자신이 생성하여 송신했던 증명 요청서의 encapContentInfo 필드의 ARCCertRequest 구조체의 값과 동일함을 확인한다. 증명 요청서와의 비교 검증에 실패하였다면, 증명서 요청자는 보관소 서버(130)에 증명 요청서와의 비교검증 실패사실을 통보하여 폐지 처리하도록 하고, 증명서를 다시 발급받도록 한다.

⑨ 전자문서 검증 단계 (S730)

증명서 검증자가 증명서와 관련된 전자문서 패키지를 가지고 있다면, 반드시 증명서의 증명대상 필드에 포함된 전자문서의 해쉬값과의 비교 검증을 수행해야 한다. 원본 증명서는 항상 DIP에 첨부되어 발급되므로, 반드시 전자문서 검증 작업 중의 원본 증명에 대한 검증을 수행해야 한다. 어떤 데이터가 특정 시각에 존재하였음을 증명하는 시점확인 증명서의 경우에는 본 전자문서 검증 과정을 수행하지 않는다.

⑩ 증적 증명에 대한 검증 단계

증명서의 증명대상 필드로서 증적 증명을 의미하는 opRecord 필드에는 원본 전자문서의 해쉬값을 포함하는 orgDocInfo 필드와 발급된 전자문서의 해쉬값을 포함하는 issuedDocInfo 필드가 있는데, orgDocInfo 필드는 증적 필드에 항상 포함되는 필드로서 보관소 서버(130)가 보관중인 AIP에 포함된 원본 전자문서의 해쉬값을 포함하고, issuedDocInfo 필드는 문서발급 기능을 수행한 증적에만 포함되는 필드로서 DIP에 포함된 전자문서의 해쉬값을 포함한다. 따라서, 이용자가 증명서 검증 자가 되어 orgDocInfo 필드 내의 전자문서의 해쉬값을 검증하기 위해서는 SIP에 포함되어 보관소 서버(130)에 등록된 전자문서와 동일한 원본 전자문서가 필요하고, issuedDocInfo 필드 내의 전자문서의 해쉬값을 검증하기 위해서는 DIP로부터 추출한 전자문서가 필요하다. 상기에서, SIP는 입수 정보 패키지를 말하며, 이는 이용자가 전자문서를 전자문서 보관소 서버(130)에 전송할 때 구성하는 구조를 말한다.

증명서 검증자는 전자문서 검증을 수행할 필요가 있다면 해당 전자문서를 획득하여야 하며, 증명서 검증자가 해당 전자문서를 획득하는 과정은 이하 생략한다(because 당업자의 용이 실시). 전자문서 검증을 수행하는 과정에서 주의하여야 할 사항은, 패키지 내의 원본 또는 변환본 전자문서에 다수의 전자문서 파일들이 포함되어 있을 때 각 문서파일들을 해쉬하는 과정에서 보관소 서버(130)가 수행한 과정과 증명서 검증자가 수행한 과정이 동일해야 한다는 것이다. 즉, 보관소 서버(130)나 증명서 검증자는 패키지 내 원본 또는 변환본의 전자문서에 포함된 다수의 전자문서 파일에 대하여 패키지에 포함되어 있는 순서로 연접한 후 정해진 해쉬 알고리즘에 따라 한번 해쉬하여 전자문서의 해쉬값을 생성하도록 한다. 만약 패키지 내의 전자문서의 해쉬값과 증적에 생성된 전자문서의 해쉬값이 다르다면, 해당 증명서는 더이상 활용할 수 없으며, 증명서 검증자는 해당 사실을 보관소 서버(130)에 통보하여 폐지처리 하도록 한다.

⑪ 원본 증명에 대한 검증 단계

증명서의 증명대상 필드로서 원본 증명을 의미하는 orgAndIssued 필드에는 증적 증명과 마찬가지로, 원본 전자문서의 해쉬값을 포함하는 orgDocInfo 필드와 발급된 전자문서의 해쉬값을 포함하는 issuedDocInfo 필드가 있는데, orgDocInfo 필드는 보관소 서버(130)가 보관 중인 AIP에 포함된 원본 전자문서의 해쉬값을 포함하고, issuedDocInfo 필드는 DIP에 포함된 전자문서의 해쉬값을 포함한다. 또한, orgAndIssued 필드에는 발급된 전자문서가 원본 전자문서인지 변환본 전자문서인지를 표시하는 issuedDocOriginal 필드를 포함하고 있는데, 만약 issuedDocOriginal 필드의 값이 TRUE이면 두 해쉬값이 동일하며, FALSE이면 두 해쉬값이 달라야 한다.

원본 증명서는 항상 DIP에 첨부되어 발급되므로 증명서 검증자는 issuedDocInfo 필드에 설정된 발급 전자문서의 해쉬값과 DIP에 포함된 전자문서의 해쉬값의 동일성 여부를 검증해야 한다. 이용자가 증명서 검증자인 경우에 orgDocInfo 필드에 설정된 원본 전자문서의 해쉬값을 검증할 필요가 있다면, 증적 증명에서와 마찬가지로 원본 전자문서를 획득하여야 하며, 증명서 검증자가 원본 전자문서를 획득하는 과정은 이하 생략한다. 전자문서의 해쉬 절차는 증적 증명에서와 마찬가지 방법으로 생성하도록 한다. 만약 패키지 내의 전자문서의 해쉬값과 증적에 생성된 전자문서의 해쉬값이 다르다면, 해당 증명서는 더이상 활용할 수 없으며, 증명서 검증자는 해당 사실을 보관소 서버(130)에 통보하여 폐지처리 하도록 한다. 또한, 검증에 실패한 원본 증명서가 첨부된 DIP의 전자문서도 신뢰할 수 없는 것으로 판단하도록 한다.

⑫ 수임자 검증 단계 (S735)

증명서에 수임자를 지정한 Qualifications 확장필드가 존재하고 critical의 값이 TRUE인 경우, 증명서 검증자는 Qualifications 필드의 값을 확인하여야 한다. 수임자 검증이란, 수임자의 정보가 올바르게 생성되었음을 검증하는 것이 아니라, 증명서 검증자 또는 수임자임을 주장하는 자가 정당한 수임자인가를 확인하는 절차이다. 증명서의 Qualifications 필드의 모든 Qualification 항목들에 대하여 nomineeRole 필드의 값이 onlyForNominee를 포함하고 있다면, 해당 증명서는 각 qualification 항목의 nomineeInfo에 지정된 증명서 수임자들을 위해서만 발급된 것이므로, 증명서 검증자 또는 수임자임을 주장하는 자가 정당한 증명서 수임자인 경우에만 증명서를 활용할 수 있다. 수임자 검증에 실패하였더라도, 증명서 검증자나 수임자임을 주장하는 자가 증명서를 활용하지 못할 뿐, 증명서의 유효성을 상실하지는 않는다.

만약 Qualifications 확장필드가 없거나, critical의 값이 FALSE이거나, 모든qualification 필드 내 nomineeRole 필드의 값이 onlyForNominee를 포함하지 않는다면, 해당 증명서는 모든 사람에 의해서 활용될 수 있다.

⑬ 증명서 정책 검증 단계 (S740)

증명서 검증자는 검증하고자 하는 증명서에 포함된 증명서 정책이 현재 활용을 위한 목적에 부합되는가를 검증해야 한다. 증명서에 포함된 증명서의 정책은 증명서의 활용, 용도, 목적, 보증 범위 등에 대한 내용을 담고 있으며, 보관소 서버(130)는 이에 대한 내용을 증명서를 사용하는 모든 이용자를 위하여 공지하고 있다. 증명서 검증자는 증명서 정책 필드의 증명서 정책이 자신의 증명서 활용 목적을 위해서 적합한 정책인가를 확인한다. 정책 검증에 실패하였더라도, 증명서 검증자의 활용 목적을 위하여 증명서를 활용하지 못할 뿐, 증명서의 유효성을 상실하지 는 않는다.

⑭ 용도 검증 단계 (S745)

증명서에 증명서 용도를 지정한 UsageType 확장필드가 존재하고 critical의 값이 TRUE인 경우, 증명서 검증자는 UsageType 필드의 값을 확인하여야 한다. 증명서의 사용환경과 증명서 용도 필드의 값이 일치하지 않으면 검증에 실패하게 된다. 본 발명에서는 UsageType 필드의 critical의 값을 FALSE로 설정하도록 하므로 증명서의 용도 검증을 하지 않아도 된다.

⑮ 증명서 요청자 검증 단계 (S750)

증명서에 증명서 요청자 정보가 포함되어 있는 경우, 즉 requestInfo 필드의 정보로 null이 아닌 arcCertRequest 필드가 사용되었다면, arcCertRequest 필드 내의 requester 필드에 대하여 필요한 경우에 검증을 수행할 수 있다. 본 증명서 요청자 검증 과정은 증명서 요청자라고 주장하는 자의 신원정보와 증명서 내의 증명서 요청자 정보와의 동일성 여부에 대한 확인을 주목적으로 한다. 증명서 요청자 검증에 실패하였더라도, 증명서 요청자라고 주장하는 자가 정당한 증명서 요청자가 아님을 확인한 것일 뿐, 증명서의 유효성을 상실하지는 않는다.

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

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

본 발명은 전자문서를 취급하는 기관, 학교, 기업체 등지에서 이용 가능하여 그 이용도가 매우 높다할 것이다. 더욱이, 미래 사회는 유비쿼터스 시대를 지향하고 있으므로 본 발명은 향후 더욱 빛을 발할 것으로 예측된다.

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

도 2는 본 발명의 바람직한 실시예에 따른 전자문서 보관 시스템에 있어서, 전자문서 보관소 서버의 내부 구성을 개략 설명한 블록도,

도 3 내지 도 6은 본 발명의 바람직한 실시예에 따른 전자문서 보관 시스템에 있어서, 전자문서 보관소 서버의 증명서 발급 절차를 설명하기 위한 흐름도,

도 7은 본 발명의 바람직한 실시예에 따른 전자문서 보관 시스템에 있어서, 증명서 검증자 단말기의 증명서 검증 방법을 설명하기 위한 순서도이다.

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

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

115 : 증명서 요청자 단말기 120 : 증명서 수임자 단말기

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

150 : 공인인증기관 서버 200 : 통신부

205 : 등록 관리부 210 : 중앙처리부

215 : 메시지 생성부 220 : 발급 관리부

225 : 무결성 검증부 230 : 시점확인 관리부

235 : 증적 검색부 240 : 기타 관리부

Claims (19)

1. 전자문서를 증명하는 증명서의 발급을 요청하는 이용자 단말기; 및

   상기 증명서를 발급하는 전자문서 보관소 서버

   를 포함하며,

   (a) 상기 이용자 단말기가 상기 증명서 발급을 요청하는 단계;

   (b) 상기 전자문서 보관소 서버가 상기 요청에 따른 증명서 요청 메시지를 생성하는 단계;

   (c) 상기 전자문서 보관소 서버가 상기 증명서 요청 메시지에서 증명의 대상이 되는 증적을 검색하는 단계;

   (d) 상기 전자문서 보관소 서버가 상기 증명서 요청 메시지와 상기 검색된 증적을 근거로 상기 증명서 발급을 시도하는 단계;

   (e) 상기 전자문서 보관소 서버가 상기 발급된 증명서의 포맷을 제1 검증하고, 상기 제1 검증시 에러가 없으면 상기 전자문서 보관소 서버가 상기 발급된 증명서의 유효기간을 제2 검증하며, 상기 제2 검증시 유효기간을 도과하지 않았다면 상기 전자문서 보관소 서버가 상기 발급된 증명서의 폐지 여부를 제3 검증하고, 상기 제3 검증시 폐지된 것이 아니라면 상기 전자문서 보관소 서버가 상기 발급된 증명서의 전자서명을 제4 검증하며, 상기 제4 검증시 인증된 것이면 상기 전자문서 보관소 서버가 상기 발급된 증명서의 서명 인증서를 제5 검증하고, 상기 제5 검증시 인증된 것이면 상기 전자문서 보관소 서버가 상기 발급된 증명서를 상기 요청 메시지에 포함된 증명 요청서와 제1 비교하며, 상기 제1 비교시 동일하면 상기 전자문서 보관소 서버가 상기 발급된 증명서를 전자문서와 제2 비교하고, 상기 제2 비교시 관련성이 있으면 상기 전자문서 보관소 서버가 상기 전자문서와 상기 증명서를 발급받는 수임자를 제6 검증하며, 상기 제6 검증시 수임자가 검증된 자이면 상기 전자문서 보관소 서버가 상기 증명서에 대한 증명서 정책을 제7 검증하고, 상기 제7 검증시 증명서 정책에 적합한 것이면 상기 전자문서 보관소 서버가 상기 전자문서와 상기 증명서의 용도를 제8 검증하며, 상기 제8 검증시 상기 증명서의 사용 환경과 상기 증명서의 용도 필드값이 일치하면 상기 전자문서 보관소 서버가 상기 증명서의 요청자를 제9 검증하고, 상기 제9 검증시 상기 요청자가 정당한 권리자이면 상기 전자문서 보관소 서버가 상기 발급된 증명서를 검증된 것으로 표시하는 단계; 및

   (f) 상기 전자문서 보관소 서버가 상기 검증된 증명서를 포함하는 증명서 응답 메시지를 생성하고 상기 이용자 단말기로 상기 증명서 응답 메시지를 전송하며, 상기 증명서 발급에 실패한 경우 원인을 포함하는 에러 메시지를 생성하고 상기 이용자 단말기로 상기 에러 메시지를 전송하는 단계

   를 포함하는 것을 특징으로 하는 전자문서 증명서 발급 방법.
2. 제 1 항에 있어서,

   상기 전자문서 보관소 서버는 상기 증명서로 상기 전자문서 등록을 증명하는 등록 증명서, 상기 전자문서 발급을 증명하는 발급 증명서, 상기 전자문서 이관을 증명하는 이관 증명서, 상기 전자문서 폐기를 증명하는 폐기 증명서, 발급된 전자문서가 보관된 전자문서와 동일한 원본임을 증명하는 원본 증명서, 및 일정 데이터가 특정 시각에 존재하였음을 증명하는 시점확인 증명서 중 적어도 하나를 발급하는 것을 특징으로 하는 전자문서 증명서 발급 방법.
3. 제 1 항에 있어서,

   상기 (d) 단계에서 상기 전자문서 보관소 서버는 저장된 증명서 정책을 이용하는 것을 특징으로 하는 전자문서 증명서 발급 방법.
4. 제 2 항에 있어서,

   상기 증명서가 상기 등록 증명서인 경우, 상기 전자문서 보관소 서버는 최초 발급에 한하여 상기 증명서 요청 메시지 수신 없이 상기 등록 증명서를 담은 상기 증명서 응답 메시지를 생성 전송하는 것을 특징으로 하는 전자문서 증명서 발급 방법.
5. 제 2 항에 있어서,

   상기 증명서가 상기 원본 증명서인 경우 상기 (c) 단계에서 상기 전자문서 보관소 서버는 전자문서 원본 이외에 추가로 상기 원본과 동일한 구성을 가지는 변환본에 대한 원본 증명서를 발급하는 것을 특징으로 하는 전자문서 증명서 발급 방법.
6. 제 2 항에 있어서,

   상기 증명서가 상기 원본 증명서인 경우, 상기 (e) 단계에서 상기 전자문서 보관소 서버는 생성되는 증명서 응답 메시지에 DIP(Dissemination Information Packages)를 포함하는 것을 특징으로 하는 전자문서 증명서 발급 방법.
7. 제 2 항에 있어서,

   상기 증명서가 상기 시점확인 증명서인 경우, 상기 (b) 단계에서 상기 전자문서 보관소 서버는 상기 증명서 요청 메시지에 데이터 해쉬값을 포함시키는 것을 특징으로 하는 전자문서 증명서 발급 방법.
8. 제 2 항에 있어서,

   상기 증명서가 상기 시점확인 증명서, 상기 발급 증명서, 상기 이관 증명서, 및 상기 폐기 증명서 중 하나 이상인 경우, 상기 (b) 단계와 상기 (c) 단계의 중간 단계에서, 상기 전자문서 보관소 서버는 상기 증명서 요청 메시지의 무결성을 검증하는 것을 특징으로 하는 전자문서 증명서 발급 방법.
9. 제 2 항에 있어서,

   상기 증명서가 상기 발급 증명서, 상기 이관 증명서 및 상기 폐기 증명서 중 하나 이상인 경우, 상기 (c) 단계에서 상기 전자문서 보관소 서버는 상기 증명서 요청 메시지를 근거로 기존 증적이 있는지를 검색하는 것을 특징으로 하는 전자문서 증명서 발급 방법.
10. 제 1 항에 있어서,

    상기 (e) 단계에서 상기 전자문서 보관소 서버는 상기 증명서 응답 메시지에 발급한 전자문서를 포함시키는 것을 특징으로 하는 전자문서 증명서 발급 방법.
11. 전자문서와 상기 전자문서에 대한 증명서를 취급하는 전자문서 보관 시스템에 있어서,

    전자문서의 등록을 요청하는 자가 접속하는 이용자 단말기;

    상기 증명서를 요청하는 자가 접속하는 요청자 단말기;

    상기 증명서를 발급하는 것으로서, 상기 요청을 표시하는 증명서 요청 메시지에서 증명의 대상이 되는 증적을 검색하며, 상기 증명서 요청 메시지와 상기 검색된 증적을 근거로 검증된 상기 증명서를 포함하는 증명서 응답 메시지를 생성 전송하되, 상기 증명서를 검증할 때에 상기 발급된 증명서의 포맷을 제1 검증하고, 상기 제1 검증시 에러가 없으면 상기 발급된 증명서의 유효기간을 제2 검증하며, 상기 제2 검증시 유효기간을 도과하지 않았다면 상기 발급된 증명서의 폐지 여부를 제3 검증하고, 상기 제3 검증시 폐지된 것이 아니라면 상기 발급된 증명서의 전자서명을 제4 검증하며, 상기 제4 검증시 인증된 것이면 상기 발급된 증명서의 서명 인증서를 제5 검증하고, 상기 제5 검증시 인증된 것이면 상기 발급된 증명서를 상기 요청 메시지에 포함된 증명 요청서와 제1 비교하며, 상기 제1 비교시 동일하면 상기 발급된 증명서를 전자문서와 제2 비교하고, 상기 제2 비교시 관련성이 있으면 상기 전자문서와 상기 증명서를 발급받는 수임자를 제6 검증하며, 상기 제6 검증시 수임자가 검증된 자이면 상기 증명서에 대한 증명서 정책을 제7 검증하고, 상기 제7 검증시 증명서 정책에 적합한 것이면 상기 전자문서와 상기 증명서의 용도를 제8 검증하며, 상기 제8 검증시 상기 증명서의 사용 환경과 상기 증명서의 용도 필드값이 일치하면 상기 증명서의 요청자를 제9 검증하고, 상기 제9 검증시 상기 요청자가 정당한 권리자이면 상기 발급된 증명서를 검증된 것으로 표시하는 전자문서 보관소 서버; 및

    상기 이용자 단말기 또는 상기 요청자 단말기와 상기 전자문서 보관소 서버 사이에서 공인인증을 하는 공인인증기관 서버

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

    상기 전자문서나 상기 증명서를 수임하는 자가 접속하는 수임자 단말기

    를 더 포함하되,

    상기 수임자 단말기는 상기 이용자 단말기, 상기 요청자 단말기 및 제3자가 접속하는 제3자 단말기 중 어느 하나인 것을 특징으로 하는 전자문서 보관소 시스템.
13. 제 11 항에 있어서,

    상기 전자문서 보관소 서버는 상기 증명서 응답 메시지 생성에 실패할 경우 원인을 포함하는 에러 메시지를 생성 전송하는 것을 특징으로 하는 전자문서 보관 시스템.
14. 제 11 항에 있어서,

    상기 전자문서 보관소 서버가 생성하는 증명서는 상기 전자문서 등록을 증명하는 등록 증명서, 상기 전자문서 발급을 증명하는 발급 증명서, 상기 전자문서 이관을 증명하는 이관 증명서, 상기 전자문서 폐기를 증명하는 폐기 증명서, 발급된 전자문서가 보관된 전자문서와 동일한 원본임을 증명하는 원본 증명서, 및 일정 데이터가 특정 시각에 존재하였음을 증명하는 시점확인 증명서 중 하나 이상인 것을 특징으로 하는 전자문서 보관 시스템.
15. 제 11 항에 있어서,

    상기 전자문서 보관소 서버는 상기 증명서 응답 메시지에 발급한 전자문서를 포함시키는 것을 특징으로 하는 전자문서 보관 시스템.
16. 제 11 항에 있어서,

    상기 전자문서 보관소 서버에 의해 운용되며, 상기 전자문서, 상기 증명서 및 상기 증적 중 하나 이상을 저장하는 전자문서 보관소 데이터베이스

    를 더 포함하되,

    상기 전자문서 보관소 데이터베이스는 WORM(Write Once Read Many) 기능을 구비하는 것을 특징으로 하는 전자문서 보관 시스템.
17. 제 14 항에 있어서,

    상기 전자문서 보관소 서버는,

    상기 증명서 요청 메시지를 수신하고, 상기 증명서 응답 메시지나 상기 에러 메시지를 송신하는 통신부;

    상기 전자문서를 등록하고, 상기 전자문서 등록에 대한 증적을 생성하며, 상기 등록 증명서를 생성하는 등록 관리부;

    상기 증명서 응답 메시지나 상기 에러 메시지를 생성하는 메시지 생성부;

    상기 전자문서를 발급하고, 상기 전자문서 발급사실에 대한 증적을 생성하며, 상기 원본 증명서를 생성하는 발급 관리부;

    상기 증명서 요청 메시지의 무결성을 검증하는 무결성 검증부;

    상기 증명서 요청 메시지에 포함된 데이터 해쉬값을 근거로 상기 시점확인 증명서를 생성하는 시점확인 관리부;

    상기 증명서 요청 메시지를 근거로 기존 증적이 있는지를 검색하는 증적 검색부;

    상기 증적 검색부가 검색한 증적을 근거로 상기 발급 증명서, 상기 이관 증명서 및 상기 폐기 증명서 중 하나 이상을 생성하는 기타 관리부; 및

    상기 전자문서 보관소 데이터베이스를 연동시키며, 상기 통신부와 상기 등록 관리부와 상기 메시지 생성부와 상기 발급 관리부와 상기 무결성 검증부와 상기 시점확인 관리부와 상기 증적 검색부와 상기 기타 관리부의 전체 작동을 제어하는 중앙처리부

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

    상기 전자문서 보관소 서버가 처리하는 상기 증명서 요청 메시지와 상기 전자문서 보관소 서버가 생성하는 상기 증명서 응답 메시지는 ASN.1(Abstract Syntax Notation One), BER(Basic Encoding Rules) 및 DER(Distinguished Encoding Rules) 중 어느 하나의 방식으로 인코딩하는 IETF RFC 3852 CMS(Cryptographic Message Syntax) 구조를 형성하는 것을 특징으로 하는 전자문서 보관 시스템.
19. 컴퓨터로 판독 가능한 기록매체에 있어서,

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

Images