KR101105121B1

KR101105121B1 - 진정문서의 전달, 저장 및 회복에 대한 시스템 및 방법

Info

Publication number: KR101105121B1
Application number: KR1020057000955A
Authority: KR
Inventors: 에프.비스비 스티븐; 제이.모스코비츠 잭; 에프.벡커 케이스; 제이.힐튼 월터; 디.스제벤이 조슈아
Original assignee: 이오리지널 인크.
Priority date: 2002-07-18
Filing date: 2003-07-17
Publication date: 2012-01-16
Also published as: AU2003259136B2; NZ537994A; BR0312774A; WO2004010271A3; EP1540881B1; CA2492986C; KR20050074430A; IL166311A0; US7743248B2; CN1682490A; US20040093493A1; CA2492986A1; WO2004010271A2; EA007089B1; HK1083252A1; BRPI0312774B1; EP1540881A2; CN1682490B; EA200500227A1; MXPA05000696A

Abstract

구성가능하고, 직접적이며, 임의의 승인된 인증기관(CA)으로부터 상태를 회복할 수 있는 인증서 상태 서비스(TSS)가 개시되어진다. 상기 인증서상태 서비스는 신뢰성 있는 보관 유틸리티(TCU)와 이와 동등한 시스템 또는 요구되어지는 활동, 제출되어진 전자적 정보물의 진정성, 디지털 서명 증명과 사용자 진정성 입증의 단계에 사용되어지는 진정성 입증의 상태를 수행하면서 개인의 권리를 증명하는 역할을 수행하는 응용프로그램에 의하여 사용되어진다. 진정성 입증의 증명은 발행된 CA를 문의하여 수행되어진다. 전통적으로 인증을 증명하기 위해 필요한 신뢰성 있는 공개키 기반구조(PKI)를 제작하기 위해서는 CA들간의 상호 인증 또는 PKI 연계 사용을 통한 복잡한 관계가 형성되어진다. PKI와 CA의 상호운영 문제는 전자적 원본 정보물(이는 또한 전달 가능한 기록이 될 수도 있는-소유권이 바뀔 수 있는)의 생성, 실행, 유지, 전달, 회복 및 제거에 적절한 신뢰할만한 환경을 설립하는 것에 초점이 맞춰지는 여러 가지 다른 측면으로부터 발생한다. TCU는 물론 CA들이 업무환경의 다양한 부분을 지원할 수 있지만 “승인된 CA들”의 알려진 세트와만 관련되어지며, 상기 세트 내에서 TCU 사용자 계정과 연관되어지는 이들 인증서들과 관련되어진다. 따라서 상기 CSS는 단지 인증된 CA들만을 문의하여 신뢰성 있는 환경을 만들고 정당한 인증서 상태의 저장을 유지하기 하기 때문에 PKI/CA 신뢰 관계를 이룰 필요가 없다.

진정문서, 신뢰보관 유틸리티

Description

진정문서의 전달, 저장 및 회복에 대한 시스템 및 방법{SYSTEM AND METHOD FOR THE TRANSMISSION, STORAGE AND RETRIEVAL OF AUTHENTICATED DOCUMENTS}

본 발명은 Electronic OriginalTM 문서와 같은 전자적 원본 정보물의 생성, 실행, 유지, 전달, 회복(retrieval) 및 제거를 위한 증명될 수 있는 증거의 연쇄 및 보안을 제공하기 위한 시스템 및 방법에 관한 것이다.

본 발명은 본 발명의 출원인의 신뢰보관 유틸리티를 유용하게 사용할 수 있다. 상기 신뢰보관 유틸리티(TCU)는 전자적 원본 기록을 보유하고 동등한 시스템은 요구되어지는 행위를 수행하기 위한 개인의 권리, 제출되어진 전자적 정보물(information objects)의 진정성(authenticity) 및 전자서명 증명과 사용자 진정성 검증 절차에 사용되는 진정성 인증서(authentication certificate)의 상태를 증명하는데 사용되어지는 가상의 전자적 저장소로서 역할을 한다. 상기 TCU들과 운용은 미국특허등록 5,615,268과 5,748,738과 6,237,096과 6,367,013에 기술되어진다.

아래의 목록은 본 명세서상에 사용되어지는 약어들이다.

약어

CA 인증기관(certification authority)

CRL 인증취소(무효화)목록(certificate revocation list)

CSS 인증서 상태 서비스(certificate status service)

HTML 하이퍼텍스트 생성언어

ID 신분증명

IETF 인터넷 엔지니어링 담당(internet engineering task force)

ITU 국제전화연합(international telecommunication union)

LDAP 경량 디렉토리 접근 프로토콜

(lightweight directory access protocol)

OCSP 온라인 인증서 상태 프로토콜, IETF-RFC 2560 X.509 인터넷

공개키 기반구조 온라인 인증서 상태 프로토콜-OCSP, 1999년

6월

PIN 개인 신분증명 번호(비밀번호)

(personal identification number)

PKCS 공개-키 암호화 기준(Public-key cryptographic standards)

PKI 공개키 기반구조(public key infrastructure)

PKIX 공개키 기반구조(X.509)

S/MIME 보안 다목적 인터넷 메일 확장자

(secure multi-purpose internet mail extensions)

SCVP 단순 인증 증명 프로토콜, Draft-IETF-PKIX-SCVP-06,

2000년 7월

SSL 보안 소켓층(secure socket layer)

TCU 신뢰보관 유틸리티(trusted custodial utility)

UETA 균일 전자적 업무규정(uniform electronic transaction act)

XML 확장성 생성언어
정의
델타 CRL - CA들이 통상의 일정에 따라 인증서 무효화 목록(CRL)을 발행한다. 모든 CRL들의 발행 사이의 개재 간격(intervening interval)중에 상쇄된다고 믿는 인증서가 델타 CRL에 위치될 수 있다. 델타-CRL에 대한 지원은 CA의 인증서 업무 준칙(certificate practice statement)에 서류화 되어 있다. CSS는 전체 CRL의 내용을 분석하고, CA 특이적 캐시(cache)에 이를 위치시킨다. 차후의 어떠한 델타-CRL의 내용은 CA의 CSS 캐시에 존재하는 내용에 부가된다. CSS 캐시는 다음의 모든 CRL 및 반복 프로세스의 수령시 비워진다. 델타-CRL은 익스텐션(extension)이 강화된 델타 CRL 지정장치(indicator)를 가지며, 모든 CRL을 매시간 다운로드하는 오우버헤드(overhead) 없이 인증서 상태를 더욱 적절한 시간에 제공하는 수단이다.

지구적, 국가적 상행위에서의 미국 전자서명 규정(ESIGN)과 미국 주법은 UETA가 균일 주법에 관한 국가회의에서 제안되어지고 1999년에 제정을 위해 승인되고 제청된 후에 모델화된 것으로 이는 정부, 은행 및 전자 상거래 행위가 이러한 잠재적인 모든 전자적 업무(transaction)의 효율성 및 경제성을 인식하도록 하는데 집중하도록 한 전자적으로 사인된 정보물(전자적 문서)에 대한 법적 기준에 대한 확신을 제공한다.

PKI와 CA는 전자적 소스 기록을 생성하는데 사용되는 전자서명 기술의 기본 요소이다. PKI는 CA들간에 계층적 관계를 형성하거나 협력하는 CA들의 상호 인증을 통하여 신용이 사용자들과 사용자 조직간에 생성되는 CA들의 모임이다. 하나의 CA는 개인 또는 단체의 신원과 이들의 공개키(입증)를 묶는 진정(성) 인증서(authentication certificate)를 발행할 수 있다. 그리고 거기에서 상기 개인에게 상기 매칭(matching)하는 공개 키(서명)에 접근권이 주어진다. 본 발명에서 인증서는 일반적으로 ITU X.509 인증서 기준에 부합하고 그 자신을 디지털적으로 발행하는 CA에 의하여 서명되어진다. 이러한 인증서는 예를 들면 상기에 인용되고 동반된 미국특허 6,237,096의 도 10에 나타나있다. 이들 진정성 인증서는 일련번호, 대상(사용자) 확인정보, 발행자(CA), 인증서 유효기간(이것이 사용될 수 없는 날짜 와 시간), 대상의 공개 키 및 디지털 서명을 생성하고 입증하기 위해 필요한 암호화 알고리즘 정보를 포함한다.

디지털 서명을 생성하기 위하여, 정보물은 파쇄(hash)되고(대상물에 있어서 1비트 변경만큼 미세하게 감지될 수 있는 일방향 암호함수를 이용한 프로세스로), 상기 파쇄된 것은 개인의 개인(암호) 키를 이용하여 암호화된다. 디지털 서명 증명은 이러한 과정을 반대로 하여 이루어진다. 상기 디지털 서명은 이들의 진정성 인증서로부터 회복된 개인 공개키를 이용하여 복호화되고 그 결과는 원본 정보물의 재분쇄(re-hash)된 것과 비교되어진다. 이러한 과정은 다른 디지털 서명 알고리즘을 사용하는 경우에는 달라질 수 있다. 디지털 서명은 단지 사용하는 단체와 발행하는 CA간에 존재하는 신용과 CA들에 의하여 진행되어지는 물리적인 제어(control), 실행 및 과정(procedure)들에 의하여 이루어지는 확신의 수준만큼 믿을 만한 것이다.

PKI기술의 목적은 서로 소통하는 집단에 대한 신뢰성 있는 환경 및 보안을 생성하고 유지하는 것이다. 이러한 집단은 사용자의 신원을 정립하고 사용자의 인증서가 더 이상 믿을 만한 것이 아닌 경우에 이를 알려주기 위해서 PKI에 의존한다. 인증서는 개인이 단체를 떠났을 때, 대체하는 인증서가 발급되었을 때 또는 서명키를 잃어버리거나, 도둑맞거나 상쇄되었을 때 효력이 없어진다. 공급자는 다양한 방법을 통하여 인증서의 상태를 보고(reporting)한다. 이러한 다양한 방법은 사용자가 다른 사용자에 대한 인증서 상태를 얻는 것을 더욱 어렵게 한다.

신뢰관계와 상호운용(interoperability)의 형태는 PKI인증서와 보안정책과 이들의 규정에 의해 지배된다. 상기 인증서 정책은 인증서의 발행을 위한 승인을 얻기 위해 요구되어지는(예를 들면, 2가지의 사진을 가지는 신분증, 신용도 조회) 개인 신상조회(즉, 인증서 요구 정보의 적정성과 의도하는 인증서 수령자의 신원을 증명하기 위한 프로세스)의 수준을 결정한다. 상기 보안정책은 응용프로그램(application) 환경을 지원하기 위해 필요한 물리적, 과정적(procedural) 및 공정 제어(process control)를 지배한다.

CA들을 생성하고 조직하는 것에는 2개의 널리 이용되는 모델이 있다. 첫째는 계층적 CA모델로서 꼭대기가 루트(root) CA가 되는 뒤집혀진 나무와 유사한 모델이다. 상기 루트 CA는 그의 바로 아래의 하부 CA의 인증서를 서명한다. 그 후에 이들 CA들은 그들의 하부의 CA들의 인증서를 서명하고 그렇게 반복된다. 이와 같은 관계는 인증사슬을 생성하여 나무의 가지를 이룬다. 두 CA들은 신뢰관계가 이들 간에 존재하는 것을 공통 노드(node)에 이를 때까지 그들 각각의 인증서 체인을 따라 “걸어감”(walking)으로써 증명한다. CA들은 하나 또는 더 많은 서비스 공급 채널, 산업 구조, 기구 또는 기업과 연계되거나 그룹화 될 수 있다.

둘째 모델에서는, CA는 하나의 기업에 대하여 생성되어지고, 상기 기업내의 하나 또는 그 이상의 단체에 CA서비스를 제공한다. 기업 CA는 다른 기업의 임의의 CA와 미리 설립된 신용 관계를 가지지 않는 것이 일반적이다. CA상호 인증의 형태에서 상호운영을 허용하기 위해서는 둘 또는 그 이상의 CA들이 각자의 인증서를 서명하여 서로를 신뢰하기로 합의하여 디지털 서명 증명시에 이러한 상호-인증 인증서를 사용하는 것과 같은 명확한 행위가 이루어져야만 한다. 하나의 CA에서 발행 된 인증서는 이후에 다른 상호-인증 CA와 그 사용자에 의하여 증명되어질 수 있다.

CA들은 여러 가지 다른 이유 중에서, 인증서에 포함된 정보가 정당하지 않거나, 사용자의 개인키가 상쇄되거나 사용자의 인중서-기준 응용프로그램 특권을 종료하는 것이 필요한 경우에는 인증서를 무효화(취소 : revocation)) 한다. CA들은 인증서가 이미 소유자의 소유에 있다면 그 소유자로부터 인증서를 단순히 삭제하거나 회복(retrieval)할 수 없다. 대신, 상기 인증서는 CA의 데이터베이스에서 “무효화”된 것으로 표시되고, 상기 인증서 상태는 발행된다. 이후에 상기 PKI의 사용자는 발행CA 또는 확인된 상태 저장소(디렉토리)로부터 인증서 상태를 요구하여 인증서의 유효성을 알 수 있게 된다.

인증서 상태를 보고하는데 사용되어지는 기존의 방법은 CRL로 알려진 CA의 무효된 인증서의 목록의 발행에 의한 방법이었다. CRL들은 응용프로그램에 의해 다운로드 되어지거나 특정의 사용자의 인증서가 무효화되었는지 또는 상기 사용자의 디지털 서명이 연장에 의하여 아직 유효한지 아닌지를 결정하는 의존집단에 의해 다운로드 되어진다. 시간이 지남에 따라 CRL들은 길어지고 통신과 데이터 처리에서 과부하를 발생하게 된다. 이러한 접근법의 추가적인 단점은 CRL들이 종종 드문 간격으로 발행된다는 것이다. (예를 들면 하루에 한번 또는 두 번) 이러한 이유로 인하여, CRL들은 종종 발행되자마자 바로 구식이 되어버린다. 무효화된 인증서는 인증서 유효기간이 지난 후에 CRL들로부터 단지 제거된다.

PKI 연계는 CRL들의 분포를 조정하여 CA들간의 상호운영을 제공하는 방법이다. 이러한 연계는 각자의 인증서와 보안 정책을 인정하기로 합의한 CA들의 세트 를 효율적으로 연결하는 중앙 CRL보관소이다. 모든 CA들은 그들의 CRL들을 상기 연계에 보낸다. 이것은 임의의 개인 또는 단체의 인증서의 집중화된 증명을 허용한다. 상기 인증서가 전에 무효화된 적이 없다면 이는 아직까지 유효한 것으로 여겨진다. PKI연계에 대한 가장 큰 단점은 이들이 인증서 상태를 위해 상기 연계에 의존하는 임의의 CA 또는 사용자에 접근 가능해야 한다는 것이다. 따라서 밴드폭(bandwidth), 연산, 및 저장장치 요구조건 등에서 비용이 많이 든다.

인증서 상태를 얻기 위한 더 최근의 방법은 IETF OCSP이다. 이는 실시간 인증서 상태를 제공할 수 있는 직접적으로 데이터베이스가 문의를 실행한다. 그러나 어떤 공급자는 CRL에 기초를 두는 제공되어진 OCSP응답기를 가지고 있다. 이러한 형식의 응답기에 의하여 보고되어지는 인증서 상태는 그들이 기초로 하는 CRL들 만큼의 현시성을 가진다. IETF SCVP와 같은 실시간 인증서 상태를 이루기 위한 시도가 계속적으로 이루어지고 있다. 본 발명의 경우에는 상태 확인 방법의 혼합 또는 매칭이 공개 PKI 환경에서 실질적이지 않았다.

인준을 인증하는 또 다른 접근법은 인증서를 발급했던 CA에 의한 전부가 아니면 모두 아닌 판단방법이다. 회원 CA들의 하나에 의하여 인증서가 발급된 모든 사용자들은 그들의 인증서가 정지되거나, 무효화되거나, 유효기간이 도과하지 않으면 정당하거나 가능한 사용자인 것이다. 참여를 제어하는 공통적인 주제는 인증서가 발행되었느냐이다. 발행은 인증서와 보안 정책과 업무규율에 의하여 지배된다.

상기 신뢰환경은 어떤 사람이라도 가입에 필요한 비용을 지불할 수 있으며 인증서를 발급하는 완전 개방형에서부터 폐쇄형 또는 부분 개방형까지 또는, 필요에 따라 기업 또는 이익 단체에서의 회원제의 형태가 있을 수 있다. 어떠한 경우에서든, CA인증서 및/또는 보안정체가 상호운영이 가능한지 아닌지를 지배한다.

본 출원인의 발명은 상기 PKI와 CA 상호운용의 문제점을 상기 기술한 방법과 전혀 다른 시각에서 접근한다. 본 출원인은 전달 가능한 기록(소유권이 변경될 수 있다)이 될 수도 있는 전자적 원본 정보물의 생성, 실행, 유지, 전달, 회복 및 제거에 적절한 신뢰 환경을 설립하는 것에 초점을 둔다,

이러한 목적을 실현하기 위해서, 전자적 원본 또는 등본을 제어하는 상기 시스템은 이들의 어떠한 복사본으로부터 원본을 조회하는 것이 가능하도록 할 수 있어야 한다. 종이문서의 원본에서처럼 단 하나의 원본만 존재할 수 있다. 전달 가능한 기록의 예는 전자적 협상 가능한 기구와 보안들이 있다. 전자적 원본 기록은 그것이 전달 가능한 기록으로서 자격이 있거나 또는 없음에 따라 임의의 소스 기록일 수 있다. 시스템 간의 전자적 원본 기록의 전달은 단 하나의 원본이 존재한다는 것을 보장하는 방법을 이용하여 이루어져야 한다.

본 발명은 기록의 소유자의 이익을 위하여 운영되어지는 신뢰성 있는 독립적인 집단, 기능단(functionary) 또는 TCU의 측면에서 상기 기록의 보관을 이룸으로써 전자적 원본 기록을 생성한다. 신뢰 환경을 생성하는 것이 필요하나 전자적 소스 기록을 유지하기 위해 충분한 것은 아니다. 본 발명의 목적을 위하여 신뢰환경은 각각의 회원, 조직 및 이들의 사용자의 신원이 단체에 가입을 허락할 것인지를 결정하는 적절한 검증 절차를 이용하여 확인되어지는 폐쇄형 또는 국한 되어진 경계를 갖는 회원제의 이익집단의 형성에 의하여 생성되어진다. 더욱이, 개인의 조 직, 참여, 역할 및 속성은 TCU에 등록하는 시점에 정의된다. 개인들은 상기 시스템과 그들의 진정 인증서에 특유하게 정의되어야 한다. 또한, 상기 단체로부터 개인과 조직을 제거하는 것과 이러한 활동이 단체의 다른 회원들에게 알려지는 것이 가능하도록 하여야 한다. CA상호운영의 전통적 접근법은 이러한 목적들을 적절히 이룩하지 못한다.

최소한의 신원조회는 조직 및/또는 개인이 단체의 알려진 회원에 의하여 후원되어야함을 요구한다. 또한, 던과 브레드스트리트-형 순위매김(Dun and Bradstreet-like rating) 또는 개인에 대한 이퀴팩스-형(Equifax-like) 신용도 확인, 또는 동등한 신용 및 지불 경력이 가능한 사업동반자, 고객 및 손님의 수용가능성을 평가하는데 이용될 수 있다. 신용조회조직 및 이의 후원된 사용자는 TCU등록이 허용되어지기 전에 믿을 만한 것으로 추정되어져야 한다. 조직이 회원권을 정의하는 계약항목에 합의한 후에 이의 후원된 개인에게는 상기 TCU에 이들이 접속할 수 있도록 하는 특유의 인식자와 암호가 각각 제공될 것이다.

일단 개인이 하나 또는 그 이상의 TCU들에 등록되면, 이들은 업무의 소유자에 의하여 업무에 참여자로 이름 붙여질 수 있고, 이들의 신원, 역할 및/또는 책임에 근거한 소스 기록들의 확인된 하위세트 또는 모든 것에 대하여 특별한 접근에 주어진다. 신원확인 및 진정성을 가용하게 하기 위하여 또한 전자적 형태에서 발생하는 업무가 가능하도록 하기 위하여, 이러한 신원확인 정보의 선택되어진 하위세트는 참여자의 진정 인증서에 포함되어진다. 상기 진정 인증서는 사용자의 신원과 이들의 매칭 서명 개인-키를 이용하여 생성되는 유효한 디지털 서명에 사용되어 지는 이들의 공개-키를 묶는다.

인증서 또는 보안정책은 인증서를 발행하기 전에 요구되는 신원조회를 위한 증거물(예를 들면, 사진이 있은 2가지의 신분증, 신용도 확인, 개인소개)을 요구한다. 상기 인증서는 디지털 서명 권한이 요구되어지면 사용자의 TCU 계정에 보내어질 것이다. 상기 연결은 특유하게 사용자를 확인하는 인증 데이터 요소(예를 들면, 인증 ID, 발행 CA이름, 사용자의 일반이름)의 하위세트를 포함할 것이다. 일단 사용자의 계정과 연결되면, 상기 인증서는 미리 결정된 위임되어진 행위의 세트가 가능하며, 상기 사용자의 제출되어진 정보물에 디지털 서명을 증명할 수 있도록 하기 위해 필요한 신원증명을 위하여 이의 디지털 서명과 연결된 형태로 사용될 수 있다. 이와 같은 내용은 전자적 기록의 세트를 제어하는 소유자 또는 소유자의 대리인이 상기 TCU를 소유권의 이전(예를 들면, 내부적 업무) 및/또는 전자적 기록의 보관소를 다른 TCU로 전달(예를 들면, 외부 업무)하는데 이용하는 경우에 특히 사실이다.

상기 기술된 바와 같이, 진정 인증서와 공개-키 암호화는 사용자 진정성 및 디지털 서명 증명을 지원하기 위해 사용되어진다. 상기 인증서는 수취인의 신분이 이들의 공개키에 의하여 기밀 되어지는 프로세스인 디지털적인 방법으로 상기 발행CA에 의하여 서명되어진다. 상기 CA는 인증서를 발행하는 경우에 상기 인증서에 의하여 확인되어지는 개인이 정보물 또는 이들의 조각에 디지털적으로 서명하는데 사용되는 매칭되는 개인키의 소유자임을 나타낸다.

본 발명은 PKI가 단지 가능성을 확인하는 용도로만 쓰이고, 신용환경의 유일 한 기본요소가 아니라는 점에서 다른 PKI기반의 전자상거래 솔루션과 다르다. 후원관계, 회원권을 위한 계약 및 등록이 주요한 요소이다. 상기 인증서 및 공개-키 암호화의 사용이 가능한 기술로 보여 지지만 인증서는 특유하게 확인되어야 하며, 특별한 사용자의 TCU 계정에 접근할 수 있기 전에 그 사용자와 묶여져야만 한다.

인증서가 채용되어지는 경우에, 일단 이와 같은 사용자 계정과 인증서와의 결합이 이루어지는 경우에만 상기 계정은 활성화되어질 수 있다. 이 결합은 인증서 ID와 발행 CA를 상기 사용자의 계정정보에 단순히 추가하여 이루어질 수 있거나, 사용자의 구별되어지는 이름(ITU X.590 기준 참조)의 구성요소와 같이 인증서에 의하여 이송되어지는 다른 정보를 이용할 수 있다. 상기 결합정보는 등록양식에 이송될 수 있거나, 각각의 TCU 시스템 보안 정책에 해당하는 인증서로부터 바로 추출되어질 수 있다. 대응확인은 상기 인증서의 상기 사용자 기술이 등록 데이터상의 그것과 상기 인증서가 사용되어질 때 마다 매칭되는 지를 확인하기 위하여 사용되어질 수 있다. 상기 사용자의 인증서는 발행CA에 의하여 서명되어지고, 이의 보전성와 진정성은 발행 CA의 인증서와 공개키를 사용하여 증명되어진다. 신원확인을 위해 사용되어지는 수집된 구성물의 세트는 추측하건데 고유한 형태가 되어야 한다. 일단 이 TCU계정과 사용자 인증서 결합이 형성되어지면, 상기 TCU는 어디로 인증서 상태를 확인하러 가야하는 지를 단지 알아야할 필요가 있다.

CA중심적 환경에서는, 단일 PKI, 상호-인증 또는 PKI연계(다중 공급자 제품이 다수의 CA들에 의하여 사용되어지는 경우에 인증서 상태 확인을 수행하는 복잡한 시스템)의 생성이 상호운영을 위해 요구되어진다. 공통 요소는 모든 인증서가 동등한 가치를 가진다는 것이다. 인증서들은 다른 수준의 신뢰성을 이송할 수 있고 개방형 환경에서 응용프로그램은 이러한 신뢰성 수준을 다르게 사용하거나 해석하는 능력을 가져야 한다. 이러한 철학은 “우리는 당신이 가길 원하는 곳을 데려다 줄 길을 닦을 것이다”라는 표현으로 특성 지워질 수 있다. 사용자들은 다양한 판단기준(예를 들면, 신용도 확인, 결제수단, 인증서의 비용)을 이용하여 CA등록에서 평가되어진다.

거꾸로, TCU는 단지 "승인되어진 CA"의 알려진 세트와 연관되어지고, 이러한 세트(set)내에서 단지 이의 사용자 계정과 연계되어진 인증서들에 연관되어진다. 다른 인증서는 무시되어질 것이다. 이러한 철학은 “당신에게 열려질 단 하나의 길은 당신의 업무를 수행하기 위해 필요한 것일 것이다.”로 특성 지워질 수 있다. 사용자들은 두 번 조회되어지는데, 먼저 CA인증 정책을 만족하기 위해서 그리고 이들이 TCU에 등록되어질 필요가 있는 업무가 있는지를 증명하기 위해서이다. 상기 TCU에 의하여 요구되어지는 업무 규칙은 다른 신뢰수준에서 발행된 인증서를 수용할 수 있다.

발명의 요약

현재까지, 모든 인증서 상태 보고 서비스는 CRL, OSCP, LDAP 등의 하나의 인증서 상태 보고 수단을 사용한다. 본 발명은 이러한 점에 다르며, 이는 인증서 상태를 회복하거나 보고하는 목적을 위하여 어떠한 CA 또는 PKI와 상호 운영될 수 있다. 대부분의 경우에, 이는 또한 인증서 상태의 캐슁(caching)에 의하여 시스템 또는 TCU와 CA 인증서 상태보고 요소들 간의 실시간 연속 연결에 대한 신뢰성을 떨어뜨린다.

본 발명의 일 측면에서, 각각의 CA들에 의하여 발행된 진정 인증서의 인준을 위해 CSS를 제공하는 방법은 진정 인증서를 발행했던 발행 CA로부터 진정 인증서의 상태를 회복하기 위해 필요한 정보를 확인하는 단계; 상기 발행CA와 통신하기 위하여 확인된 정보에 기초하여 커넥터를 구성하는 단계; 상기 구성되어진 커넥터에 따라 발행 CA와 통신하는 단계; 및 진정 인증서의 상태를 회복하는 단계를 포함한다. 상기 발행 CA와 커넥터는 구성 기억장치의 승인된 CA들의 목록에서 지정되어진다.

지역 데이터 및 시간은 이들이 진정 인증서 유효기간에 지시된 유효기간 내에 해당하는지를 통하여 확인되어질 수 있다. 상기 발행 CA는 미리 결정된 업무 규칙에 따라 발행 CA를 조회하고 승인하여 승인된 CA의 목록에 포함되어질 수 있고, 상기 발행 CA가 조회되어지고 승인되지 않으면, 상기 발행 CA는 구성 기억장치의 승인되지 않은 CA의 목록에 지정될 수 있다. 상기 발행 CA의 조회 및 승인은 신뢰성 있는 진정 인증서의 대표를 CSS에 등록시키는 것과 최소한 상기 대표, 상태 및 생존시간(time-to-live) 데이터 요소를 지역 캐쉬 메모리에 추가하는 것을 포함할 수 있다. 이제 커넥터는 신뢰성 있는 진정 인증서의 상태가 문의되어질 때, 추가되어진 상태를 회복하기 위해 구성되어진다. 발행 CA들간의 통신 또한 커넥터의 순서에 따라 이루어질 수 있다.

상기 방법은 상기 상태에 대한 지역 캐쉬 메모리를 확인하는 것을 포함하고, 상기 상태가 상기 지역 캐쉬 메모리에서 찾아지고 지역 날짜 및 시간이 유효 기간 내에 있다면 상기 지역 캐쉬 메모리로부터 상기 상태를 회복하는 단계를 더 포함할 수 있다. 상기 상태가 상기 지역 캐쉬 메모리에서 찾아지지 않거나, 상기 지역날짜와 시간이 유효 기간내에 있지 않다면, 상기 CSS는 상기 발행 CA의 인증서 상태보고 구성요소와 통신 세션을 설립하고, 상기 구성된 커넥터에 따라 인증서 상태 요구를 구성하고, 상기 인증서 상태보고 구성요소로부터 상태를 회복하고, 인증서 상태보고 구성요소와의 통신 세션을 닫고, 그리고 최소한 진정 인증서의 신원확인, 상태 및 지역 캐쉬 메모리에 대한 생존시간을 더한다.

인증서 상태는 CRL에 의하여 지시되어질 수 있고, 상기 발행 CA의 발행스케줄에 따라 상기 CSS는 구성 기억장치에 리스팅된 인증서 상태보고 구성요소로부터 CRL을 회복하고, 상기 CSS는 상기 발행 CA연계된 캐쉬 메모리를 비우고, 상기 CSS는 상기 CRL로부터 진정 인증서의 상태를 결정하고, 상기 발행 CA와 연계된 캐쉬 메모리에 상태를 저장한다.

인증서 상태 또한 델타 인증서 무효화 목록("CRL")에 의하여 지시되어질 수 있다. 그리고 상기 발행 CA에 의하여 CRL이 사용 가능하다는 통지가 있는 경우, 상기 CSS는 상기 구성 기억장치에 리스트된 인증서 상태보고 구성요소로부터 상기 CRL을 회복한다. ; 상기 CRL이 완전한 CRL이면, 상기 CSS는 상기 발행 CA와 연계된 캐쉬 메모리를 비우고, 상기 CRL로부터 상태를 결정하고, 상기 캐쉬 메모리에 상태를 저장한다. ; 상기 CRL이 모든 CRL의 발행후에 일어난 변화를 단지 포함한다면, 상기 CSS는 상기 CRL로부터 상태를 결정하고, 상기 캐쉬 메모리에 상태를 저장한다.

본 발명의 다른 측면에서, 진정 인증서의 상태를 인준하기 위하여 TCU로부터 CSS로의 문의에 대응하여, 상기 발행 CA에 의하여 발행되어진 진정 인증서 의 상태를 회복하는 방법은 상기 CSS의 캐쉬 메모리에서의 상태가 존재(present)하고 현재(current)이면 그 상태를 위치시키고 보고하는 단계를 수행하고; 그렇지 않으면, 상태 타입을 얻는 단계와 CSS 구성 기억장치로부터 회복방법을 수행하고; 상기 상태타입이 CRL이고 상기 상태가 캐쉬 메모리에서 찾아지지 않으면, 상태를 유효한 것으로 보고하고; 상기 상태 타입이 CRL이 아니면, 상기 상태 타입에 따라 인증서 상태 요구를 구성하고; 상기 발행 CA와 통신 세션을 설립하고; 얻어진 회복 방법을 이용하여 발행 CA의 상태보고 구성요소로부터 상태를 회복하고, 상기 통신 세션을 종료하고; 회복된 상태를 해석하고; 상태 타입에 대한 CSS정책에 의하여 특정되어진 기간을 대표하는 생존기간을 회복되어지고 해석되어진 상태와 연계하고; 최소한 진정 인증서의 신원확인, 상태 및 생존시간 값을 상기 캐쉬 메모리에 더하고; 상기 문의에 대응하여 상기 TCU에 상기 상태를 보고하는 단계를 포함한다.

본 발명의 또 다른 측면에서는, 발행 CA들에 의하여 발행되어진 진정 인증서의 정확하고 적절한 상태 표시를 제공하기 위한 CSS는 상기 인증서의 발행 CA가 상태를 지시하기 위해 CRL들을 사용하는 경우에 CRL에 의하여 지시되어지는 바와 같이 진정 인증서의 상태를 제공하는 것을 포함한다. 그렇지 않다면, 상기 캐쉬 메모리가 상태를 포함하고 생존시간 데이터 요소가 초과하지 않을 때에 캐쉬 메모리에 의하여 지시되는 상태가 공급되어진다. 생존시간 데이터 요소가 초과되면, 상기 상태는 상기 캐쉬 메모리로부터 비워지게 되고, 상기 상태는 상기 상태가 상기 캐쉬 메모리에 없는 경우에 실시간 인증서 상태보고 프로토콜을 이용하여 요구되어지고 회복되어진다. 최소한 진정 인증서의 신원확인, 상태 및 생존시간 데이터 요소가 상기 캐쉬 메모리에 더하여 지고, 회복되어진 상태가 제공되어진다.

상태 사용-카운터 데이터 요소가 상기 캐쉬 메모리에 더해질 수 있으며, 상기 인증서의 상태가 확인되는 매번 마다 증가 또는 감소된다. 상기 상태 사용-카운터 데이터 요소가 한계값을 넘으면, 상기 상태가 제공되어지며 상기 상태에 따라 상기 캐쉬 메모리가 비워지게 된다. 상태 최종-접속 데이터 요소도 또한 상기 캐쉬 메모리에 더해질 수 있고, 상기 상태 사용-카운터 데이터 요소와 결합된 상기 상태 최종-접속 데이터 요소는 상기 인증서의 상태의 활동 수준의 결정이 가능토록 한다.

새로운 인증서의 상태를 회복하기 위하여 상기 CSS에 요구가 이루어지고 상기 캐쉬 메모리가 설정되어진 버터크기의 한계에 도달했을 때, 상기 CSS는 가장 오래된 날짜를 지시하는 최종-접속 데이터 요소에 대한 캐쉬 메모리를 검색하고 각각의 캐쉬 메모리 엔트리를 비운다. ; 그리고 난 후에 상기 CSS는 요구되어진 상태를 회복하고, 이를 상기 캐쉬 메모리에 위치하고, 상기 요구되어진 상태를 제공한다.

본 발명의 또 다른 측면에서는 증명할 수 있는 증거의 일련을 가지는 진정 정보물의 제어를 전달하여 제1집단과 제2집단간에 업무를 수행하는 방법은 신뢰되어진 보관소로부터, 최소한 신원과 암호키를 제출집단과 연결하는 제1진정 인증서와 제출집단의 디지털 서명을 갖는 제1디지털 서명블록을 포함하는 진정성을 갖는 정보물을 회복하고, 상기 회복되어진 진정성을 갖는 정보물에 상기 제2집단의 디지털 서 명블록을 포함하도록 하여 제2집단에 의하여 상기 회복되어진 진정성을 갖는 정보물을 회복하고, 그리고 상기 실행되어진 회복된 진정성을 갖는 정보물을 TCU에 전달하는 것을 포함한다.

상기 TCU는 상기 디지털 서명을 증명하고 최소한 CSS로부터 진정 인증서의 상태를 회복함에 의하여 상기 디지털 서명과 연계되어지는 진정 인증서를 인준한다. 상기 TCU는 상기 각각의 디지털 서명이 증명되지 않거나 각 진정 인증서의 상태가 유효기간이 도과 하거나 취소되면 디지털 서명블록을 거부하고, 최소한 정보물내에 하나의 서명블록이 거절되지 않으면, 상기 TCU는 상기 TCU의 디지털 서명과 날짜, 시간 지시자를 정보물에 첨가하고 제1집단을 위하여 상기 정보물의 제어를 취한다.

도 1은 CSS를 채용한 TCU 전자적 정보물 인준 과정을 도시한다.

도 2는 CRL들과 CRL들이 인증 상태 기억장치에 합쳐짐에 의한 백그라운드 CSS과정을 도시한다.

도 3은 나누어진 CRL들의 분리된 캐슁(caching), OCSP반응 및 다른 인증서 상태보고 방법으로부터 유도된 상태를 도시한다.

도 4는 디지털 서명이 정보물의 조각과 부가된 데이터에 적용되어지고 있는 경우에 예시 데이터 요소를 포함하고 있는 서명블록에 대한 확장 가능한 신택스(syntax)를 도시한다.

도 5는 CSS와 TCU의 상호작용과 회원과 외부 CA들로부터 인터넷을 통하여 인증서 상태의 CSS회복을 도시한다.

도 6은 인증서 상태 확인 단계를 종료하는 TCU 사용자 등록 과정과 이 경우의 디지털 서명 인준이 성공적인 등록을 나타내는 것을 도시한다.

도 7은 외부 CA가 사용자 인증서를 발행한 경우에 인증서 상태 확인 단계를 종결하는 TCU 사용자 등록과정과 이 경우의 디지털 서명 인준이 성공적인 등록을 나타내는 것을 도시한다.

도 8은 CSS가 어떻게 전자상거래에 사용되어질 수 있는 지를 나타내는 자동차 리스의 예를 도시한다.

인증서 상태 확인은 시스템이나 전자적 정보물 제출의 TCU 수용에 중요한 요소이다. 제출이 받아들여지기 위해서는 상기 인증서 상태는 유효한 것으로 보고되어져야 한다. 인증서 상태에 대한 요구는 일반적으로 TCU와 인증서 상태 소스와의 통신이 발생할 것을 요구한다. 이러한 통신의 발생빈도는 TCU제출의 수에 비례하여 늘어날 것이다.

인증서 상태 확인은 실시간 요구가 될 수 있으며 상태 요구는 매 제출마다 실행되어진다. 그러나 상태는 CRL들의 경우에서와 같이 실시간으로 갱신되어지지 않을 수 있다. 모든 CRL들은 일반적으로 하루에 한번 또는 두 번 정도 일정한 간격으로 발행되어진다. CRL의 회복과 반복되는 분석은 시스템 성능에 부정적 요소 로 작용한다. 본 발명은 상기 작업의 많은 부분을 CSS에 덜어 줌으로써 직접적인 연산과 통신 요구를 현격히 낮춘다. 단일 인증서 상태 프로토콜이 상기 TCU와 CSS사이에 세워졌다. 상기 상태 프로토콜은 IETF OCSP가 응용프로그램이 단일 인증서의 상태에 대해 CA를 문의하는 것을 허용하는 것과 유사한 속성을 가지도록 할 수 있으며 이를 통하여 프로세스의 과부하를 최소화할 수 있다.

상기 CSS가 공급되어지고, 이는 통신과 서로 상호운용되는 것이 필요한 모든 CA에 대한 인증서 상태를 프로세싱하는 수단인 그 위치에서 충분한 정보를 유지한다. 그러므로 상기 CSS는 응용프로그램 설계가 안정적이고 최적으로 이루어지는 것이 가능하도록 한다. 상기 CSS는 유용하게 인증서 상태를 분석하고 은닉하여 TCU의 상태 문의에 대응하는 상태대응시간을 최소화한다. 그러므로 상기 CSS는 PKI상호운영의 어떠한 전통적 형태에 대한 필요성을 제거한다. TCU 사용자 계정이 손쉽게 비활성화 되어질 수 있고 사용자들의 세트가 승인된 CA들의 CSS목록으로부터 CA를 지우는 것이 생략되어지므로 잠재적 보상 회복이 훨씬 향상되어진다.

진정 인증서의 사용:

상기 TCU에 로깅한 후에, 참여자는 공개키 암호화 및 그들의 진정 인증서를 사용함에도 불구하고 그들 자신의 진정성에 대하여 문의되어질 수 있다. 이와 같은 진정성 검증은 보안세션 설립, TCU서비스에 대한 요구 또는 디지털서명과 전자적 정보물의 제출과 연계되어질 수 있다.

어떤 사람이 TCU와 상호작용을 하기 전에 4가지의 조건이 만족되어져야 한 다. 1) 이들은 먼저 시스템 사용자로 등록되어져야 한다. 2) 이들은 단순히 읽기만을 수행하는 수준으로 접속하는 것이 아니라면 공개-키 짝과 이에 매칭하는 진정 인증서를 발행하여 이를 소유하고 있어야 한다. 3) 인증서는 승인된 CA에 의하여 발행되어져야 한다. 4) 상기 사용자의 인증서는 유효기간이 지나거나 비활성으로 보고되거나 취소된 것이 아니어야 한다. 상기 마지막 조건은 일반적으로 상기 TCU가 직접 인증서의 상태를 회복하기 위하여 발행 CA에 문의하는 것을 요구한다. 인증서 상태를 회복하기 위한 다양한 표준과 CA설정이 존재하기 때문에 이것은 쉽거나 단순한 작업이 아니다.

배경기술에서 설명하였듯이 다중 CA들 또는 PKI가 포함되는 경우에는 일반적으로 PKI상호운영의 어떤 형태가 요구되어진다. 본 발명은 인증서 상태 서비스(CSS)를 생성하여 이러한 필요를 제거한다. CA 상호-인증 또는 연계는 불필요하다. 왜냐하면 상기 CSS에 의하여 요구되어지는 지식은 승인된 발행 CA, 이들의 IP주소 또는 이에 준하는 것 및 인증서 상태를 보고하는 이들의 수단뿐이기 때문이다.

인증서 상태를 회복하기 위해서, 각각의 인증서 상태 방법에 대한 커넥터 또는 프로그램 모듈이 정의되어진다. 모든 진정 인증서는 대상(사용자)과 발행인(CA) 필드를 포함한다. 상기 발행인 필드는 TCU문의를 CSS에 직접전달하기 위해 사용되어지고 이후에 인증서의 상태의 존재에 대하여 이의 캐쉬를 확인한다. 상태가 존재하지 않으면, 상기 CSS는 상기 인증서의 상태를 회복하기 위하여 적절한 커넥터를 요구할 것이다. 다양한 방법(LDAP, OCSP, CRL 등)이 인증서 상태를 보고하 고 회복하는데 사용되어질 수 있을 것이다.

어떠한 TCU 행동을 수행하기 위해서는 사용자는 먼저 TCU에 로그인하여야 한다. 이에 성공하면 상기 사용자는 권한이 주어져 있다면 업무를 생성하거나 선택할 수 있다. 이들이 전자적 정보물을 제출하도록 허용된다면 그들은 이제 그렇게 할 수 있다. 전자적 정보물의 수령에 있어서, 상기 TCU는 필요한 디지털 서명 인준단계를 수행한다. 인증서 상태 문의가 작성되어지고 CSS에 보내어질 것이다. 유효한 상태가 돌아오면 상기 TCU는 권한 있는 복사본으로서 상기 제출물을 받아 저장할 것이고 그렇지 않다면 거절될 것이다.

디지털 서명 과정과 인증서 상태 확인:

디지털 서명은 정보물의 하나 또는 그 이상의 조각 또는 전체 내용에 적용될 수 있다. 디지털 서명은 업무과정의 정황내에서 상기 업무를 상황을 이루도록 하는 대리인이나 상기 업무에 해당하는 집단에 소유될 수 있다. 디지털 서명은 실제로 수행되어지는 과업에 관계된 추가적 정보에 적용될 수 있다. 그러한 예의 하나가 부동산증서에서의 구역 기록 표기법을 들 수 있다. 다른 예로는 집단의 서명을 TCU에 제출되어지는 정보물의 진정성을 증명하는데 적용한 것을 들 수 있다. 상기 후자의 예에서, 상기 제출자는 추후의 변경을 막기 위하여 전체 내용물에 디지털 서명이 그 안에 적용되어지는 정보물을 싸거나 기밀 할 수도 있다.

디지털 서명이 적용되어질 때마다, 상기 서명자는 그들의 디지털 서명에 적용되어지는 의도에 대하여 확인하도록 요구되어질 것이다. 최근의 법률에 의하여 요구되어지는 이와 같은 행위는 디스플레이 윈도우나 뿌려지는 화면에서 가독한 텍스트형태를 취할 수 있고, 암호화키와 인증서 기억장치인 암호화 토큰을 호출하는 그래픽 버튼 및/또는 로그온을 요구하도록 할 수 있다. 상기 수행의 의도의 실제적인 데모는 선택된 내용을 이용하여 사용자의 디지털 서명을 계산하고 서명블록을 형성하기 위하여 이를 이들의 진정 인증서와 결합하는 신뢰성 있는 응용프로그램의 사용을 통하여 이루어진다. 상기 서명 블록은 또한 진정 또는 부진정 데이터 요소를 포함할 수 있다. 진정 데이터 요소는 상기 디지털 서명 연산에 포함되어지고(예, w지역 날짜-시간) 디지털 서명에 의하여 보호되어지는 것으로 여겨질 수 있다.(보전성) 비진정 데이터 요소는 서명연산이후에 포함되어지고 보호되어지지 않는다. 도 4는 상기 데이터 요소와 서명 블록의 레이아웃을 포함하는 샘플 신텍스를 보여준다. 이는 도시된 예제에 불과한 것이므로 이를 문자 그대로 해석하지 말아야 한다.

상기 정보물과 어떤 서명블록은 취급의 용이성 및 정보과정을 가능하도록 하기 위하여 랩퍼(S/MIME) 또는 확장 가능한 정보 신택스(XML, HTML, XHTML)의 태그에 유용하게 위치시킬 수 있다. 상기 데이터 구조는 이제 인준을 위하여 TCU로 보내어진다. 거꾸로, 상기 서명블록은 독립적으로 상기 TCU에 보내어져 결코 상기 TCU를 떠나지 않는 실제적인 소스 레코드에 첨부되어진다. 후자의 경우에 각 서명블록은 별도로 인준되어진다.

상기 디지털 서명 인준 과정은 제출시점에서 이후에 수행되어지는 것과 다르다. 상기 TCU가 디지털 서명을 보는 첫 번째 시점에 4단계 인준이 이루어진다.: 1) 상기 디지털 서명을 증명하라, 상기 디지털 서명에 의하여 보호되어지는 내용전송과정에서 변경되지 않은 것을 증명하는 단계; 2) 현재 TCU시간이 개인의 진정 인증서의 허용할 수 있는 유효기간에 해당하는 지를 확인하라.(“전이 아니고”, “후가 아니고”); 3) 지역적으로 지정된 CSS를 이용하여 인증서 상태를 발행 CA, CRL 분배 포인트 또는 다른 승인된 인증서 상태의 소스로부터 요구하고 회복하라.; 4) 상기 TCU 사용자 계정 정보가 인증서에 이송된 것과 일치하는 지를 증명하고, 요구되어지는 행위가 상기 TCU 규칙 데이터베이스에서 위임된 것인지 증명하라. 상기 정보물의 제출자에 대하여 상기 프로세스는 하나의 추가적 단계를 부가한다. 이 다섯 번째 단계는 제출자의 신분이 현재의 세션을 TCU와 설립한 집단의 그것과 매칭되는지를 확인하는 것이다. 모든 테스트가 성공적이면, 상기 행위는 허용되어지거나/허용되어지고 상기 정보물은 받아들여지며, 이의 소유자를 위해 TCU에 의하여 보관되어진다. 어떠한 단계라도 실패하면 치료법이 실행된다.

이와 같은 초기 인증서 상태 확인이후에 상기 TCU 신뢰환경은 모든 보유 정보물의 진정성과 보전성을 유지한다. 새로운 버전의 문서가 제출되지 않는 한 어떠한 추가적인 인증서 상태 확인이 필요한 경우는 예상되지 않는다.

본 발명의 두 측면이 PKI 수단의 일반과정과 다르다. 첫째로 본 발명은 TCU(또는 인증서 상태 인증을 요구하는 임의의 응용프로그램/시스템)라 불리는 응용프로그램의 존재와 이의 전자적 원본 소스 기록을 생성하고 유지하는 능력에 기초하고 있다는 것이다. 둘째로 "발행 CA"는 단지 상기 신뢰환경을 지배하는 정책과 연동하여 신분확인이 이루어지면 되고 CA 상호-인증이나 PKI연계가 필요치 않다 는 것이다. "발행 CA" 포함을 위해 필요한 정당화는 문서화된 업무관계이다. 상기 TCU 등록 과정동안에 사용자 계정이 생성되어져, 효율적으로 사용자 계정과 사용자의 진정 인증서를 결합하는 사용자 특정 인증서 정보를 참조한다.

TCU 사용:

전형적으로 일단 조직이 TCU의 서비스를 이용하기로 합의하면, 그 조직의 업무에 접근하는 제어는 그 조직의 대리인에게도 허용되어진다. 상기 조직의 대리인은 그 이후에 상기 조직의 업무에 관한 선택된 행위를 수행하도록 그들이 위임한 개인의 세트를 구분한다. 모든 행위는 사용자가 TCU에 계정을 가지고 이러한 계정이 활성화되고 상기 사용자는 로그온 ID를 가지고 적절한 패스워드 또는 대응하는 도전문구를 제공할 수 있을 것을 요구한다. 더욱이 버전이 나누어진 전자적 원본 소스 기록의 세트로 이루어진 각 업무는 업무 프로세스에서 다른 단계에서 사용자 접근을 지배하는 허용의 세트를 가진다. 이는 업무의 일반적인 과정에서 업무 프로시드로서 업무 기록에 대한 권리를 허용하거나 제거함- 즉 영원한 보류 또는 파기를 통한 개시와 같이-에 의하여 예증되어진다. 일단 허용되어지면 전자적 소스 기록을 보기 위해서는 단지 상기 TCU에 로그온 하는 것만 요구되어진다. 그러나 임의의 시스템 수준 행위 또는 도입 또는 전자적 소스기록의 변경은 개인이 추가로 공개키 암호를 이용하거나 그들의 디지털 서명과 진정 인증서를 적용하여 진정성을 제공하는 것이 요구되어진다. 모든 예에서, 상기 개인의 신분확인은 유효해야 한다. 디지털 서명이 채용되어진 경우에 이는 1) 사용자가 적절한 접근허용을 가질 것, 2) 상기 디지털 서명을 복호화하는 것과 파쇄와 메시지 다이제스트가 수행되어진 내용물이 변형되지 않았음을 증명할 것, 3) 제출 시간이 인증서 유효기간에 해당하는지를 확인할 것, 4) 사용자 인증서가 아직 유효한지 확인할 것을 수반한다.

인증서 상태 확인은 상기 발행 CA 또는 인증서 상태 응답자가 문의되어질 것을 요구한다. 이 단계는 매 진정 행위 또는 전자적 소스 기록 제출과 함께 행해져야 하기 때문에 통신 배드폭이 과도하게 될 수 있고, 지연, 백로그(backlog) 및 무응답 또는 느린 상태 응답으로 인한 거절을 야기할 가능성이 있다. 본 발명은 이러한 것에 주안점을 두고 TCU작동의 높은 신뢰성과 TCU와 상호 작용하는 모든 집단유효성을 확신하는데 주안점이 있다.

상기 TCU가 운영되어지는 높은 신뢰성의 환경에서, 인증서 상태 확인은 서비스가 자격을 갖는 사용자에 의하여 요구되질 때만 필요하다. 정보물에 대하여, 인증서 상태는 제출시점에만 확인되는 것이 필요하다. 모든 디지털 서명이 유효한 것으로 결정되면, 상기 정보물은 이후에 진정한 것으로 추정된다. 보안과 과정상의 실시와 방법들은 TCU에 배치되어 부진정 문서의 변형이나 소실을 일으키는 부당한 행위와 하드웨어 결손을 막을 수 있다. 매 제출은 새로운 버전의 전자적 소스기록을 생성한다. 상기 TCU는 최근의 소스 레코드 버전에 해당하는 지식을 유지하는 책임이 있다. 상기 버전은 전자적 원본 또는 전달 가능한 기록으로서 확인되어질 수 있다. 상기 TCU는 믿을 수 있는 날짜-시간 스탬프를 소스 기록에 더하고 이후에 이의 디지털 서명을 적용하고 이의 인증서를 첨부하여 원본 소스 레코드를 제어하는 가정을 예시한다. 랩퍼(wrapper)가 보안 및 프로세싱 편의를 위하여 소스 레코드에 적용되어질 수 있다. 이러한 버전닝(versioning) 과정이 단독의 진정화된 증거의 자국과 보관을 생성하지만 분리된 잉여의 관찰 기록이 확실성을 위하여 유지되어진다.

본 발명의 CSS는 오늘날 PKI와 전자상거래에 지속되어오는 상기 기술된 한계를 극복한다. 회원 CA들로부터 인증서 상태를 얻는 것이 요구되어지는 소스 정보는 이들이 생성되어지는 경우에 상기 CSS에 등록되어진다. 외부의 승인된 CA에 대한 소스 정보는 상기 사용자 등록 과정 동안에 입력되어질 수 있다. CSS 회복정보는 매 인증서 상태 소스에 대하여 요구되어진다. 인증서 상태 소스의 형식에는 다양한 형태가 있고 상기 CSS는 커넥터나 각 등록된 형식에 대한 방법이 요구되어진다.

인증서 상태를 이송하기 위한 어떤 CA들에 의해 사용되어지는 방법의 하나는 CRL이다. 이는 취소되어진 인증서의 목록과 취소된 이유와 CRL이 발행되어진 경우에 CRL의 발행자와 CRL의 다음 버전의 발행 시기를 포함한다. 모든 CRL은 그들의 보전성과 진정성을 확신하기 위하여 발행 CA나 지정된 서명자에 의하여 서명되어진다. 인증서는 이들의 유효기간이 일단 지나면 상기 CRL로부터 제거되어진다.

CRL이 사용되어지는 경우에, 상기 CSS는 X.509 v2 CRL 프로파일(IETF RFC2459, 1999년 1월)과 같은 CA배분 포인트로부터 CRL의 최근 본을 회복하고, 이의 서명을 인준하고, 이를 나누어 그 결과를 저장하기 위해 캐쉬를 생성한다. 상기 CSS는 언제 다음 CRL을 다운로드 실행할 것인지를 지배하기 위해 CA의 CRL발행 간격을 이용한다. 모든 CRL은 다운로드를 실행할 때 어떤 여지를 제공하도록 일반 적으로 설정되어지는 유효성 필드를 포함한다. 이는 통신정체와 CA다운시간을 염두에 둔 것이고 이 간격을 넘어서면 상기 CSS가 치료행위를 요구하도록 할 것이다. 이와 같은 치료는 새롭게 추가된 취소된 인증서와 연계되어지는 어떠한 제출을 재인준하는 것을 포함할 수 있다. 매 새로운 CRL은 전에 로드된 CRL을 대신한다. 이러한 법칙의 예외는 델타 CRL과정에 대한 것이다. 델타 CRL의 내용은 현재 캐쉬 내용에 추가되어진다. 델타 CRL 기초 CRL번호는 발행된 가장 최근 전체 CRL을 참조한다. 델타 CRL은 더 짧은 간격(분, 시간)으로 발행되며 최근 전체 CRL이후에 인증서 취소가 일어나는 경우에만 발행된다. 상기 CSS는 발행 간격 또는 고지에 기초하여 CRL과 델타 CRL을 회복하는 책임이 있고, 이는 TCU 보안 정책에 설립된 간격을 초과하지 않는다.

인증서 상태를 배포하기 위해 CA에 의해 사용되어지는 두 번째 방법은 OCSP이다. OCSP가 사용되어지는 경우에는 상기 CSS는 인증서 상태를 요구하는 경우에는 OCSP응답자를 문의하게 된다. OCSP응답은 이들의 보전성과 진정성을 보장하기 위하여 서명되어진다. 상기 CSS는 상기 OCSP 응답을 분해하고, 또 다른 캐쉬에 인증서 상세 및 상태를 추가한다. 지역 TCU 보안 정책에 의하여 결정되어지는 생존시간 플래그가 포함되어지고 이는 상기 엔트리가 상기 캐쉬로부터 언제 제거될 것인지를 결정한다. 이러한 특성은 다수의 정보물이 짧은 기간 안에 동일한 집단/단체에 의하여 상기 TCU에 업로드되는 경우에 통신에 과부하가 걸리는 것을 최소화하는데 목적을 둔다. 상기 생존시간 플래그는 일반적으로 표준 CRL발행 기간(하루에 한, 두 번)보다 훨씬 짧을 것이다.(예를 들면, 5분) 상기 CSS는 인증서 취소가 발 생하지 않았음을 확증하기 위하여 캐쉬로부터 인증서 상태를 일소하기 전에, 하나이상의 정보물이 처리되어졌다면 인증서 상태를 다시 확인할 수 있다. 인증서 무효화가 상기 생존시간 간격동안에 발생했다면 접촉의 소유자 조직 포인트가 고지되어져야만 한다. 다양한 다른 문의 방법이 존재한다. 그러나 간결히 설명하기 위해 이에 대해서는 언급하지 않는다. 이들이 사용되어질 때에는 이들 각각은 커넥터와 잠재적으로 분리된 캐쉬가 요구되어진다는 것을 이해하여야 한다.

도 1은 전자적 원본을 생성하는 흐름도를 도시한다. 설명을 위하여 상기 정보물은 매매계역을 가정한다. 전자적 정보물의 복사본(실행되어지지 않은)이 상기 TCU 또는 문서준비시스템으로부터 회복되어지고 적절한 집단에 의하여 디지털적으로 또는 홀로그래픽적(수기)으로 서명되어진다. 실행과정을 감독하는 소유자의 대리인은 디지털 서명을 하고 상기 정보물을 싸고 이를 TCU에 보내기 위하여 신뢰성 있는 응용프로그램을 사용한다.

전자적 문서를 기존에 생성, 실행 또는 회복한 제출자는 101단계에서처럼 디지털 서명을 하고 이를 TCU에 제출한다. 이러한 전자기밀 과정에서, 제출자 및 기타의 다른 서명자의 인증서 및 디지털 서명을 더 포함하는 디지털 서명블록과 서명된 내용을 포함하는 랩퍼(WRAPPER)가 형성되어진다. 도 1에는 5가지 단계가 나타나있다: (1) 유효하지 않은 디지털 서명 및/또는 취소된 인증서가 찾아진 경우의 행동, (2) 상태가 지역적으로 캐쉬된 경우의 인증서 상태 확인, (3) 인증서 상태가 회복되어져야 경우의 인증서 상태 확인, (4) CRL회복 및 프로세싱, (5) 전자적 기밀된 문서가 진정한 것으로 결정된 경우에 전자적 원본 생성하기. 103단계에서, 상기 TCU는 전자적 기밀된 전자적 문서를 받는다. 105단계에서, 상기 TCU는 상기 제출자가 선택된 계정 및 또는 업무에 전자적 문서를 더하는 권한을 갖는다는 것을 인준한다. 107단계에서, 상기 TCU는 전자적으로 포장된 디지털 전자적 문서에 포함된 임의의 디지털 서명을 암호적으로 증명한다. 서명인의 X.509 진정 인증서에서 찾아지는 공개키는 상기 증명단계에서 사용되어진다. 109단계에서, 인증서 유효기간이 서명자의 진정 인증서로부터 추출되어지고, 111단계에서, 상기 유효기간이 현재 날짜 및 시간에 대하여 확인되어진다. 상기 언급된 어떠한 시험에 대하여 실패하는 경우에는 상기 제출은 113단계에서 거절되어지고 부정적 인식자가 114단계에서 보내어질 수 있다. 상기 행위의 일지는 117단계에서 기록되어진다.

상기 모든 시험에 통과하는 경우에는 상기 랩퍼내에 포함되어진 각 인증서에 대한 인증서 상태가 119단계에서 CSS로부터 요구되어진다. 121단계 및 123단계에서, 인증서 상태는 이것이 인증서 상태 기억장치에 존재한다면 조회를 위해 확인되어진다. 125단계에서, 인증서 상태는 회복되어지고 인증서 유효성이 127단계에서 확인되어진다. 어떤 인증서가 어떠한 이유로 유효하지 않은 것으로 판단되면 제출은 113단계에서 거절되고, 115단계에서 부정적 인식자가 보내어질 수 있다. 그리고 상기 행위의 일지는 117단계에서 기록되어진다. 상기 제출자는 적절한 치료법을 찾는 것이 예상되어진다.

127단계에서 모든 디지털 서명과 인증서가 상기 제출자에 대하여 유효한 것으로 결정되면, 129단계에서 상기 TCU는 날짜-시간 스탬프와 TCU디지털 서명블록을 포함하는 또 다른 랩퍼를 적용한다. 이에 따라 상기 TCU는 소유자의 기록을 위하 여 제출의 제어를 전자적 원본 기록으로 가정한다. 131단계에서 상기 TCU는 전자적 원본을 보호되는 지속적인 저장소에 위치하고, 133단계에서 상기 TCU는 긍정적 인식자를 전송하고, 117단계에서 상기 TCU는 막 완료된 행위의 일지를 기록한다.

123단계에서 상기 인증서 상태가 상기 인증서 상태 기억장치에 존재하지 않는 것으로 결정되면, 135단계에서 상기 CSS는 상기 시험중인 인증서로부터 발행 CA필드를 회복한다. 137단계에서, 상기 CSS는 상기 발행 CA가 승인된 CA목록에 있는지 조회하기위해 확인한다. 이는 139단계에서 CA커넥터 기억장치에 의하여 유지되고 접근되어질 수 있다. 이와 같은 승인된 목록은 또한 CSS가 다중 PKI, 독립적 CA 및 인증서 상태 응답기로부터 인증서 상태를 연결, 요구 및 회복을 가능하게 하는 충분한 정보를 포함한다. 상기 CA가 목록에 없으면, 유효하지 않다는 상태가 리턴 되며 프로세스는 125단계를 재가동시키고 127, 113, 115 및 117단계가 차례로 수행되어 제출의 거절과 부정적 인식자의 전달 및 이에 대한 기록일지의 작성이 이루어진다. 상기 발행 CA가 137단계에서 상기 승인 CA목록 상에 발견되고 114단계에서 상기 인증서 상태 보고 메카니즘이 CRL이라는 것이 결정되면, 유효하다는 상태 지시가 125단계에 리턴 되어진다. 상기 CA는 알려져 있고, 상태는 상기 대상 인증서에 대하여 존재하지 않으나 상태 메카니즘은 CRL이라면, CRL이 존재하고 CA에 대하여 현재(CURRENT)인 경우에는 상기 인증서 상태는 유효한 것으로 추정되어질 수 있다. 상기 프로세스는 127, 129, 131, 133 및 117의 단계를 통하여 진행되고, 이를 통하여 전자적 원본의 생성, 긍정적 인식자의 전달 및 막 완료된 행위에 대한 일지기록이 이루어진다.

141단계에서 상기 인증서 상태 보고 메카니즘이 CRL이 아닌 것이 결정되면, 137단계에서 얻어진 상기 커넥터 정보가 인증서 상태 보고 메카니즘을 문의하는데 사용되어진다. 상기 커넥터 기술내용에는 적당한 인증서 상태 보관소를 문의에 필요한 모든 구성 정보가 포함되어질 수 있고, 이에는 CA, 디렉토리 또는 다른 형태의 인증서 상태 보관소가 해당될 수 있다. 145, 147, 149 및 151단계와 연계된 상태 기억장치(즉, 각각 LDAP 디렉토리, OCSP 응답기, 데이더베이스 및 서버)는 이러한 보관소의 예에 해당한다. 143단계에서의 문의에 대응하여, 이들 중의 하나는 인증서 상태 정보에 대한 응답이고, 상기 상태는 153단계에서 인증서 상태 기억장치에 더해진다.

153단계에서 더해지는 경우에, 상기 인증서 상태 기억장치내 프로세스가 121단계에서 다시 수행되어지고, 123, 125 및 127단계를 통하여 계속되어져 상기 제출은 받아들여지거나(129, 131, 133, 117단계), 거절되는(113, 115, 117단계) 결론에 도달하게 된다.

의심스런 타협이 보고되거나 방침(policy)이 즉각적인 응답을 필요로 하는 때, 미리 정해진 간격으로 155단계에서 그리고, 필요한 바대로 157단계에서 CRLs는 발행된다. 이 단계는 그림 2에서 잘 묘사되어 있다.

만약 CA가 알려져 있고, 상태(status)가 존재하지 않는다면, 그리고 상태 기작이 CRL이 아니면, 인증 상태 서비스(Certificate Status Service)는 연결자(connector)를 선택하고, 인증 상태 기작을 질의한다(143단계). 연결자는 상태 검색과 해석을 가능하게 하는 필요한 정보를 가지고 있다. 145 - 151단계에서 묘사된 실시간 인증서 상태의 출처 중 어떤 것이라도 인증서 상태 질의에 현재 상태로 응답할 것이다. 그러나, 이 단계은 그러한 자료에 한정되지는 않는다. 상태는 수신되 어 153단계에서 인증 상태 저장소(Certificate Status Store)에 추가된다. 상태가 추가된 때, 125단계에서 재개되고, 전에 설명한 것과 같이 완료되는 상태의 단계과 같이, 응답이 생성되고, 조치가 123단계로 회신된다.

이제 그림 2에 대해 언급하며, CSS는 이면 실행(background process)으로 CRL 검색을 수행한다. 현재 일자와 시간이 인증서에 들어 있는 유효기간을 넘어설 때까지 CRL은 모든 취소되거나 정지된 인증서의 목록을 보유한다. 정지된 인증서는 마치 취소된 것처럼 처리된다. 그러나 그것들은 복원될 수 있고, 그 결과 CRL에서 제거된다. 취소된 인증서는 복구될 수 없다.

155단계에서, CA 관리자는 미리 정한 간격으로 CRL을 발행하도록 CA를 구성한다. 157단계에서, CA 관리자는 구역 인증서(local certificate) 또는 보안 방침에 의해 지시된 바대로 델타 CRL을 또한 발행할 수도 있다. CA 관리자 또는 CA는 델타 CRL의 발행에서 공지사항(notice)을 넣을(push) 것이다. 인증서가 취소되거나 정지된 때마다 전체 CRL의 발행 사이에, 델타 CRL은 생성될 수 있다. 델타 CRL은 취소된 CRL의 모든 목록을 담을 수 있다. 201단계에서, CRL과 델타 CRL은 CRL 저장소 또는 디렉토리(directory)에 발행된다.

203단계에서, CSS는 CRL 발행 일정표 또는 델타 CRL 공지사항을 검색한다. 그리고, 205단계는 예정된 검색에 사용된 타이머(timer)를 나타낸다. 타이머는 모든 CRL에 함유된 "차기 경신" 영역(field)에 근거한 검색을 허용한다. 207단계에서, CRL 또는 델타 CRL은 CRL 저장소에서 검색된다. 209단계에서, CRL 또는 델타 CRL은, 121단계에서 인증서 상태 저장소에 있는 적당한 캐시 또는 목록, 또는 설정 된 일정 또는 공지에 기초한 디렉토리에, 153단계에서 부가되기에 앞서 분석된다. CRL을 분석하는 것은 CRL 기재사항을 열람하는 데에 보다 쉬운 관리하고 경상비용을 경감시킨다. CSS의 119, 123, 125, 135, 137 그리고, 141단계는 완결을 위해 그림 2에 묘사되어 있다. 그리고 그림 1과 연결된 부위에 묘사된 것과 같이 이행된다.

이제, 그림 3을 언급하면, 인증서 상태 저장소는 다른 답신(reporting) 기작에 의한 인증서 상태를 저장하는 수많은 캐시(cache)를 가지고 있다. 캐시(그중 5개는 그림 3에 그려져 있다)는 개인 CA 또는 CA 모음으로 할당될 수 있다. 실시간으로 답신된 상태를 위해, 상태는 공간이 필요하거나(적어도 자주 사용되는 것 같이), 방침 요구(특정 시간 동안만 유지하는 것 같이)에 근거하여 캐시에 남아있는다. 일단 기준이 초과되면, 상태는 정상적으로 제거된다.

캐시의 목적은 방침이 정한 기간 동안 인증서 상태를 유지한 것이다. 그렇게 하여, 인증서 상태와 CRL 검색 동안 필요한 통신 비용을 감소시킨다. 그러므로 CSS는 통신 중단시간(outage)의 간격을 메울 수 있다.

CRL은 분석될 수 있다 그리고 개개의 취소된 인증서 상태는 CRL이 반복적으로 검색되어야 할 때, 컴퓨터 비용을 감소하기 위해 캐시에 있게 된다. 이것은 캐시 305, 307로 묘사되어 있다. 캐시의 내용은 새로운 전체 CRL이 검색될 때마다 바뀌어 진다.

이제 그림 4를 언급하면, 디지털 서명 영역에 포함되어야 하는 보다 중요한 자료 요소들 몇 개를 표시하는 사례 구문이 나와 있다. 그림 4는 다중의 메시지 단 편과 일자/시간 인장에 적용되는 디지털 서명을 이루는 자료 요소의 자유 형태 사례이다.

이 사례는 디지털 서명 영역에 사용될 수 있는 구문의 묘사한 것이다. <CumulativeHashValue> 자료 요소는 하나 또는 그 이상의 단편 또는 전체 내용의 HashValue, 그리고 어떤 인증된 자료(Authenticated Data)에 적용될 수 있음이 주목될 수 있다.

그림 5는 인증서 상태 서비스를 지탱하는 건축자재를 나타내는 확실한 통신 구조(architecture)를 묘사한다. 그림은 3개의 CA, CSS, TCU간의 상호작용을 보여 준다. CSS는 높은 접근성(availability)를 보장하기 위해 TCU은 부근에 적당히 배치된다. 그것의 주된 목적은 TCU에 통상의 인터페이스(interface)를 제공하고, 인증서 상태 정보의 정확하고 시의적절한 공급을 확보하는 것이다. 그것의 부가적인 목적은 인증서 상태 정보를 유지하는 데 필요한 통신과 컴퓨터 비용을 조절하여 서비스의 보증된 수준과 질을 확보하는 것이다.

그림 5에서 보여지듯이, CSS 서버와 TCU는 적당한 통신 라우터(router)와 허브(hub)와 함께, 통신 방화벽 뒤에 유리하게 배치되어 있다. 라우터와 허브는 CSS와 TCU에 적당하게 정보를 전한다. 이 정보 중 어떤 것은 전술한 바와 같이 사용자 클라이언트 응용프로그램(User Client Application)으로부터 인터넷과 같은 네트워크를 통해 TCU로 전달되는 eSeal 제출서를 포함한다. OCSP를 경유하는 CSS와 TCU 통신이 또한 그려져 있다.

그림 5는 각각의 통신 방화벽의 뒤에 다른 전형적인 환경에 있는 3개의 CA를 그리고 있다. 기업 CA는 점선에 의해 포함된 임대 산업 CA(Lease Industry CA)와 인접하는 서버를 포함하였다. 외래 PKI 또는 응답자(Responder)는 PKI, CA 그리고, 인증서 상태 응답자와 같은 실체와 인접하는 서버를 포함하였다. 계층 구성원 PKI(Hierarchical Member PKI)는 CRL 및 인증서 상태에 대한 V3 LDAP, 루트(Root) CA, 그리고, 저당 및 임대 산업, 임대인, 결산 대리인(closing agents) 및 소유권 보증인에 대한 CA와 같은 실체와 인접하는 서버를 포함하였다.

그림 6 및 7은 각각 구성원 CA 및 외부 CA에 대한 사용자 등록단계 동안에 인증서 상태 서비스의 사용을 그리고 있다. 구성원 CA는 사용자 인증을 발행하는 것을 신뢰할 수 있는 사람이다. 외부 CA는 외부 객체에 의해 작동되는 것이며, TCU 작업에서 사용하는 데에 그들의 인증에 앞서 승인될 것이 필요하다. 사용자 신원 인증은 모든 CA에 의해 실시되거나 조직 대리인(organization agent)에 의해 대행되어 엄격하게 처리될 것이 요구된다. 추가적인 요구사항은 TCU가 사용자에게 접속을 허용할 수 있기 전에, 사용자 인증서가 직접적으로 가입되거나, 하나 또는 그 이상의 신청한 조직의 계정과 함께하는 사용에 대해 승인될 필요가 있다는 것이다. 일단 이러한 것이 이루어지면, TCU는 사용자의 디지털 서명을 받아들일 것이고, 인증서 상태 확인에 대해 CSS를 신뢰할 것이다.

그림 6에서, TCU 등록단계는 601단계에서 조직의 관리자/대리인에 의해 보증인으로부터의 사용자 등록 정보의 수령에서 시작된다. 603단계에서 이런 관리자/대리인은 요청을 작성하기 위해 보증인의 권한의 확인을 담당한다. 보증인은 보통 그들 계정에서 주어진 통제만을 한다. 605단계에서 관리자/대리인은 사용자 계정을 설정하여 TCU로 사용자를 등록한다. 607단계에서 관리자/대리인은 사용자에게 처리권한을 할당한다. 처리권한은 전자 원본과 다른 출처 기록을 제출, 변경, 전송 등을 하는 능력을 포함할 수 있다.

609단계에서, 암호표(전자 서명 기작)는 초기화되고, 611단계에서, 표에 공용키 한벌이 생성된다. 613단계에서, 인증서 요청이 생성되고, 615단계에서, 요청은 조직의 CA로 보내진다. 617단계에서, 인증서는 검색되고 표에 위치된다. 619단계에서, 인증서는 사용자 TCU 계정에 연결되거나, 또는 연계된다.

621단계에서, 예를 들면 개인적으로 사용자 신원을 확인할 수 있는 조직의 관리자/대리인에게 보임(appear)으로써 사용자 신원이 확인된다. 보통, 적어도, 신원의 2가지 형태가 필요하다. 사용자 참여가 보증되어(sponsored) 있으므로, 고가의 거래를 제외하고는, 관리자/대리인에 알려져 있는 누군가가 사용자의 신원에 대해 보증할 것을 요청받을 수 있는 곳에서 이것을 충분할 것이다. 623단계에서, 사용자는 사용자의 디지털 서명의 사용이 합쳐지는 것에 동의하는 계약 동의서에 서명할 것을 요청받는다. 625단계에서, 사용자는 필요할 것으로 판단되는 실용 사용자 설명서와 모든 지침을 받는다. 627 및 629단계에서, 사용자는 로그온 ID와 임시 비밀번호(password) 및 암호표를 제공받는다.

631단계에서, 사용자는 시스템에 로그온하고, 633단계에서 시험 문서를 TCU에 보낸다. 635단계에서, TCU는 사용자의 디지털 서명 및 인증서를 확인한다. 637단계에서 TCU는 CSS에 인증서 상태 정보에 대해 질의한다. 639단계에서 TCU는 상태를 수신하고, 그에 따라 진행한다. 만약 수신된 인증서 상태가 유효이면, 등록은 641단계에서 완료하고, 사용자는 TCU에 접근하고 사용할 수 있다. 만약 인증서 상태가 무효이면, 등록은 643단계에서 중단되고, 관리자/대리인은 에러(error)의 원인을 정하고, 구제방법을 만든다. 그런데 그 방법은 대강 설명된(outlined) 등록 단계의 일부 또는 전부를 반복하는 것을 포함한다. 그림 6에 설명된 신뢰성 있는 단계는 등록자가 완전하게 완성할 수 있는 것을 보장한다.

그림 7에서, 만약 방침 지시된 조건에 합치하면, 사용자는 외부 CA에 의해 예전에 발행된 암호표를 사용하는 것이 허용된다. 전술한 것과 같이, 601에서 607까지의 등록단계가 이어진다. 사용자 신원 확인 및 계약 단계(621에서 627) 역시 전술한 것과 같이 이어진다.

사용자는 이미 표(token)를 가지고 있기 때문에, 단계는 그림 6에 설명된 것에서 벗어난다. 701단계에서 사용자는 표를 적당한 판독기(reader)에 놓고 로그온 한다. 703단계에서, 관리자 응용프로그램은 표로부터 사용자 인증서를 검색한다. 705단계에서, 인증 정보는 표시되고, 발행하는 CA 신원 정보가 얻어진다. CA 정보는 CA가 승인 목록에 있는 것을 확인하기 위해, 707단계에서 사용된다. 만약 CA가 승인 목록에 없다면, CA 정보는 709단계에서 TCU 관리자에게 제공되고, 관리자는 711단계에서 등록을 계속하는 승인을 위해 응용프로그램 방침 결정권자 (Application Policy Authority)을 검색한다. 응용프로그램 방침 결정권자가 외부 CA를 승인 목록에 추가하는 것을 허가할 수 있다.

만약 713단계에서 승인이 거부되면, 등록은 사용자에거 3가지 선택사항(option)을 주면서, 649단계에서 중단된다. 하나는 구성원 CA에 의해 발행된 표를 요청하여 사용하는 것이다. 두번째는 CA 거절 결정의 재검토를 요청하는 것이다. 세번째는 이전에 승인된 외부 CA의 이름을 요청하는 것이다.

만약 발행하는 CA가 승인되었으나 713단계에 있는 목록에 없다면, 715단계에서 관리자는 CSS를 CA로 부터 인증서 상태를 검색하는 것으로 구성하여, CA와 연결자 정보를 승인 목록에 추가한다.

619단계에서 사용자 인증서는 새롭게 만들어진 사용자 계정에 연결되거나 연계된다. 그림 6 및 631단계에서 639단계와 같이, 사용자는 계정이 맞게 설정되었는지 그리고 사용자가 TCU에 접근할 수 있는지 확인하기 위해 TCU에 시험 제출을 할 것을 요청 받는다. 만약 CSS가 유효의 상태 정보를 회신하면, 등록은 641단계에서 완료한다. 만약 CSS가 무효의 상태를 회신하면, 관리자는 에러(error)의 원인을 정하고, 구제방법을 만든다. 그런데 그 방법은 전술한 등록 단계의 일부 또는 전부를 반복하는 것을 포함한다. 아마 실패의 원인은 CSS가 도달하여 외부 CA에서 인증서 상태를 올바르게 검색할 수 있는 것과 관련이 있을 것이다.

CSS는 TCU 또는 다른 시스템에 접근하는 때에 사용자 인증서와 발행하는 CA가 모두 허가된 것인가를 확인하는 데에 있어서 중요한 역할을 한다. 만약에 발행하는 CA를 승인 목록에서 제거하고 그것의 연결자 구성 자료를 삭제하면, 모든 관계된 사용자는 이후 TCU 접근이 불허된다. CSS는 다중의 PKI와 CA와 상호 작동(inter-working)을 요구하는 응용프로그램과 시스템을 포함하여, 인증서 상태를 요구하는 다른 응용프로그램 및 시스템과 같이 작동할 수 있다는 것을 이해해야 한다.

예를 들면, CSS의 또다른 사용은 스스로 서명한(self-signed) 인증서를 포함하는, 신용 인증서(trusted authentication certificate)를 제공하는 것이다. 그리고 동의는 서비스를 찾는 고객과 응용프로그램 운영자간에 존재한다. 신용 인증서(예를 들면, PEM, 인증서 ID, 응용 디지털 서명)의 표현은 CSS에 의해 임시로 저장된다(cached). 그리고, 상태는 신용 인증서 연결자를 이용해 질의된다. 이것은 응용프로그램이 인증서가 스스로 서명했는지 또는 CA에 의해 발행되었는지와 관계없이 하나의 인증서 상태를 가질 수 있게 한다. 이러한 신용 인증서 방법은 공동체의 CA(s)를 질의하는 것보다 단체에 의해 통제된 인증서의 작은 숫자가 사용되는 곳에서 사용될 수 있다. 그러므로, 이 응용프로그램에서 사용되는 것과 같은 "CA" 및 "발행되는 CA"라는 용어는 통상적인 CA 뿐만 아니라 스스로 서명한 인증서의 인정된 발행인과 같은 것도 포함한다는 것을 알아야 할 것이다.

더욱이, CSS는 인증서 상태를 검색하기 위해 연결자의 조합을 사용할 수 있다. 적어도 하나의 연결자는 신용 인증서 사용에 대해 방금 설명한 것과 같이 "가상의 것"이 될 수 있다. 인증서 상태가 확보될때까지 CSS는 미리 정해진, 예를 들어 지시된, 순서에 연결자를 호출한다(invoke). 이 방법은 상태 자료의 계층의 형성을 가능하게 한다(예를 들면 높은 신용도에서 낮은 신용도).

그림 8은 어떻게 CSS가 전자상거래(e-commerce)에서 이용되는지 보여주는 자동차-할부의 예를 묘사한다. 자동차 판매자 또는 판매자의 대리인(이후 판매자라고 한다)은 자동차 CA - 자동차 CA는 컴퓨터로 그려져 있다 - 에 의해 각각의 인증서(authentication certificate)를 발행받는다. 자동차 할부자 - 할부자는 자동차 판매 대리점에 있을 수 있다 - 는 은행 CA에 의해 각각의 인증서가 발행받는다. 원격의 대출자는 금융 CA에 의해 각각의 인증서를 발행받는다. 대신에 할부자나 대출자는 스스로 사인한(self-signed) 인증서를 생성할 수도 있다. 예를 들면 할부자는 판매자의 통상적인 고객이기 때문에, 판매자는 할부 프로그램(leasing application)과 CSS를 등록했다.

이 응용프로그램에서 설명한 바 대로, CSS는 승인된 보고 프로토콜(protocol)을 사용한 어떤 인증서 상태 보고 수단을 사용하여 이러한 그리고 다른 인증서에 대한 상태를 검색하고 보고한다. 그림 8에서 자동차 CA와 금융 CA는 OCSP를 사용하고, 은행 CA는 CRL을 사용하고, 판매자와 할부자는 인증서와 암호화된 서명 수단을 포함한는 어떤 형태의 표(예를 들면, PKCK#11, PKCS#12, 브라우져 키 스토어(browser key store))를 사지고 있다고 가정한다. 그림 8은 단순히 거래의 실시예라는 것을 알아야 할 것이다; 더 많거나 적은 CA가 특정한 거래에서 필요한 통신이 필요하게 연결될 수 있다.

801단계에서, 판매자는 임대 계약을 고안하거나 또는 판매대리점에서 지역적으로 실행되는 컴푸터 프로그램 또는 원격지에서 원격으로 실행되는 컴퓨터 프로그램, 즉 응용 서버와 같은 임대 응용 프로그램으로부터 검색한다. 803단계에서, 판매자는 임차인(lessee)과 임대인(lessor)에 의한 임대의 실행을 조정한다. 임대는 이때 로컬 임차인 및 원격 임대인 양자에 디스플레이될 수 있으며, 판매자는 질문에 대답하거나 필요한 경우 수정할 수 있도록 요구될 수 있다. 판매자는 임대인에게 URL(uniform resource locator)을 제공함으로써 임대인에게 임대 계약을 디스 플레이하도록 하여 임대인이 임대 계약를 리뷰하고 실행하도록 할수 있고, 실행된 버젼이 판매자에게 되돌아오도록 할 수 있다. 임대 계약서 상에 임차인의 전자 서명을 캡처하는 타블렛 pc 등으로 임차인과 판매상에 의한 로컬 서명 및 임대인에 의한 원격 서명 후에, 임대 계약서는 응용 서버와 통신하는 전자 저장고(electron vault)로 전송된다(805단계). 임차인 및 임대인에 의한 전자 서명은 유리하게 동적이고, 응용 서버는 "전자 서명된" 인디케이터를 디스플레이된 이미지에 적용시킴으로써 디스플레이를 업데이트한다. 실제의 전자 서명은 디스플레이되지 않는 것이 바람직하다.

응용 서버 및 관련 전자 저장고는 판매자에 의하여 임대인에 의한 원격 사인용 계약을 하는데 사용될 수 있다는 것이 잘 인식될 수 있을 것이다. 807 내지 811의 단계에서 임대인은 저장고로부터 임대 계약을 검색하고, 전자 서명함으로써 임대 계약서의 기간에 동의하며, 전자 서명된 버젼을 저장고로 보낸다. 807 내지 811의 단계는 멀티-사이트 콜래보레이션(multi-site collaboration) 및 어싱크러스 트랜잭션 프로세싱(asynchronous tranaction processing) 모두를 나타낸다.

813 내지 817의 단계에서, 받은 전자 서류(임대 계약서)에서 전자 서명을 체크하고, 만약 전자 서명이 발견되면, 전자 서명을 검증하고, 각각의 공인 인증서의 유효여부를 확인한다. 817단계에서 로컬 시간이 인증서의 유효 기간내에 포함되는지를 확인하고, 819단계에서, 인증서의 상태에 대하여 CSS에 질의한다. 821 단계에서 응답으로, CSS는 먼저 인증서 상태를 위하여 로컬 캐쉬 메모리 또는 데이타 스토어(data store)를 체크하고, 만약 인증서가 존재하고 현재 유통의 상태이면 CSS는 인증서 상태를 "활성"으로 돌려보낸다(827). 823 단계에서, 인증서 상태가 존재하지 않거나 현재 유통의 상태가 아니면, CSS는 이 목적을 위하여 만들어진 커넥터 타입(connector type)을 사용하여 발행 CA에 질의한다. 825의 단계에서, 예를 들면 뱅크 CA 등의 발행 인증 기관 또는 상태 보고 수단(예를 들면 디렉토리)은 바람직하게는 동일한 커넥터를 사용하여 CSS에 상태를 보내고, 827 단계에서 CSS는 질의된 인증 상태를 응용 서버에 재보고한다.

모든 전자 서명 및 인증서가 검증되고 그 유효성이 확인되고, 전자 서류의 진위가 입증된 것으로 추정되면, 응용 서버는 전자 서류의 제어를 추정하며 이를 새로운 버젼으로 전자 저장고에 저장한다(829). 따라서, 응용 서버 및 전자 저장고는 TCU로서 적당한 특징을 가지고 조력함을 알 수 있다. 831 단계에서, 새로운 버젼은 인증본으로 지정되고, 전자 원본(Electronic Original)은 날짜-시간 스탬프를 부착하고, TCU 전자 서명을 서류에 적용함으로써 전송 가능한 기록으로 될 수 있다. 서류상의 적어도 하나의 전자 서명이 유효한 이상, 이 단계는 수행된다.

833 단계에서, 어떠한 전자 서명 또는 인증서가 모든 테스트를 통과하지 못하는 경우, 판매자는 복구하도록 경고되며, 이는 전형적으로 유효한 대체 전자 서명이 적용될 때까지 801 내지 829 단계가 반복되는 것으로 구성되어 있다. 만약 서명자의 인증서가 취소되거나 만료된 상태이면, 새로운 인증서 및 암호화 물질이 발행될 때까지 복구 공정은 완결될 수 없다.

자동차를 위한 임대계약과 같은 모든 정보 객체는 전자적 형태 예를 들면, XNL, PDF, PKCS#7, S/MIME등으로 제공되어 전자 서명의 검출과 배치를 가능하게 하 고, 미인증된 변환을 방지할 수 있음을 이해할 수 있을 것이다. 따라서, 많은 이러한 형태는 포함된 정보에 대한 봉인 또는 안전 래퍼를 제공하는 것으로 간주될 수 있다.

또한, CSS는 키사용을 불문하고 인증서의 상태를 체크하는데 사용될 수 있음을 이해할 수 있을 것이다. 그러한 인증서는 일차 사용이 예를 들면, 키 합의/교환, 인증서 서명, CRL 서명, 키 암호화, 데이카 암호화, 암호만, 해독만, SSL(secure sockets layer)등과 같은 확인 및 인증을 위한 것이 아닌 것들을 포함하며, 이에 제한되지 않는다. 따라서, 본 응용에서 사용되는 용어 "인증서"는 일반적으로 확인을 위해 사용되지 않는 인증서도 포함하는 것임을 이해할 수 있을 것이다.

또한, CSS 커넥터는 단일 커뮤니케이션에서 하나 이상의 인증서 상태 체크를 유리하게 포함할 수 있다. 다른 것 중에서, 이러한 능력은 몇개의 또는 모든 유저/엔터티 인증의 체인 및 CA 인증 예를 들면, 루트 CA로 부터 발행 CA까지의 CA의 계층을 확인하는데 사용될 수 있다.

본 응용은 필수적인 발행 CA를 위한 인증 상태를 검색하기 위하여 필요로 하는 셋업 정보를 결정하는 단계, 발행 CA로부터 인증 상태를 검색하기 위하여 사용된 인증 상태 찾기 기술과 양립가능한 커넥터를 식별하는 단계, 선택된 카넥터 및 발행 CA에 특정한 셋업 및 커뮤니케이션 파마미터로 커낵터를 구성하는 단계, 발행 CA 및 커넥터간에 CSS 맵핑을 셋업하는 단계를 포함하는 CSS를 구성하는 방법을 개시한다. CA 지정 및 커넥터는 구성 스토어에 승인된 CA 리스트에 추가된다.

각 검증할 수 있는 에비던스 트레일을 가지는 공인된 정보 객체를 전송함으로써 트랜잭션을 실행하는 방법은 1차 파티에 의하여 신뢰할 만한 저장소로부터 공인된 정보 객체를 검색하는 단계를 포함한다. 공인된 정보 객체는 서브미팅 파티의 제1 디지털 서명, 서브미팅 파티에 대한 적어도 하나의 아이덴터티와 암호화키에 관한 제1 인증서, 신뢰할 만한 날짜와 시간, 신뢰할 만한 저장소의 전자 서명, 신뢰할 만한 저장소에 대한 적어도 아이덴터티 및 암호화키에 관한 인증서; 정보 객체의 진위를 증명하기위한 제출시 신뢰할만한 저장소에 의하여 확인된 서브미팅 파티의 전자 서명과 인증서; 및 신뢰할 만한 저장소의 통제하에 있는 전자적 원시 정보 객체로서 저장된 공인된 정보 객체를 포함한다.

트랜잭션 실행 방법은 어떤 서명 실체가 서명행위전에 전자 서명을 사용하도록 요구하는 단계; 어느 파티에 의하여 상기 정보 객체를 실행하는 단계를 추가적으로 포함하며, 적어도 서명 파티(signing party)의 전자 서명 및 공인 인증서의 포괄(inclusion), 적어도 서명 파티의 전자 서명 및 공인 인증서를 포함하는 서명 블록을 만드는 단계, 서명 블록을 정보 객체와 연계시키는 단계; 복수 주체가 정보 객체 및/또는 래퍼에 전자적으로 서명하는 이전의 실행 단계를 반복하는 단계, 및 전자 서명된 및/또는 싸여있는 정보 객체를 TCU에 포워딩하는 단계로 구성된다. TCU는 모든 전자 서명을 조회하고, 각 관련된 공인 인증서의 유효성을 확인하고 CSS로 부터 상태를 검색한다. 서명자의 전자 서명이 조회되지 않거나, 서명자의 공인 인증서가 만료되거나 해제된 것으로 보고되는 경우, 서명 블럭은 거부된다. 서명 블록의 거부는 대체 서명 블록의 요구 또는 복구의 시작을 초래하게 된다. 만약 적어도 하나의 서명 블록이 유효한 것으로 결정되면, TCU는 신뢰할 만한 날짜 및 시간을 포함하는 그 자신의 서명 블록을 문제의 정보 객체에 첨부하고, 소유자에 유리하게 보유되고 제어될 수 있는 전자 원본을 만든다.

전자 서명 블록을 만드는 것은 하나 이상의 정보 객체 단편 또는 전체 정보 객체를 위하여 하나 이상의 내용 해쉬를 계산하는 단계, 하나 이상의 내용 해쉬 및 로컬 날짜 및 시간, 서명 레숄레 또는 지시와 같은 어떠한 첨부된 데이타에 대하여 해쉬를 계산하는 단계; 계산된 해쉬를 서명 파티의 사적인 키를 사용하여 암호화하는 단계, 서명자의 전자 서명을 서명자의 공인 인증서와 함께 서명 블록에 배치하는 단계를 포함한다. 첨부된 데이타가 로컬 날짜 및 시간을 포함하는 경우, 전자 서명 블복을 만드는 방법은 로컬 날짜 및 시간을 디스플레이하는 단계, 서명자로 하여금 날짜와 시간이 정확한지를 확인하도록 요구하는 단계, 또는 신뢰할 만한 시간 서비스기관에 의해 설정되고 로컬 날짜나 시간이 템퍼링으로부터 보호되는 경우에는 시스템의 날짜 또는 시간에 의존하는 단계를 추가적으로 포함할 수 있다. 로컬 날짜와 시간이 정확한지 또한 사용자의 공인 인증서 유효 기간내에 존재하는지, 로컬 날짜와 시간이 유효 기간에 의해 특정된 날짜 및 시간의 전후가 아닌지를 확인하도록 체크할 수 있다.

조회되지 않은 전자 서명의 복구는 전자 서명을 재계산하고 서명 블록을 재전송할 것을 요구한다. 공인 인증서 유효 기간 위반의 복구는 사용자에게 사용자의 인증서가 유효기간이 만효되었으므로 갱신되어야 한다는 것을 통지하는 단계 및 트랜잭션 소유자에게 트랜잭션이 완결되지 못하였음을 통지하는 단계를 포함한다.

하나 이상의 서명 블록 및 거기에 포함된 정보를 배치하는 것은 적어도 하나의 서명 태그에 의하여 특정된다. 하나 이상의 수기 서명 및 날짜는 디지트화되어 정보 객체 실행에 사용되며, 상기 서명 및 날짜의 배치는 적어도 하나의 서명 태그에 의하여 특정된다. 하나 이상의 서명 블록은 상응하는 서명 태그의 지정과 함께독립되어 TCU에 보내질 수 있으며, TCU는 독립적으로 또는 그룹으로 보내어진 모든 서명 블록의 유효성을 확인할 수 있다. 만액 전자 서명 확인 또는 공인 인증서 유효화 확인 중 어느 하나라도 실패할 경우에는, TCU는 서명 블록을 거부하고 복구를 요청할 수 있으며, 만약 서명 블록 유효화 단계가 성공하는 경우에는 TCU는 서명 블록을 표시된 태그에 배치한다. 서명 블록들(signature blocks)을 구분하여 보내기 위해, TCU는 신뢰할만한 날짜 및 시간을 각 서명 블록에 추가한다. 비즈니스 룰(business rules)에 따라서, TCU는 전자적 원시 정보 객체(electronic original information object)를 생성하기 위한 중요 정보 객체(subject information object)와 삽입된 서명 블록 필드들(signature block fields)을 포함하는 래퍼(wrapper)에서의 신뢰할만한 날짜 및 시간을 포함하는 고유 서명 블록을 부가한다. 복수 사용자 서명 블록들(multiple user signatures blocks)은 하나의 래퍼 내에서 추가될 수 있으며, 래퍼들은 다른 비즈니스들 및 보안 프로세스들에 재귀적으로 적용될 수 있다.

TCU는 비즈니스 룰 데이터베이스에서 인증서에 의하여 식별되는 서명 개체(signing entity)가 요구된 동작을 수행하기 위한 권한(authority)을 가졌는지를 체크하며, 서명 개체의 디지털 서명을 확인하며, 인증 유효 기간이 현재의 신뢰할 만한 날짜 및 시간을 포함하는지를 체크하며, 전달된 로컬(local)의 날짜 및 시간이 TCU 날짜 및 시간의 허용할만한 편차 내에 포함되는지를 체크하며, CSS를 이용하여 인증 상태(certificate status)를 체크하는 방법에 의하여, 전자적 원시 정보 객체의 컨텐트에 포함되거나 추가되는 서명 블록(들)에 존재하는 디지털 서명(들)(digital signature(s)) 및 인증서(들)(authentication certificate(s))를 확인할 수 있다. 만약 이러한 단계들 중 어느 하나라도 유효하지 않거나 잘못된 결과가 나온다면, 디지털 서명은 유효하지 않은 것으로 판단되며, 요청된 동작은 허용되지 않으며 수정이 이루어지며, 그렇지 않은 경우 디지털 서명은 유효한 것으로 판단되며 요청된 동작은 허용된다.

CSS와 함께 발행 CA(issuing CA)를 등록하는 것은 조직화 비즈니스(organization business) 및 시스템 폴리시(system policy)와 같은 인더스트리(industry) 기반으로 공인된 것으로서 CSS 지식 기반(CSS knowledge base)에 포함하기 위하여 발행 CA를 조사하며 승인하는 단계를 포함할 수 있다. 만약 조사 단계가 실패하면, 발행 CA는 상기 CSS 구성 스토어에 “공인되지 않은”으로 저장되며/저장되거나 CA 등록이 종료된다. 그렇지 않으면, 상기 발행 CA는 “공인된” 것으로 추가되며, 상기 통신 파라미터들(IP 주소, SSL 키 및 인증) 및 인증 상태를 보고하기 위하여 사용된 방법(OCSP, CRL, LDAP)은 상기 CSS 구성 스토어에 추가되며, 인증 상태를 해석하기 위한 커넥터는 미리 구현되지 않은 경우에 추가된다. 이러한 방법으로, 상기 CSS는 시스템 또는 TCU와 인증 상태 반응자들(responders)의 다양한 조합 사이의 상호 작동성을 가능하게 한다.

인증 상태 체킹은 통신을 개설하기 위하거나, 승인된 인증 발행 CA들로부터 인증 상태를 검색하거나 추출하기 위하여 편리하게 CSS를 사용할 수 있다. CSS가 시스템 또는 TCU로부터 인증서 상태의 질의를 수신하면, 상기 CSS는 먼저, 상기 인증 상태가 존재하는지, 만약 발견된다면 만료 시간 내에 존재하는 지를 알아보기 위하여 로컬의 캐시를 체크하며, 상태를 리턴한다. 만약 인증 상태가 존재하지 않거나 만료 시간 인터발(interval) 외부에 있으면, 상기 CSS는 구성 스토어로부터의 첫 번째 요구되는 연결 정보(requesting connection information)에 의하여 상태를 검색한다. 상기 CSS는 그 후, 구성 스토어에서 식별되는 인증 상태 보고 요소(certificate status reporting component)와의 통신 세션을 개설한다. 상기 CSS는 CSS 구성 스토어에 포함되어 있는 각 방법에 따라 인증 상태 리퀘스트(certificate status request)를 구성하며, 상기 인증 상태 보고 요소로부터 인증 상태를 수신하며, 상기 요소와의 통신 세션을 종료한다. 상기 CSS는 적어도 상기 인증의 ID, 인증 상태 및 만료 시간을 캐시에 추가하며 상기 리퀘스팅 시스템(requesting system) 또는 TCU로 인증 상태를 리턴한다.

상기 인증 상태 보고(certificate status reporting)는 CRL과 CRL의 수행에 기반한다. 상기 발행 CA의 공개 스케줄에 따르면, 상기 CSS는 상기 CSS 구성 스토어에 리스트된 인증 상태 보고 요소로부터 상기 CRL을 검색한다. 상기 CSS는 상기 발행 CA에 상응하여 캐시 메모리를 삭제하며, 상기 CRL로부터 인증 상태를 분석하며 상기 발행 CA에 상응하여 캐시에 상기 인증 상태를 배치한다. 상기 발행 CA에 의한 CRL이 유효하다는 통보에 따라서, 상기 CSS는 상기 CSS 구성 스토어에 리스트 된 인증 상태 보고 요소로부터 상기 CRL을 검색할 수 있다. 표준으로 요구되는 부분에서, 상기 CRL이 완료 CRL이면 상기 CSS는 상기 발행 CA에 상응하여 상기 캐시를 삭제하며, 상기 CRL을 분석하며, 상기 발행 CA에 상응하여 상기 캐시에 상기 인증 상태 및 관련되는 정보를 배치한다. 상기 CRL이 전체 CRL(full CRL)의 공개 이후에 발생한 변화들(changes)만을 포함하면, 상기 CSS는 상기 CRL로부터 인증 상태를 분석하며 상기 발행 CA에 상응하여 상기 캐시에 상기 인증 상태 및 관련되는 정보를 배치한다.

사용자에게 허용되는 인증 상태를 획득하기 위하여 CSS를 사용함으로써, 인증 상태를 획득하기 위한 단일 수단을 사용하는 시스템 또는 TCU는 상기 CSS에 대하여 정보 객체에 대한 서명 블록 내에 존재하는 인증서에 대한 상태를 질의하는 단계-여기서, 상기 상태 질의(status query)는 단일 수단(예를 들어, OCSP)을 사용할 수 있음-, 상기 발행 CA에 의하여 요구된 형태로 상기 상태 질의를 변역하는 단계, 및 인증 상태를 검색 및/또는 보고하는 단계를 포함할 수 있다. 인증 상태가 해제되면, 상기 서명 블록은 사용되지 않으며, 복구(remedy)가 요구된다. 상기 디지털 서명이 확인되고 인증 상태가 유효하면, 상기 서명 블록은 상기 전자적 원시 정보 객체에 추가된다.

상기 TCU는 상기 상태가 상기 CSS 캐시/데이터 저장부(data store)에 현존하면 상기 인증 상태를 위치시켜 보고하며, 상기 CSS 구성 스토어로부터 인증 상태를 검색하기 위한 타입 및 수단을 획득함으로써 서명자의 인증서 상태를 검증하도록 상기 CSS에게 질의할 수 있다. 만약 특별한 인증 상태 방법이 CRL이며 상기 특정 인증의 상태가 CSS 내의 캐시에 저장된 발행 CA에서 발견되지 않으면, CSS는 인증 상태를 유효한 것으로 보고한다. 만약 인증 상태 방법이 CRL이 아니면, CSS는 CSS 구성 스토어에 포함된 각 방법으로서 인증 상태 리퀘스트를 구성하며, 발행 CA와의 적절한 통신을 개설한다. CSS는 식별된 인증 상태 체킹 방법을 사용하여 상태 보고 요소로부터 인증 상태를 검색하며 통신 세션을 종료한다. CSS는 검색된 인증 상태를 분석 또는 해석하며, 만료 시간 값(time-to-live value)을 CSS 폴리시에서 기술된 상태 타입에 의하여 특정된 기간으로 설정하며, 적어도 인증의 ID, 상태 및 만료 시간 값을 발행 CA의 인증 상태 캐시에 추가한다. 그 후, CSS는 리퀘스팅 시스템으로 인증 상태를 리턴한다.

승인된 발행 CA에 의하여 인증이 발행되는 시스템 또는 TCU에서 사용자를 등록하는 방법은 CSS에 알려져 있으며, 사용자가 개설된 멤버십 단계 및 규정을 이용하는지를 검사하며, 승인된 조직 스폰서(organization sponsor)에 의하여 이미 서명된 사용자 등록 정보(user enrollment information)를 기입하며, 상기 식별된 발행 CA로 인증 리퀘스트를 생성하여 전송하는 단계를 포함한다. 사용자의 인증서가 검색되고, 발행되며, 배달을 위한 토컨(token)에 배치된다. 디지털 서명, 디지털 서명 확인 및 CSS 인증 상태 체크는 공개키 쌍의 제공 및 인증 발행 단계가 정확하게 완료되었음을 보증하기 위하여 수행된다. 사용자는 자신의 디지털 서명을 수기 서명(hand written signatures)과 동일한 가치를 부여하도록 위임하는 동의서에 서명하도록 요구되며, 상기 사용자에게 토컨(token)이 배달되며, 사용자의 시스템 또는 TCU 계정은 활성화된다.

CA에 의하여 이미 사용자가 인증되는 시스템 또는 TCU에서 사용자를 등록하는 방법은 미리 CSS에 알려져 있지 않으며, 사용자의 인증서에 대하여 사용자의 토컨을 질의하며 발행자 정보를 획득하며, 발행 CA가 포함되어 있는지를 확인하기 위하여 CSS 지식 기반(CSS knowledge base)에 질의하는 단계를 포함한다. 만약 그렇지 않다면, 인더스트리(industry)나 조직화 폴리시(organization policy)는 발행 CA가 CA 포함에 대한 시스템 룰(system rules)을 만족하는지 여부를 판단하기 위하여 접촉된다. 발행 CA가 “공인되지 않은” 것으로 판단되면, 등록은 종료하고 발행 CA가 “공인된” 것으로 판단되면 등록 단계는 상술한 바와 같이 진행된다.

사용자의 인증서 컨텐츠의 일 부분은 사용자가 시스템 또는 TCU로의 접근이 승인된 후, 사용자 등록 정보를 기입하며, 인증서를 유지하는 사용자 토컨을 로컬의 토컨 리더(token reader)에 삽입하며, 컨텐츠가 정확하다는 사용자 확인을 포함하는 인증 컨텐츠(certificate contents)를 검색하고 디스플레이하며, 인증 ID, 발행 CA, 사용자의 구별 이름 또는 인증 확장들(certificate extensions, 예를 들어 subjectAltName)에 포함되어 전달되는 다른 식별 정보와 같은 인증(certificate)으로부터 추출되는 시스템 또는 TCU 사용자 등록 데이터에 선택된 필드들(fields)을 추가함으로써 사용자 계정(user's account)에 상기 인증을 결합하기 위하여 사용될 수 있다. 상기 추출된 데이터는 추출 및 데이터 엔트리가 자동화되도록 상기 시스템 또는 TCU 폴리시로 특정될 수 있다.

정보 객체의 제출자가 제출된 정보 객체의 진정성(authenticity)을 보증하는 방법은 정보 객체 및/또는 래퍼(wrapper)에 제출자의 서명 블록을 첨부하며, 그것 을 시스템 또는 TCU로 포워딩하는 단계를 포함한다. 서명 블록에 대한 검증이 실패하면, TCU는 재전송이나 복구를 요구하며, 서명 블록에 대한 검증이 성공하면, TCU는 통신 세션의 시작자(initiator)와 상기 제출자가 동일한지를 체크하며, 동일하지 않으면 상기 제출을 거부한다. 모든 체크가 성공하면, TCU는 전자적 원시 정보 객체(electronic original information object)를 생성하면서 상기 제출(submission)에 서명 블록을 추가한다.

CSS에서 만료 시간 데이터 요소(time-to-live data element)를 사용하는 실시간 인증 상태 보고 수단(real-time certificate status reporting means)에 대하여 정확하며 적시의 인증 상태를 유지하기 위한 방법은 다음과 같은 단계를 포함한다. 만약 CRL 상태 방법이 사용되면, CSS가 상태를 보고한다. 만약 인증 상태가 캐시에 존재하며 만료 시간 데이터 요소가 초과되지 않으면, CSS는 상태를 보고한다. 만약 만료 시간 데이터 요소가 초과하면, CSS는 발행 CA 캐시로부터 인증 상태 엔트리를 삭제한다. 만약 실시간 인증 상태 보고 수단(예를 들어, OCSP, LDAP 쿼리, 등)을 사용하여 상태가 검색되며 상태가 캐시 내에 존재하지 않으면, 인증 상태는 요구되며, 검색되며 보고된다. 그 후, CSS는 적어도 인증 ID, 인증 상태 및 만료 시간을 캐시에 추가하며 리퀘스팅 시스템 또는 TCU에 인증 상태를 리턴한다.

인증 상태 사용-카운터 데이터 요소(certificate status use-counter data element)는 CSS의 발행 CA 캐시에 포함되는 인증의 상태 엔트리에 추가될 수 있으며, 상기 상태 사용-카운터 데이터 요소(status use-counter data element)는 상기 인증서의 상태가 체크될 때마다 증가되거나 감소될 수 있다. 만약 상기 상태 사용- 카운터가 CSS 폴리시에 의해 정해진 쓰레쉬홀드(threshold)를 통과하면, 상기 인증 상태는 보고될 수 있지만, CSS는 그 후, 발행 CA 캐시로부터 인증 상태 엔트리를 삭제한다. 만약 CSS 리턴된 인증 상태가 유효하지 않거나 해제되면, 시스템 또는 TCU는 해당 에러를 로그로 만들며 제공자 및/또는 트랜잭션 소유자에게 보고하며, 요구된 동작은 허용되지 않으며 복구가 필요하다. 그렇지 않으면, 디지털 서명은 유효한 것으로 판단되며 요구된 동작은 허용된다. 인증 상태 최종-접속 데이터 요소(status last-accessed data element)가 추가될 수 있으며, 상기 상태 최종-접속 데이터 요소는 상기 사용-카운터와 결합하여 상기 인증서의 상태에 대한 활동 레벨(activity level)에 대하여 판단하기 위하여 사용될 수 있다.

배경 프로세스(background process)는 CSS가 자동적으로 업데이트된 인증 상태를 검색하도록 하며, CSS 폴리시에서 크라이테리언(criterion)이 만족할 때 새로운 만료 시간 및 사용-카운터 데이터 요소를 수립하도록 할 수 있다. 이러한 프리 페치(pre-fetch)는 인증 상태를 요구하는 시스템 또는 TCU 및 응답하는 CSS 사이의 평균 시간을 단축할 수 있다.

만약 CSS가 새로운 인증에 대하여 인증 상태를 검색하도록 요구되어지며 발행 CA 캐시가 허용된 버퍼 사이즈 한도에 도달할 경우, 상기 인증 상태 최종-접속 데이터 요소는 CSS의 발행 CA 캐시 내의 인증의 상태 엔트리에 추가될 수 있다. 상기 CSS는 가장 오래된 데이터(가장 낮은 빈도로 사용되는)에 대한 최종-접속 데이터 요소(last-accessed data element)를 상기 발행 CA 캐시에서 검색하며, 각 캐시 메모리 엔트리를 삭제한다. 그 후, 상기 CSS는 상기 요구된 인증 상태를 검색하며, 발행 CA 캐시 내의 여유 공간에 위치시키며 폴리시에 따라서 동작하는 시스템 또는 TCU에 상기 상태를 보고한다.

분산된 CSS에서 상태를 체크하는 방법은 새로운 발행 CA가 소개될 때마다 CSS들을 정리(coordinating)하며, 다른 CSS가 발행 CA 질의에 대한 원칙적인 책임을 가질 때 모든 CSS 지식 기반들(CSS knowledge bases)의 엔트리들을 수립하며, CSS와 발행 CA 사이의 통신 단계를 줄이기 위해 발행 CA 대신에 다른 CSS들에게 질의하며, 발행 CA에 대하여 복수의 로컬 시스템에 인증 상태 리퀘스트가 집중될 때 인증 상태들을 로컬하게 동기화 및 저장(caching)하며, 원래의 기초적인 CSS 보다 주어진 발행 CA에서, 다른 CSS에 과도한 로드가 걸리면 질의 응답성(querying responsibility)을 공유하거나 전송하는 단계를 포함한다.

CSS 지식 기반에서 “승인되지 않은(not approved)" 것에 참조하여 발행 CA를 변경함으로써 발행 CA에 상응하는 사용자 집합을 배제하는 것은 발행 CA가 포기되도록 승인을 요청하며, 공과에 따라 상기 리퀘스트를 재검토하며 필요한 행위가 요구되는지 판단함으로써 수행될 수 있다. 또한 사용자 집합을 배제하는 것은 발행 CA가 유효하지 않은 것으로 판단되면, 발행 CA의 상태를 CSS 지식 기반의 “승인되지 않은(not approved)" 것으로 변경함으로써 수행될 수 있다. 그 이후의 “승인되지 않은(not approved)" 것으로 리스트된 CA에 의해 발행된 인증의 상태에 대한 어떠한 리퀘스트에 대해서도 CSS가 리턴하는 결과는 실패의 상태(failed status)이다.

발행 CA 레퍼런스가 “승인되지 않은(not approved)" 것으로 이전의 셋팅에 의하여 유효하지 않은 사용자 집단을 재유효(re-enabling)하게 하는 방법은 발행 CA를 재유효하게 하기 위하여 승인이 되도록 요구하며, 공과에 따라 상기 리퀘스트를 재검토하며 필요한 행위가 요구되는지 판단함으로써 수행될 수 있다. 또한 사용자 집단을 재유효(re-enabling)하게 하는 방법은 발행 CA가 재유효하도록 판단되면, 발행 CA의 상태를 CSS 지식 기반의 “승인된(approved)" 것으로 변경함으로써 수행될 수 있다. CSS는 발행 CA가 승인 CA로 복귀하도록 인증 상태 리퀘스트를 수행한다.

상태 보고 요소와의 통신은 정보를 위치시키고 요청하며 검색하기 위하여 사용되는 각 인증 상태 프로토콜을 위하여 모듈로 구성되며 재사용 가능한 장치를 생성하며, 특별한 인증 상태 프로토콜을 인식하는 모든 CA 및 응답자들에서 공통으로 사용되는 장치의 버전(version)을 이용하며, 사용되는 각 상태 보고 프로토콜(status reporting protocol)을 위한 장치의 버전을 가짐으로써 수립될 수 있다.

상기 장치는 장래 인증 상태 보고 프로토콜들을 지원하도록 용이하게 변경 가능하도록 설계될 수 있다.

상기 제출자(submitter)가 제1 TCU이며 상기 제출(submission)은 제2 TCU로 하나 또는 그 이상의 전자적 원시들(electronic originals)에 대한 이동 관리(transferring custody)인 상태에서 트랜잭션을 수행하는 단계는 제2 TCU에 대한 하나 또는 그 이상의 전자적 원시 도큐먼트(electronic original documents)에 대하여 이동 관리하기 위하여 제1 TCU에 지시하는 트랜잭션의 소유자를 가지는 단계를 포함할 수 있다. 상기 트랜잭션의 소유자는 제2 TCU에게 하나 또는 그 이상의 전자적 원시 도큐먼트에 대한 이동 관리를 지시하며, 제1 TCU에게 상기 제2 TCU로 전송될 전자적 원시들을 식별하기 위한 명부(manifest)를 제공한다. 제1 TCU는 제2 TCU와 통신을 개설하며, 제2 TCU에 대한 동작의 목적을 식별한다. 제1 TCU 또는 소유자는 관리에 대한 트랜스퍼가 완료되었는지를 판단할 수 있도록 제2 TCU로 상기 명부를 전송할 수 있다. 제1 TCU는 각각의 식별된 전자적 원시를 제2 TCU로 전송하는데, 제2 TCU는 각각의 전송된 전자적 원시에 대한 제1 TCU의 디지털 서명이 유효하며 전자적 원시들이 변경되지 않았음을 보장하기 위하여 CSS를 사용한다. 제1 TCU의 디지털 서명이 유효하지 않으면, 제2 TCU는 제1 TCU에게 통보하며 복구 방안(remedy, 예를 들어 제1 TCU에게 현재의 인증서를 이용하여 재서명하도록 요청하는 것)을 찾는다. 만약 제1 TCU가 응할 수 없는 경우에, 제2 TCU는 상기 이벤트를 로그로 만들며 트랜잭션 소유자에게 요청된 관리의 트랜스퍼가 실패했음을 통보하며, 그렇지 않은 경우에, 제2 TCU는 각 성공적으로 전송된 정보 객체에 대하여 날짜-시간 스탬프 및 서명 블록을 추가하면서 새로운 래퍼를 생성한다. 제2 TCU는 각각의 성공적인 트랜스퍼에 대하여 제1 TCU에 통보하며, 완료에 따라서 제1 TCU는 소유자의 재량에 따라서 원시 정보가 되도록 구성될 수 없도록 하는 방법과 같이 마크를 하거나 복사본을 보존할 수 있거나, 전송된 정보 객체에 대해 존재하는 모든 복사본을 파괴할 수 있다. 상기 프로세스는 모든 식별된 전자적 원시들이 전송될 때까지 되풀이 된다. 이러한 방식으로, 제2 TCU는 공인된 복사본에 대한 전송된 기록들을 위한 보관자(custodian)가 된다. 제2 TCU는 신뢰할만한 날짜 및 시간, 디지털화된 서명을 추가하거나 관리 트레일(trail-of-custody)의 독립적 요소를 생성하기 위한 명부를 포함하며 저장할 수 있다.

트랜잭션을 수행함에 있어서, 소유자의 명령은 소유권의 트랜스퍼가 발생한다는 것을 말할 수 있으며, 소유권 도큐먼테이션(ownership documentation)의 트랜스퍼는 제1 TCU 또는 제2 TCU에 배치될 수 있다. 책임있는 TCU는 모든 디지털 서명들, 인증 유효 기간을 확인하며 CSS를 이용하여 인증 상태를 체크함으로써 소유권 도큐먼트의 트랜스퍼에 대한 진정성(authenticity)을 검증한다. 그 후, 상기 TCU는 신뢰할만한 날짜 및 시간 및 디지털화된 사인을 추가하며, 명부에 추가되는 이러한 전자적 원시 정보 객체들을 포함하며 저장한다. 이러한 전자적 원시들이 제1 TCU에 위치할 경우, 소유권에 대한 트랜스퍼가 관리 트랜스퍼 이전에 수행되며, 명부에 대한 초기화가 소유주에 대한 트레일의 부분이 된다.

전송되는 자료의 몇몇은 단순한 전자적 정보 객체이며 전자적 원시 자체는 아니다. 상기 CSS는 시스템 또는 TCU와 통신하기 위하여 적당한 인증 상태 프로토콜을 사용할 수 있다.

본 발명은 발명의 근원적인 특징을 벗어나지 않는 범위 내에서 다양한 변형이 이루어 질 수 있으며, 따라서 상술한 실시예들은 모든 사항에 대하여 예시적이며, 제한하지 않는 것으로 고려되어야 한다. 본 명세서에서 강조되어 사용된 용어인 “포함” 또는 “포함하다”는 하나 또는 그 이상의 다른 특징들의 존재를 방해하지 않고 언급된 특징들의 존재를 특징짓는 것을 의미한다. 본 발명은 상술한 실시예에 한정되지 않고, 전 범위의 균등물을 고려하여 첨부된 특허청구범위에 의하여 한정되어야 할 것이다.

Claims

각 발행 인증 기관들(Certification Authorities, CAs)에 의하여 발행된 인증서(authentication certificates)의 유효성을 체크하기 위한 인증 상태 서비스(Certificates Status Service, CSS)를 제공하는 방법에 있어서,

상기 인증서를 발행하는 발행 CA로부터의 인증서의 상태 정보를 검색하기 위하여 필요한 정보를 식별하는 단계;

상기 발행 CA와의 통신을 위하여 상기 식별된 정보를 바탕으로 커넥터(connector) - 상기 커넥터는 상기 CSS가 상기 인증서의 상태 정보를 전달할 수 있도록 프로그램들이 활용할 수 있는 수단임 - 를 구성하는 단계;

상기 인증서의 상태가 질의되는 경우에, 상기 구성된 커넥터에 따라서 상기 발행 CA와 통신하는 단계; 및

상기 인증서의 상태 정보를 검색하는 단계

를 포함하되, 상기 발행 CA 및 상기 커넥터는 구성 저장장치(configuration store)에서 승인된 CA들의 리스트에 표시되는 것을 특징으로 하는 각 발행 인증 기관들(Certification Authorities, CAs)에 의하여 발행된 인증서(authentication certificates)의 유효성을 체크하기 위한 인증 상태 서비스(Certificates Status Service, CSS) 제공 방법.
제1항에 있어서,

로컬(local)의 날짜 및 시간이 상기 인증서에 표시된 유효 기간 내에 포함되는 지의 여부가 체크되고, 만일 상기 로컬 날짜 및 시간이 유효 기간내에 포함되지 않을 경우 유효하지 않은 상태(invalid status)를 보고하는 것을 특징으로 하는 각 발행 인증 기관들(Certification Authorities, CAs)에 의하여 발행된 인증서(authentication certificates)의 유효성을 체크하기 위한 인증 상태 서비스(Certificates Status Service, CSS) 제공 방법.
제1항에 있어서,

미리 정해진 비즈니스 규칙(business rules)에 따라 상기 발행 CA를 검사 및 승인함으로써, 상기 발행 CA는 승인된 CA들의 리스트에 포함되며, 만일 상기 발행 CA가 검사되어 승인되지 않거나 나중에 승인되지 않으면(later disapproved), 상기 발행 CA는 상기 구성 저장장치에서 비승인된 CA들의 리스트상에 표시되고/거나 나중에 비승인된 발행 CA와 상기 커넥터는 상기 구성 저장장치에서 승인된 CA들의 리스트상에서 삭제되는 것을 특징으로 하는 각 발행 인증 기관들(Certification Authorities, CAs)에 의하여 발행된 인증서(authentication certificates)의 유효성을 체크하기 위한 인증 상태 서비스(Certificates Status Service, CSS) 제공 방법.
제3항에 있어서,

상기 발행 CA를 검사 및 승인하는 것은 상기 CSS와 함께 상기 발행 CA의 신뢰되는 인증서(trusted authentication certificate)에 기재된 내용을 등록하는 것과 적어도 상기 내용, 상기 발행 CA의 신뢰되는 인증서의 상태 정보 및 생존 시간 데이터 요소(time-to-live data element)를 로컬 캐시 메모리에 추가하는 것을 포함하며, 상기 커넥터는 상기 신뢰되는 인증서의 상태가 질의되었을 경우에 상기 추가된 상태 정보를 검색하기 위하여 구성되는 것을 특징으로 하는 각 발행 인증 기관들(Certification Authorities, CAs)에 의하여 발행된 인증서(authentication certificates)의 유효성을 체크하기 위한 인증 상태 서비스(Certificates Status Service, CSS) 제공 방법.
제2항에 있어서,

상기 인증서의 상태 정보에 대한 로컬 캐시 메모리를 체크하고, 만일 상기 인증서의 상태 정보가 상기 로컬 캐시 메모리에서 발견되고 상기 로컬의 날짜 및 시간이 유효 기간에 포함되는 경우, 로컬 캐시 메모리로부터 상기 인증서의 상태 정보를 검색하거나, 만일 생존시간 또는 사용-카운터 데이터 요소가 초과되는 경우, 상기 캐시 메모리 엔트리의 소거를 요구함으로써 상기 인증서의 상태를 보고하는 단계를 추가로 포함하되, 만일 상기 인증서의 상태 정보가 상기 로컬 캐시 메모리에서 발견되지 않거나 상기 로컬의 날짜 및 시간이 상기 유효 기간에 포함되지 않는 경우에, 상기 발행 CA의 인증 상태 보고 요소(certificate status reporting component)와 통신 세션을 형성하며, 상기 구성된 커넥터에 따라서 인증 상태 리퀘스트(certificate status request)를 구성하며, 상기 인증 상태 보고 요소로부터 상기 인증서의 상태 정보를 검색하며, 상기 인증 상태 보고 요소와의 통신 세션을 종료하며, 적어도 상기 인증서의 식별(identification), 인증서의 상태 정보, 사용-카운터 및 생존 시간(time-to-live)을 상기 로컬의 캐시 메모리에 추가하는 것을 특징으로 하는 각 발행 인증 기관들(Certification Authorities, CAs)에 의하여 발행된 인증서(authentication certificates)의 유효성을 체크하기 위한 인증 상태 서비스(Certificates Status Service, CSS) 제공 방법.
제1항에 있어서,

상기 인증서의 상태 정보는 상기 발행 CA의 공개 스케줄(publication schedule)에 따라서 인증 해제 리스트(Certificate Revocation List, CRL)에 의하여 표시되며, 상기 구성 스토어에 리스트된 인증 상태 보고 요소로부터 상기 CRL을 검색하며, 상기 발행 CA에 상응하여 캐시 메모리를 지우며(clear), 상기 CRL로부터 상기 인증서의 상태를 결정하며 상기 발행 CA에 상응하여 캐시 메모리에 상기 인증서의 상태 정보를 저장하는 것을 특징으로 하는 각 발행 인증 기관들(Certification Authorities, CAs)에 의하여 발행된 인증서(authentication certificates)의 유효성을 체크하기 위한 인증 상태 서비스(Certificates Status Service, CSS) 제공 방법.
제1항에 있어서,

상기 인증서의 상태 정보는 인증 해제 리스트(Certificate Revocation List, CRL)가 유효하며, 상기 구성 저장장치에 리스트된 인증 상태 보고 요소로부터 상기 CRL을 검색한다는 상기 발행 CA에 의한 통보(notification)에 따라서 델타(Delta) 인증 해제 리스트(CRL)에 의하여 표시되는데, 상기 CRL이 완전한 CRL(complete CRL)이면, 상기 발행 CA에 상응하여 캐시 메모리를 지우며 상기 CRL로부터의 상기 인증서의 상태를 판단하며 상기 캐시 메모리에 상기 인증서의 상태 정보를 저장하며, 상기 CRL이 전체 CRL(full CRL)의 공개 이후에 발생한 변화들(changes)만을 포함하면, 상기 CRL로부터 상기 인증서의 상태를 판단하며 상기 캐시 메모리에 상기 인증서의 상태 정보를 저장하는 것을 특징으로 하는 각 발행 인증 기관들(Certification Authorities, CAs)에 의하여 발행된 인증서(authentication certificates)의 유효성을 체크하기 위한 인증 상태 서비스(Certificates Status Service, CSS) 제공 방법.
제1항에 있어서,

상기 통신 단계는 커넥터들의 순서에 따라 다중 CA 및 PKI와의 통신을 포함하는 것을 특징으로 하는 각 발행 인증 기관들(Certification Authorities, CAs)에 의하여 발행된 인증서(authentication certificates)의 유효성을 체크하기 위한 인증 상태 서비스(Certificates Status Service, CSS) 제공 방법.
제1항에 있어서,

커넥터는 단일의 통신 단계에서 하나 이상의 인증 상태 체크(certificate status check)를 포함하는(embed) 것을 특징으로 하는 각 발행 인증 기관들(Certification Authorities, CAs)에 의하여 발행된 인증서(authentication certificates)의 유효성을 체크하기 위한 인증 상태 서비스(Certificates Status Service, CSS) 제공 방법.
제1항에 있어서,

상기 인증서는 상기 인증서의 소유자를 확인할 수 있는 식별 정보(identification information)로 사용되지 않는 것을 특징으로 하는 각 발행 인증 기관들(Certification Authorities, CAs)에 의하여 발행된 인증서(authentication certificates)의 유효성을 체크하기 위한 인증 상태 서비스(Certificates Status Service, CSS) 제공 방법.
인증서의 상태를 검증하기 위하여 신뢰되는 보호 유틸리티(Trusted Custodial Utility, TCU)로부터 인증 상태 서비스(Certificate Status Service, CSS)로의 질의에 따른 응답으로서 발행 인증 기관(Certification Authority, CA)에 의하여 발행된 인증서(authentication certificates)의 상태를 검색하는 방법에 있어서,

상기 인증서의 상태 정보가 상기 CSS의 캐시 메모리에 현존하면 상기 인증서의 상태 정보를 위치시키며 보고하는 단계;

상기 인증서의 상태 정보가 상기 캐시 메모리에 현존하지 않으면, CSS 구성 스토어(configuration store)로부터 상태 타입(status type) 및 검색 방법을 획득하는 단계;

만일 상기 상태 타입이 인증 해제 리스트(Certificate Revocation List, CRL)이고 상기 CRL의 다음 버전이 아직 게재되지 않았으며 상기 인증서의 상태 정보가 상기 캐시 메모리에서 발견되지 않은 경우, 상기 인증서의 상태를 유효한 것으로 보고하는 단계;

상기 상태 타입이 CRL이 아니면, 상기 상태 타입에 따라서 인증 상태 리퀘스트(certificate status request)를 구성하는 단계;

상기 발행 CA와의 통신 세션을 설정하는 단계;

상기 획득된 검색 방법을 사용하여 상기 발행 CA의 상태 보고 요소(status

reporting component)로부터 상기 인증서의 상태 정보를 검색하며 상기 통신 세션을 종료하는 단

계;

상기 검색된 인증서의 상태 정보를 해석하는 단계;

상기 상태 타입에 대한 CSS 폴리시(policy)에 의하여 특정되는 시간을 나타내는 만료 시간값(time-to-live value)을 상기 해석되고 검색된 인증서의 상태 정보에 연계시키는 단계;

적어도 상기 인증서의 식별(identification), 인증서의 상태 정보 및 만료 시간값을 상기 캐시 메모리에 추가하는 단계; 및

상기 질의에 응답하여 상기 TCU에 상기 인증서의 상태를 보고하는 단계

를 포함하는 인증서의 상태를 검증하기 위하여 신뢰되는 보호 유틸리티(Trusted Custodial Utility, TCU)로부터 인증 상태 서비스(Certificate Status Service, CSS)로의 질의에 따른 응답으로서 발행 인증 기관(Certification Authority, CA)에 의하여 발행된 인증서(authentication certificates)의 상태를 검색하는 방법.
제11항에 있어서,

상기 CSS는 상기 통신 세션에서 인증 상태 보고 프로토콜(certificate status protocol) - 상기 인증 상태 보고 프로토콜은 실시간으로 상기 인증서의 상태 정보를 보고하는 규약임 - 을 사용하는 것을 특징으로 하는 인증서의 상태를 검증하기 위하여 신뢰되는 보호 유틸리티(Trusted Custodial Utility, TCU)로부터 인증 상태 서비스(Certificate Status Service, CSS)로의 질의에 따른 응답으로서 발행 인증 기관(Certification Authority, CA)에 의하여 발행된 인증서(authentication certificates)의 상태를 검색하는 방법.
제11항에 있어서,

상기 획득된 검색 방법을 사용하여 하나 이상의 인증서의 상태 정보가 검색되는 것을 특징으로 하는 인증서의 상태를 검증하기 위하여 신뢰되는 보호 유틸리티(Trusted Custodial Utility, TCU)로부터 인증 상태 서비스(Certificate Status Service, CSS)로의 질의에 따른 응답으로서 발행 인증 기관(Certification Authority, CA)에 의하여 발행된 인증서(authentication certificates)의 상태를 검색하는 방법.
제11항에 있어서,

상기 인증서는 상기 인증서의 소유자를 확인할 수 있는 식별(identification)을 위하여 단독으로 사용되지 않는 것을 특징으로 하는 인증서의 상태를 검증하기 위하여 신뢰되는 보호 유틸리티(Trusted Custodial Utility, TCU)로부터 인증 상태 서비스(Certificate Status Service, CSS)로의 질의에 따른 응답으로서 발행 인증 기관(Certification Authority, CA)에 의하여 발행된 인증서(authentication certificates)의 상태를 검색하는 방법.
제1항에 있어서,

인증 상태 타입(certificate status type)이 인증 해제 리스트(Certificate Revocation List, CRL)이고, 상기 CRL의 다음 버전이 아직 게재되지 않았으며, 상기 인증서의 타입이 캐시 메모리에서 발견되지 않은 경우, 유효 인증 상태를 보고하는 단계;

상기 인증서의 상태 정보가 상기 캐시 메모리에서 발견되고, 만료 시간 데이터 요소가 도과되지 않은 경우, 상기 인증서의 상태 정보를 보고하는 단계;

상기 인증서의 상태 정보가 상기 캐시 메모리에서 발견되지 않거나 상기 만료 시간 데이터 요소가 도과되며 상기 인증 상태 타입이 상기 CRL이 아닌 경우, 상기 인증서의 상태 정보가 상기 캐시 메모리에 존재하지 않으면, 실시간 인증 상태 보고 프로토콜(real-time certificate status reporting protocol) - 상기 실시간 인증 상태 보고 프로토콜은 실시간으로 상기 인증서의 상태 정보를 보고하는 규약임 - 을 사용하여 상기 인증서의 상태 정보를 요청하고 검색하는 단계;

적어도 상기 인증서의 식별, 상기 인증서의 상태 정보 및 만료 시간 데이터 요소를 상기 캐시 메모리에 추가하는 단계; 및

상기 검색된 인증서의 상태 정보를 보고하는 단계

를 더 포함하는 것을 특징으로 하는 각 발행 인증 기관들(Certification Authorities, CAs)에 의하여 발행된 인증서(authentication certificates)의 유효성을 체크하기 위한 인증 상태 서비스(Certificates Status Service, CSS) 제공 방법.
제15항에 있어서,

상태 사용-카운터 데이터 요소(status use-counter data element)가 상기 캐시 메모리에 추가되는데, 상기 상태 사용-카운터 데이터 요소는 상기 인증서의 상태가 체크될 때마다 증가되거나 감소되며, 상기 상태 사용-카운터 정보 요소가 쓰레쉬홀드(threshold)를 통과하면, 상기 인증서의 상태 정보는 제공되며 상기 캐시 메모리는 상기 인증서의 상태에 따라 지워지는 것을 특징으로 하는 각 발행 인증 기관들(Certification Authorities, CAs)에 의하여 발행된 인증서(authentication certificates)의 유효성을 체크하기 위한 인증 상태 서비스(Certificates Status Service, CSS) 제공 방법.
제16항에 있어서,

상태 최종-접속 데이터 요소(status last-accessed data element)가 상기 캐시 메모리에 추가되며, 상기 상태 최종-접속 데이터 요소는 상기 상태 사용-카운터 데이터 요소와 결합하여 상기 인증서의 상태에 대한 활동 레벨(activity level)에 대한 판단을 가능하게 하는 것을 특징으로 하는 각 발행 인증 기관들(Certification Authorities, CAs)에 의하여 발행된 인증서(authentication certificates)의 유효성을 체크하기 위한 인증 상태 서비스(Certificates Status Service, CSS) 제공 방법.
제17항에 있어서,

상기 CSS로부터 상기 인증서의 상태 정보를 검색하기 위한 요구가 있으며 상기 캐시 메모리가 허용된 버퍼 사이즈 한도에 도달하면, 상기 CSS는 만료 시간값이 도과되는 인증 상태 엔트리들, 사용-카운터 데이터 요소값(user-counter data element value)이 완전히 도과되는 인증 상태 엔트리들, 및 가장 오래된 최종-접속 데이터 요소(last-accessed data element)가 있는 인증 상태 엔트리를 상기 캐시 메모리에서 검색하고 삭제하며, 상기 CSS는 그 후, 상기 CSS는 상기 인증서의 상태 정보를 검색하고 상기 캐시 메모리에 위치시키며 보고하는 것을 특징으로 하는 각 발행 인증 기관들(Certification Authorities, CAs)에 의하여 발행된 인증서(authentication certificates)의 유효성을 체크하기 위한 인증 상태 서비스(Certificates Status Service, CSS) 제공 방법.
검증할 수 있는 에비던스 트레일(evidence trail) - 상기 에비던스 트레일은 각 단계들의 실행시 기록된 정보임 - 을 가지는 공인된 정보 객체(authenticated information object)의 전송 제어에 의하여 제1 파티(party)와 제2 파티 사이의 트랜잭션(transaction)을 수행하는 방법에 있어서,

신뢰할만한 저장부로부터 공인된 정보 객체를 검색하는 단계-여기서, 상기 공인된 정보 객체는 서브미팅 파티(submitting party) - 상기 서브미팅 파티는 상기 공인된 정보 객체를 전송할 수 있도록 구성된 수단임 - 의 디지털 서명 및 적어도 상기 서브미팅 파티, 날짜 및 시간 지시자(indicator)에 대한 아이덴터티(identity) 및 암호화 키에 관련된 제1 인증서를 포함하는 제1 디지털 서명 블록(a first digital signature block), 상기 신뢰할만한 저장부에 대한 제2 디지털 서명 및 적어도 상기 신뢰할만한 저장부에 대한 아이덴터티 및 암호화 키에 관련된 제2 인증서를 포함하는 제2 디지털 서명 블록을 포함하며, 상기 제1 디지털 서명 블록은 상기 신뢰할만한 저장부에 의하여 검증되었으며, 상기 공인된 정보 객체는 상기 신뢰할만한 저장부의 제어에 따라서 전자적 원시 정보 객체(electronic original information object)로서 저장됨-;

상기 제2 파티에 의하여 적어도 제3 디지털 서명 및 상기 제2 파티에 대한 제3 인증서를 포함하는 제3 디지털 서명 블록을 상기 검색된 공인된 정보 객체에 포함시킴으로써, 상기 검색된 공인된 정보 객체를 실행하는 단계; 및

상기 실행된, 검색된 공인된 정보 객체를 상기 신뢰할만한 보호 유틸리티(trusted custodial utility, TCU)에 포워딩하는 단계-여기서, 상기 TCU는 디지털 서명들을 확인하며, 상기 정보 객체들에 포함된 디지털 서명들에 상응하여 적어도 청구항 1에 따라서 제공되는 인증 상태 서비스(Certificate Status Service, CSS)로부터 인증서들의 상태를 검색함으로써 인증서들을 검증하며, 상기 TCU는 각 디지털 서명이 확인되지 않거나 각 인증서의 상태가 만료되거나 해제되는 경우에 디지털 서명 블록을 거부하며, 상기 정보 객체 내의 적어도 하나의 서명 블록이 거부되지 않는다면, 상기 TCU는 상기 정보 객체에 상기 TCU의 디지털 서명 블록 및 날짜 및 시간 지시자(indicator)를 추가하며 상기 제1 파티측의 객체에 대한 제어를 수행함-;

를 포함하는 검증할 수 있는 에비던스 트레일(evidence trail)을 가지는 공인된 정보 객체(authenticated information object)의 전송 제어에 의하여 제1 파티(party)와 제2 파티 사이의 트랜잭션(transaction)을 수행하는 방법.
제19항에 있어서,

서명 블록은 상기 서명 블록이 포함되는 상기 정보 객체의 적어도 한 부분(portion)에 대한 적어도 하나의 해쉬(hash)를 포함하며, 상기 적어도 하나의 해쉬는 각 블록의 각각의 서명자(respective signer)의 암호화 키에 의하여 암호화되는 데, 이로 인하여 서명자의 디지털 서명이 형성되며, 상기 서명자의 디지털 서명은 상기 서명자의 인증서와 함께 서명 블록에 포함되는 것을 특징으로 하는 검증할 수 있는 에비던스 트레일(evidence trail)을 가지는 공인된 정보 객체(authenticated information object)의 전송 제어에 의하여 제1 파티(party)와 제2 파티 사이의 트랜잭션(transaction)을 수행하는 방법.
제20항에 있어서,

상기 실행 단계는 로컬의 날짜 및 시간을 상기 제2 파티에 디스플레이하는 단계, 상기 제2 파티에 의하여 상기 디스플레이된 로컬의 날짜 및 시간이 정확하다는 것을 확인하는 단계 및 부정확한 로컬의 날짜 및 시간이 있으면 정정하는 단계를 포함하는 것을 특징으로 하는 검증할 수 있는 에비던스 트레일(evidence trail)을 가지는 공인된 정보 객체(authenticated information object)의 전송 제어에 의하여 제1 파티(party)와 제2 파티 사이의 트랜잭션(transaction)을 수행하는 방법.
제19항에 있어서,

상기 TCU가 디지털 서명 블록을 거부하면, 상기 TCU는 상기 디지털 서명이 다시 계산되며 상기 서명 블록이 재포워드 되도록 요청하는 복구(remedy)를 요청하는 것을 특징으로 하는 검증할 수 있는 에비던스 트레일(evidence trail)을 가지는 공인된 정보 객체(authenticated information object)의 전송 제어에 의하여 제1 파티(party)와 제2 파티 사이의 트랜잭션(transaction)을 수행하는 방법.
제19항에 있어서,

상기 TCU는 상기 날짜 및 시간이 정확한 지 여부 및 상기 제2 파티의 인증서에 의하여 표시되는 유효 기간 내에 존재하는 지 여부를 체크하는 것을 특징으로 하는 검증할 수 있는 에비던스 트레일(evidence trail)을 가지는 공인된 정보 객체(authenticated information object)의 전송 제어에 의하여 제1 파티(party)와 제2 파티 사이의 트랜잭션(transaction)을 수행하는 방법.
제23항에 있어서,

상기 날짜 및 시간이 상기 제2 파티의 인증서에 의하여 표시되는 유효 기간 내에 존재하지 않으면, 상기 TCU는 제2 파티에 상기 인증서가 거부되었음을 통보하며, 제1 파티에 상기 트랜잭션이 불완료되었음을 통보하는 것을 특징으로 하는 검증할 수 있는 에비던스 트레일(evidence trail)을 가지는 공인된 정보 객체(authenticated information object)의 전송 제어에 의하여 제1 파티(party)와 제2 파티 사이의 트랜잭션(transaction)을 수행하는 방법.
제19항에 있어서,

하나 또는 그 이상의 디지털화된 수기 서명들(digitized handwritten signatures)은 상기 정보 객체에 포함되며, 데이터 스트럭쳐에서 상기 디지털화된 수기 서명들에 대한 배치(placement)는 적어도 하나의 서명 태그(signature tag)에 의하여 특정되는 것을 특징으로 하는 검증할 수 있는 에비던스 트레일(evidence trail)을 가지는 공인된 정보 객체(authenticated information object)의 전송 제어에 의하여 제1 파티(party)와 제2 파티 사이의 트랜잭션(transaction)을 수행하는 방법.
제19항에 있어서,

데이터 스트럭쳐에 포함된 하나 또는 그 이상의 서명 블록들에 대한 배치는 적어도 하나의 서명 태그에 의하여 특정되는 것을 특징으로 하는 검증할 수 있는 에비던스 트레일(evidence trail)을 가지는 공인된 정보 객체(authenticated information object)의 전송 제어에 의하여 제1 파티(party)와 제2 파티 사이의 트랜잭션(transaction)을 수행하는 방법.
제26항에 있어서,

하나 또는 그 이상의 서명 블록들은 서명 태그들에 따라서 상기 TCU에 독립적으로 포워드되며, 상기 TCU는 상기 각 디지털 서명이 확인되지 않거나 각 인증서가 유효하지 않으면 서명 블록을 거부하며, 상기 서명 블록이 거부되지 않으면 각 서명 태그에 따른 서명 블록을 배치하는 것에 의하여 서명 블록들을 검증하며,

서명 블록들을 독립적으로 전송하기 위하여, 상기 TCU는 날짜 및 시간 지시(indication)를 각 서명 블록에 추가하며, 비즈니스 룰들(business rules)에 따라서 래퍼(wrapper) - 상기 래퍼는 정보 객체들을 가질 수 있는 암호 메시지 규격임 - 에 상기 TCU의 서명 블록을 추가하고, 상기 래퍼는 상기 정보 객체와 배치된 서명 블록들을 포함하는 것을 특징으로 하는 검증할 수 있는 에비던스 트레일(evidence trail)을 가지는 공인된 정보 객체(authenticated information object)의 전송 제어에 의하여 제1 파티(party)와 제2 파티 사이의 트랜잭션(transaction)을 수행하는 방법.
제27항에 있어서,

상기 TCU는 디지털 서명을 확인하며 상기 비즈니스 룰들로부터 상기 인증서에 상응하는 파티가 권한을 가지고 있는 지의 여부를 판단하며, 상기 파티의 디지털 서명을 확인하며 상기 인증서의 유효 기간이 상기 TCU의 현재 날짜 및 시간을 포함하는지를 체크하며, 상기 CSS로부터 상기 인증서의 상태를 검색하는 것에 의하여 서명 블록 내의 인증서를 검증하며, 이전 단계 중 하나라도 비유효하거나 잘못된 결과를 출력하면, 상기 디지털 서명은 유효하지 않은 것으로 판단되며, 상기 트 랜잭션은 실행되지 않으며, 그렇지 않으면 상기 디지털 서명은 유효한 것으로 판단되며 상기 트랜잭션은 실행되는 것을 특징으로 하는 검증할 수 있는 에비던스 트레일(evidence trail)을 가지는 공인된 정보 객체(authenticated information object)의 전송 제어에 의하여 제1 파티(party)와 제2 파티 사이의 트랜잭션(transaction)을 수행하는 방법.
제19항에 있어서,

상기 CSS는 적어도 상기 인증서의 상태 정보에 대한 로컬 캐시 메모리를 체크하는 단계와 만일 상기 인증서의 상태 정보가 상기 로컬의 캐시 메모리에서 발견되며 상기 로컬의 날짜 및 시간이 유효 기간 내에 존재하면, 상기 로컬의 캐시 메모리로부터 상기 인증서의 상태 정보를 검색하거나, 만일 생존시간 또는 사용-카운터 데이타 요소가 초과되면 상기 캐시 메모리 엔트리의 소거를 요구하는 단계에 의하여 상기 인증서 상태 정보를 상기 TCU에 제공하며, 상기 인증서의 상태 정보가 상기 로컬의 캐시 메모리에서 발견되지 않거나 상기 로컬의 날짜 및 시간이 상기 유효 기간 내에 존재하지 않으면, 상기 CSS는 상기 발행 CA의 인증 상태 보고 요소와의 통신 세션을 개설하며, 구성된 커넥터에 따른 인증 상태 리퀘스트를 구성하며, 상기 인증 상태 보고 요소로부터 상기 인증서의 상태 정보를 검색하며, 상기 인증 상태 보고 요소와의 통신 세션을 종료하며, 적어도 상기 인증서의 식별, 인증서의 상태 정보 및 만료 시간 데이터 요소를 상기 로컬의 캐시 메모리에 추가하는 것을 특징으로 하는 검증할 수 있는 에비던스 트레일(evidence trail)을 가지는 공인된 정보 객체(authenticated information object)의 전송 제어에 의하여 제1 파티(party)와 제2 파티 사이의 트랜잭션(transaction)을 수행하는 방법.
제19항에 있어서,

상기 제1 파티는 제1 TCU이며, 상기 트랜잭션은 제2 TCU로부터 상기 제1 TCU로의 하나 또는 그 이상의 전자적 원시들(electronic originals)에 대한 이동 관리(transferring custody) - 상기 전자적 원시들에 대한 이동 관리는 소정의 장소에서 다른 장소로의 상기 전자적 원시들의 이동임 - 를 위한 것이며, 상기 트랜잭션의 소유자는 상기 제1 TCU로 전송될 전자적 원시들을 식별하기 위한 명부(manifest)를 상기 제2 TCU로 제공하며, 상기 제2 TCU는 상기 제1 TCU와의 통신을 개설하며 자신의 행동 목적을 식별하며, 상기 명부는 상기 이동 관리가 완료되는 것을 판단할 수 있도록 상기 제1 TCU로 통신되며, 상기 제2 TCU는 상기 제1 TCU로 각각의 식별된 전자적 원시들을 전송하며, 상기 제1 TCU는 상기 제2 TCU의 인증 상태를 검색하며 각 전송된 전자적 원시들에 있어서의 상기 제2 TCU의 디지털 서명을 확인하며, 만약 상기 제2 TCU의 디지털 서명들이나 인증서들이 유효하지 않으면 상기 제1 TCU는 상기 제2 TCU에게 통보하며 복구 방안(remedy)을 찾으며, 상기 제2 TCU가 복구 방안을 제공하지 않으면 상기 제1 TCU는 상기 트랜잭션 소유자에게 요청된 이동 관리는 실패하였음을 통보하며, 그렇지 않으면 상기 제2 TCU는 각 각의 성공적인 전송 정보 객체에 대하여 새로운 래퍼(wrapper) - 상기 래퍼는 정보 객체들을 가질 수 있는 암호 메시지 규격임 - 를 생성하며, 날짜-시간 스탬프(stamp) 및 상기 제1 TCU의 서명 블록을 추가하는 것을 특징으로 하는 검증할 수 있는 에비던스 트레일(evidence trail)을 가지는 공인된 정보 객체(authenticated information object)의 전송 제어에 의하여 제1 파티(party)와 제2 파티 사이의 트랜잭션(transaction)을 수행하는 방법.
제30항에 있어서,

상기 트랜잭션은 명령에 따른 소유권(ownership)에 대한 트랜스퍼(transfer)이며, 소유권 도큐먼테이션(ownership documentation)의 트랜스퍼는 제1 TCU 또는 제2 TCU에 배치되며, 상기 소유권 도큐먼테이션에 대한 트랜스퍼를 가지는 상기 TCU는 모든 디지털 서명들, 인증 유효 기간을 확인함으로써 상기 소유권 도큐먼테이션에 대한 트랜스퍼에 대한 권한을 검증하며, 상기 CSS를 사용하여 상기 소유권 도큐먼테이션의 트랜스퍼에 포함된 모든 인증서들의 인증 상태를 체크하기 위하여, 날짜 및 시간 지시 및 디지털 사인들(digitally signs), 랩들(wraps)을 추가하며 상기 명부에 추가되는 소유권 도큐먼테이션의 트랜스퍼를 저장하는 것을 특징으로 하는 검증할 수 있는 에비던스 트레일(evidence trail)을 가지는 공인된 정보 객체(authenticated information object)의 전송 제어에 의하여 제1 파티(party)와 제2 파티 사이의 트랜잭션(transaction)을 수행하는 방법.
제19항에 있어서,

인증 상태들은 상기 CSS에서 인증 해제 리스트(Certificate Revocation List, CRL)에 의하여 표시되며, 상기 발행 CA의 공개 스케줄에 따라서, 상기 CSS는 상기 구성 스토어에 리스트된 인증 상태 보고 요소로부터 상기 CRL을 검색하며, 상기 CSS는 상기 발행 CA에 상응하여 캐시 메모리를 지우며, 상기 CSS는 상기 CRL로부터 인증서의 상태를 판단하며 상기 발행 CA에 상응하여 상기 캐시 메모리에 상기 상태를 저장하는 것을 특징으로 하는 검증할 수 있는 에비던스 트레일(evidence trail)을 가지는 공인된 정보 객체(authenticated information object)의 전송 제어에 의하여 제1 파티(party)와 제2 파티 사이의 트랜잭션(transaction)을 수행하는 방법.
제19항에 있어서,

인증 상태는 상기 CSS에서 델타 인증 해제 리스트(Delta Certificate Revocation List, Delta CRL)에 의하여 표시되며, 상기 CSS는 상기 구성 스토어에 리스트된 인증 상태 보고 요소로부터 상기 CRL을 검색한다는 상기 발행 CA에 의한 통보(notification)에 따라서 델타(Delta) 인증 해제 리스트(CRL)에 의하여 표시되는데, 상기 CRL이 완전한 CRL(complete CRL)이면, 상기 CSS는 상기 발행 CA에 상응하여 캐시 메모리를 지우며 상기 CRL로부터의 상기 인증서의 상태를 판단하며 상기 캐시 메모리에 상기 인증서의 상태 정보를 저장하며, 상기 CRL이 전체 CRL(full CRL)의 공개 이후에 발생한 변화들(changes)만을 포함하면, 상기 CSS는 상기 CRL로부터 상기 인증서의 상태를 판단하며 상기 캐시 메모리에 상기 인증서의 상태 정보를 저장하는 것을 특징으로 하는 검증할 수 있는 에비던스 트레일(evidence trail)을 가지는 공인된 정보 객체(authenticated information object)의 전송 제어에 의하여 제1 파티(party)와 제2 파티 사이의 트랜잭션(transaction)을 수행하는 방법.
제5항에 있어서,

백그라운드의 낮은 우선순위 유틸리티(priority utility)가 소정의 캐시 엔트리를 제거하고, 상기 소정의 캐시 엔트리는 CSS 정책으로 설정된 경우 생존시간 데이터 요소가 현재의 로컬 시간을 초과하고/거나 상태 업데이트를 초기화할 수 있는 것을 특징으로 하는 각 발행 인증 기관들(Certification Authorities, CAs)에 의하여 발행된 인증서(authentication certificates)의 유효성을 체크하기 위한 인증 상태 서비스(Certificates Status Service, CSS) 제공 방법.
제1항에 있어서,

1차로 지정된 어느 하나의 CSS가 CA, PKI 또는 인증서 상태 서버로부터 인증서 상태를 검색하고, 2차로 지정된 CSS가 인증서 상태에 대하여 1차 CSS에게 질문하는 것을 특징으로 하는 각 발행 인증 기관들(Certification Authorities, CAs)에 의하여 발행된 인증서(authentication certificates)의 유효성을 체크하기 위한 인증 상태 서비스(Certificates Status Service, CSS) 제공 방법.