제 4 장 . 공개키 기반구조

1. 제 4 장. 공개키 기반구조

2. 목 차 개요 4.1 공개키 인증의 필요성 4.2 상호인증 4.3 공개키 기반 구조의 구성 4.4 PKI(Public Key Infrastructure) 4.5 X.509 인증서 형식 4.6 인증서 취소 목록 4.7 PKI 관리 4.9 주요 관리 기능 4.10 인증 실무 준칙 4.11 PKI 운영 프로토콜

3. 개 요 • 공개키 기반 구조(Public Key Infrastructure) • 공개키 암호 시스템을 사용하는 암호시스템에서 사용자의 공개키를 안전하고 신뢰성 있게 공표하는 수단을 제공 • 안전하고 신뢰성 있게 사용자의 공개키를 공표 • 인터넷 전자상거래 및 정부 정보통신망에서 매우 중요한 역할 • 관련 용어 • 인증서, OID(Object Idnetifier), X.500 DN(Distinguished Name) • 인증실무준칙(CPS : Certification Practice Statement), LDAP(Lightweight Directory Access Protocol), FTP(File Transfer Protocol), OCSP(Online Certificate Status Protocol)

4. 4.1 공개키 인증서 필요성 및 개요 • 파일 전송 프로토콜, WWW, 기타 security application은 공개키 알고리즘에 바탕 • 자신의 공개키 공표, 개인키를 비밀스럽게 간직 • 공개키 기반 구조 • 공개키 암호 시스템을 사용한다는 전제 하에서 구축 • 공개키 인증서에 바탕을 두고 구축해야 함 • 인증서 • CA(Certification Authority)가 end entity를 인증하는 전자증명서 역할 수행 • CA는 자신의 private key를 사용하여 digital signature를 생성하여 인증서에 첨부 • CA의 public key를 사용하여 인증서 확인 • 인증서 사용자에 대한 공개키와 신분에 대한 정보 포함

5. 송신자의 개인키로 서명 송신자의 서명 부분을 자신의 서명으로 바꾸어 전송 • 공개키 인증서의 필요성 도청자 Internet 송신자 A 수신자 A의 공개키로 서명 확인 공개키 등록 공개키 디렉토리

6. 공개키 인증서(인증서) • 사용자의 공개키와 사용자의 ID를 결합한 digital stream • 특정 개체 확인, 특정 활동, 권한, 능력을 허가하는데 이용 • 인증 기관(CA : Certificate Authority)의 서명문을 포함 • 사용자 공개키와 사용자 신분 확인 • CA에 의해 수행 또는 등록 기관(RA : Registration Authority)에 의해 수행 • 인증서 형식 : X.509 버전 1, 2, 3

7. 인증서 구조 • 버전(Version) : 인증서 형식의 연속된 버전의 구분, 기본은 1988년 • 일련번호(Serial Number) : 발행 CA내부에서는 유일한 정수값 • 알고리즘 식별자(Algorithm Identifier) : 인증서를 생성하는데 이용되는 서명 알고리즘을 확인하기 위한 서명 알고리즘 OID • 발행자(Issuer) : 인증서를 발행하고 표시하는 CA • 유효기간(Period of validity) : 인증서가 유효한 첫번째와 마지막 날짜 두 개로 구성 • 주체(Subject) : 인증서가 가리키는 사람 • 공개키 정보(Public-key information) : 주체의 공개키와 이 키가 사용될 알고리즘의 식별자 • 서명(Signature) : CA의 개인 서명키로 서명한 서명문

8. 공개키 기반 구조(PKI : Public Key Infrastructure) • 공개키 암호 시스템에서 사용하는 공개 정보를 공표하는 보안 시스템의 일종 • 다양한 인터넷 보안 응용을 가능케 하기 위한 바탕을 제공 • 대표적인 보안 서비스 • 프라이버시 보호 • 전자서명 서비스 • 구성 요소 • 공개키 인증서(Certificate), 인증기관(Certification Authority), 등록 기관 (RA : Registration Authority) • End entity, CA의 인증서 관리 서비스, 디렉토리 서비스 규정 • 각 개체에 대한 인증과 신분 확인 기능을 제공 – 1996년

9. CA의 공개키 – off-line으로 users에게 전달 • User들은 CA의 공개키를 항상 저장 • 해당 CA에서 발행한 인증서의 유효성을 검증하기 위해 사용 • 최상위 CA의 인증서 • root CA에서 서명후 발급 • 하위 CA 및 end user들에게 모두 공유 • 인증 경로 • 여러 개 인증서들의 chain • 신뢰 체인(Trusted Path)라고도 함 • 검증 : 각 CA가 발행한 CRL(Certificate Revocation List)을 검증하여 만기 이전의 폐기 상태를 함께 검증

10. Root CA Brand CA GCA CCA CCA PCA Card holderSign Merchant Signature Merchant Key EX PG Signature PG Key EX SET에서의 hierarchical CA structure

11. 인증서 소유자 • 인증서의 주체 필드(subject field)를 X.500 directory의 DN(Distinguished Name)으로 유일하게 확인 • X.500 directory • 전화번호부와 비슷한 역할 • X.500 directory entry • 특정인의 주소, 전화번호, 이름, 조직, e-mail address, 직위 등의 부가 정보를 제공 • 개체의 공개키를 규정하는 인증서를 포함 • 유일하게 구별 가능한 이름인 DN을 할당받음 • DN의 유일성을 보장하기 위해 X.500 directory는 계층적 구조를 DIT(Directory Information Tree)로 구성 • Root node를 제외한 모든 node는 RDN(Relative Distingusihed Name)을 할당 받음

12. X.500 directory entry (Continued) • Root node아래에는 두 개의 문자로 구성된 나라를 나타내는 RDN이 할당 • ISO에 의해 할당 • 정부조직, 일반 회사, 지방 정부, 국영 회사 등의 entry등이 존재 • 각 entry는 unique RDN을 할당 받음 • End organization은 포함하고 있는 다양한 개체들을 나타내는 entry들을 포함 • Unique RDN이 할당

13. X.500 DN Root RDN = KR 한국 미국 RDN = SCH 순천향대 정부 정부 IBM RDN = K.D.Hong 홍길동 속 성 DN : {C=KR, O=SCH, CN=K.D.Hong } CN : K.D.Hong 전화번호 : 0418-542-8819 전자우편 주소 : kdhong@sec.sch.ac.kr 직위 : 연구원

14. 4.2 상호인증 • 모든 최종 개체가 하나의 CA로부터 인증서를 발급받는 것은 불가능 • 여러 보안 구역으로 나뉘고, 해당하는 CA로부터 인증서 발급 • 다른 보안 영역에 존재하는 CA간의 상호 인증(Cross-certification)이 요구 • 상호 인증시 연결점이 필요 • 인증 경로 • PKI 계층에서 신뢰의 연결 고리 • 신뢰구간 확장을 위한 CA구조 • 계층적 구조 • 네트워크형 평면적 구조 • 두 방식을 결합한 구조

15. 상호 인증 및 인증 경로 CA Y CA Z CA X Bob의 인증서 Alice의 인증서 Bob Alice

16. CA 계층 구조 • PAA(Policy Approving Authority) • 최상위 계층이면서 다음 하위 계층인 PCA로 인증서를 발행 • PCA(Policy Certification Authority) • 응용에 따른 인증서 정책을 결정 • CA(Certification Authority) • 특정의 그룹 및 조직 구성원에게 인증서를 발행 • 인증 • CA가 최종 개체를 위하여 인증서를 발행 • 인증서 사용자가 인증서에 대한 유효성을 검증 • 인증의 유형 • ID 인증 (Identity Authentication) • 자격 인증(Credential Authentication)

17. 확장자(extention) • 인증서 정책, 인증서 정책 매핑 필드, 대체 이름 필드, 개체 디렉토리 속성 필드, 인증 경로 제한 속성 필드 등을 포함 • X.509 버전 3 • 기존 버전 1, 2에 비해 확장자의 개념을 도입 • 인증 경로의 제한 • 특정 CA로 부터 나올 수 있는 인증 경로의 유형을 제한하는 기능을 수행 • 인증 경로를 현재의 인증서로부터 특정의 이름 공간, 그리고 특정의 정책 하에서 발행된 상호 인증서로 제한하는 기능을 수행 • 버전 3에만 있는 기능으로서 매우 중요한 의미를 가짐

18. 4.3 공개키 기반 구조의 구성 • PKI 방식 : 순수 계층 방식과 네트워크 구조 방식 • 순수 계층 방식 • 최상위 인증 기관인 root CA에 바탕을 둠 • 최상위 계층의 root CA • 전반적인 PKI 정책을 수립 • 제 2계층 CA를 인증 • 제 2계층 CA • 루트 CA에 의해 설정된 정책 하에 자신의 정책을 수립 • 제 3계층 CA를 인증 • 제 3계층 CA • 사용자를 인증 • 하부의 CA간의 상호 인증은 원칙적으로 배제 • 루트 CA간의 상호인증을 통한 국제간 상호 동작을 원활히 함

19. 순수계층 구조 루트-CA 사용자 제2계층 - CA 제 3계층 -CA

20. 네트워크 구조 • 모든 구조가 평면적으로 구성 • 모든 CA간에 상호인증을 허용 • 상호인증의 수가 대폭 증가하는 단점이 있다. 개별 기반구조 사용자

21. 4.4 PKI 구성 요소 정의 • PAA • 전체 PKI 시스템 내에서 수행되는 정책을 설정하는 당국 • 모든 사용자와 사용자의 연합, CA들이 지켜야 할 전반적인 사용지침을 생성 • 하부 PCA에 대한 인증기능 및 국가적, 다국적 기반 구조의 PAA들과의 상호인증(상호인증서 발급) 기능 수행 • 모든 하부 PCA의 지역적인 정보와 정책을 공표 • 인증서에 대한 취소 요구 정보 수신 및 확인 • 자신이 발급한 인증서에 대한 CRL 생성 • 호주 PKAF ; PARRA • 캐나다 GOC PKI ; PMA • 유럽 ICE –TEL PKI ; ICE-TEL CA 등

22. PCA • PAA에서 승인된 전반적인 정책을 확장하거나 세부화된 정책을 생성 • 정책 생성 당국이라는 표현이 더 정확함 • 조직 혹은 공동사회(COI, Community of Interest)에서 사용될 정책을 설정 • 누가 키를 생성할 것인가? • 계수의 범위를 얼마로 할 것인가? • 인증서의 유효기간을 얼마로 할 것인가? • 어떻게 CRL이 취급될 것인지?… • 등등의 세부 사항을 명세화

23. CA • PAA/PCA의 정책에 따라서 사용자에게 공개키 인증서를 발급 • 타 CA에 대한 상호 인증서를 발급하는 기능 • PCA의 정책 규제 조건을 만족하는 키 생성 계수를 사용하여 키 쌍을 생성 • 생성한 키 쌍에 대해 PCA의 규제 조건을 만족하는지 확인 • 하위에 또 다른 CA를 둠으로써 일종의 PCA역할을 겸할 수도 있다.

24. ORA(Organizational Registration Authority) • 사용자와 CA 중간에서 인증서 요구 및 전달 역할을 수행 • 사용자와 CA가 서로 원거리에 있을 경우 • GOC PKI에서는 LRA(Local Registration Authority)라고 함 • 사용자 신원 확인 • 사용자의 신원 정보와 공개키를 서명 후 CA에게 전송 • CA로부터 인증서 수신 및 확인 • 인증서 취소 요구를 받아 정당성 확인 및 CA에게 인증서 취소 요구를 전달

25. 4.5 X.509 인증서 형식 • X.509 • ITU에 의해 제안된 인증서에 대한 기본 형식을 정의한 규격 • 인증서 데이터 형식 • 인증서를 이용한 공개키의 효율적인 분배 방법을 정의 • X.509 v1, v2 • 인증서 취소 목록(CRL:Certificate Revocation List)를 포함 • X.509 v3 • 인증서를 정의하는 다양한 환경에 맞는 조건과 서명 알고리즘들의 선택이 가능하도록 확장영역을 추가

26. X.509 v1 • 1988년 발표 • 인증서 구성 요소 • CA의 개인키로 서명

27. X.509 v1 • 인증 경로 • DTI(Directory Information Tree)에서의 노드들의 경로 • 다른 보안 영역 CA들간의 사용자간 통신시에 이용 • 유효기간이 경과 • CA는 해당 인증서를 디렉토리에서 제거 • 추후 부인 봉쇄 서비스를 위해 일정기간 보관 • 인증서의 폐기 • 개인키가 공개키로 유출되었다고 판단되는 경우 • 해당 사용자가 CA에 신고함으로서 수행

28. X.509 v2 • X.509 v1 형식과 거의 비슷 • 두 개의 옵션을 추가 • 발급자 고유 ID(issuer unique identifier) • 선택영역 • 발급자 CA의 X.500 이름에 대한 부가 정보를 포함 • 관리가 어렵고 식별이 용이치 않아서 대부분의 구현 제품들에서 사용되지 않음 • 주체 고유 ID(subject unique identifier) • 선택영역 • 인증서 주체의 X.500 이름에 대한 부가 정보를 포함

29. X.509 v3 • 새로운 개념이 많이 도입 • 확장자 도입 • X.509 실현자가 그들의 용도에 적합하게 인증서 내용을 정의할 수 있게 하기 위함 • 표준 확장자(standard extension) • 인증서 정책 정보, 주체(subject) 디렉토리 속성, 인증 경로 제한, 확장된 CRL 기능들을 제공 • 사용자 공개키에 대한 정보, 인증서 관리를 위한 부가적인 사항을 표시 • 확장 영역은 크게 3개의 부분으로 구분 • 키 및 정책 확장자, 주체와 발급자에 대한 속성 정보, 인증서 경로 규제 정보

30. X.509 v3 인증서 형식

31. 키 및 정책 확장자 • 주체 및 발급자 키에 대한 부가적인 정보를 포함 • CA 키 고유번호(Authority Key Identifier) • 하나의 CA는 여러 개의 키를 보유할 수 있는데 이를 확인하기 위한 기능을 수행 • 키 속성(Key Attribute) • 인증서에 포함된 공개키에 대한 속성을 표시 • 인증서 정책(Certificate Policy) • 대규모 PKI 등에 있어서 필수적인 요소 • 사용하고 있는 정책에 관한 정보 • 키 사용 규제(Key Usage Restriction) • 인증서에 포함된 키의 용도에 따른 정책과 관련된 규제를 정의 • 정책매핑(Policy Mapping) • 타 CA에서 사용되는 정책과의 정책 매핑을 규정

32. 주체와 발급자에 대한 속성 정보 • 인증서 사용자에게 신뢰성을 주기 위한 영역 • 주체와 발급자에 대한 부가적인 정보를 가짐 • 주체 대체 이름(Subject Alternative Name) • 인증서의 사용자 주체의 이름 혹은 또 다른 별개의 이름에 대한 부가정보를 표시 • 사용자 ID, e-mail / IP 주소, DNS 이름 등 • 발행자 대체 이름(Issuer Alternative Name) • 인증서 발급자의 이름 혹은 별개의 이름에 대한 부가정보 표시 • 인증서 발급자 이름, 발급자 ID, E-mail / IP 주소, DNS 이름 등 • 주체 디렉토리 속성(Subject Directory Attribute) • 인증서 사용자 주체에 대한 X.500 속성 값을 의미

33. 인증서 경로 규제 정보 • 키 사용 규제, 기본 규제, 이름 규제, 정책 규제 영역은 상당히 중요한 의미를 지님 • 기본 규제(Basic Constraints) • 주체가 CA인지, 인증 경로에 대한 정보 포함되어야 함 • 이름 규제(Name Constraints) • 인증 경로 하부에 형성되는 CA들에 대한 이름 명명에 관한 일련의 규제를 의미 • 인증서 체인에 대한 정보를 쉽게 알 수 있다. • 정책 규제(Policy Constraints) • PKI내의 다른 정책과의 호환성을 유지하기 위하여 정책 결정에 대한 제한 범위를 규정

34. CRL을 위한 확장자 • 인증서가 취소되었을 경우 CRL에 접근할 수 있는 위치를 지정 • 델타 CRL(delta-CRL)의 유지 여부, 다른 인증기관에 의하여 유지되는 간접 CRL 위치를 나타냄 • CRL 분배점(Distribution Points) • CA :다양한 방법으로 분할, 관리 • 각각의 CRL부분은 다른 분배점을 통해 접근 • 델타 CRL(Delta-CRLs) • CRL의 크기를 줄이는 또 다른 방법을 제공 • 마지막으로 전체 CRL을 발표한 후 새로 취소된 인증서 목록만을 발행 • 간접 CRL(Indirect CRLs) • 해당 인증서 발행 CA가 아닌 다른 개체로부터 CRL이 발행될 수 있게 한다. • 여러 인증 기관에 의해 발행된 CRL을 하나로 모음

35. 4.6 인증서 취소 목록 • 인증서 취소 • 인증서 발행 조직에서의 탈퇴 • 비밀키의 손상 • 비밀키 유출의 의심 • 인증서 취소 메커니즘 • X.509에 정의된 CRL 메커니즘 • 인증서 취소 목록의 기본 영역 • 서명 알고리즘 : CRL에 서명한 서명 알고리즘 ID 및 관련 데이터 • 발급자 : 발급자 CA의 X.509 이름 • 최근 수정 일자 : 최근 수정 일자(UTC Time) • 차후 수정 일자 : 다음 수정 일자(UTC Time) • 취소 인증서 목록 : 취소된 인증서 목록들 • CRL확장자 : CRL 확장자 유무 및 내용 • 발급자 서명문 : 발급자의 서명문

36. CRL의 확장자 영역 : 기본 확장자 + 개체 확장자 • 기본 확장자 • CA 키 고유 번호 : CRL에 서명한 키 번호 • 발급자 대체 이름 : CRL 발급자의 대체 이름(e-mail, IP 주소 등) • CRL 발급자 번호 : CRL에 대한 일련 번호 • 발급 분배점 : CRL 분배점 이름 • 델타 CRL지시자 : 최근에 취소된 목록만을 저장한 델타 CRL 지시자 • CRL 개체 확장자 영역 • 취소 이유 부호 : 인증서가 취소된 이유 • 명령 부호 : 해당 인증서를 만났을 경우 취해져야 할 명령 • 무효화 날짜 : 해당 인증서가 무효화된 날짜 • 인증서 발급자 : 간접 CRL에서의 해당 인증서 발급자

37. 인증서 취소 요구 • 인증서 소유자 또는 인증서 소유자의 대리인의 요구에 의해 • CRL 공개 • 취소된 인증서에 대한 목록을 공개 디렉토리에 보관 • 네트워크를 통해 접속할 수 있도록 함 • CRL 생성 방법 • 주기적인 CRL 생성 방식 • 즉각 CRL 생성 방식 • 신속성, 안전성 면에서 우수 • 해당 CA에 상당한 부하가 예상 • 두 방식의 절충 방식이 바람직

38. 4.7 PKI 관리 • IETF의 표준안을 중심으로 관리모델, 관리 메시지의 데이터 구조, PKI 관리 기능을 정의 • 개요 • 관리 프로토콜 • PKI 구성 요소들 사이에 온라인 상호 작용을 지원해야 함 • CA와 클라이언트 사이에 이용, 또는 상호 인증서를 발행하는 두 CA 사이에 이용 가능 해야 함 • PKI 관리 모델 • 인증기관(CA), 등록기관(RA), 최종개체(EE), 저장소(Repository)로 구성 • PKI 관리를 위한 주요 요소 • 최종 요소, 인증기관, 등록기관

39. 최종 개체(EE : End Entity) • 주체 필드와 혼돈을 피하기 위해 사용 • PKI 관리 동작을 위한 모든 프로토콜에 영향 • 인증기관(CA) • 최종 개체와 다른 CA들에게 인증서를 발행하는 신뢰된 개체 • 단순히 신뢰 되는 개체임을 나타냄 • “하부 CA” : 루트 CA 이외의 CA를 지칭 • RA(Registration Authority) • CA를 대신하여 사용자의 신분을 확인 • 개인 사용자 확인, 토큰 분배, 취소 보고, 이름 할당, 키 생성, 키 쌍 등록 등의 기능을 수행 • RA가 존재하지 않을 때, CA가 RA의 기능들을 대신 • 최종 개체가 직접 CA와 통신할 수 있다.

40. PKI 관리 프로토콜을 위한 요구사항 -IETF • 정기적으로 키 생신 가능 • 기밀성의 사용은 최소화 • 다양한 상용 보안 알고리즘의 사용 가능 • 최종 개체, RA, CA에 의한 키 쌍의 생성을 배제해서는 안됨 • 최종 개체, RA, CA를 위한 인증서의 공표를 지원해야 됨 • E-mail, HTTP, TCP/IP, FTP와 같은 다양한 전송 메커니즘을 이용할 수 있어야 함 • 인증서 생성에 대한 최종 책임은 CA에게 있음 • CA 키 쌍의 갱신은 자연스럽고 계획적으로 이루어져야 함 • CA는 RA의 기능들을 수행할 수 있어야 함 • 최종 개체가 인증서를 요구할 경우, 최종 개체는 공개키에 대응하는 개인키를 증명할 수 있어야 한다.

41. 인증서 발급 및 취소를 위한 주요 절차 (1) 초기 등록 및 인증 • 등록/인증 초기화, 최종 개체에 대한 메시지 인증, 최종 개체를 위한 공개키의 생성, 사용자 인증 과정 등을 포함 • 최종 개체, RA 또는 CA 등에서 시작 • 인증 기관은 최종 개체에 의해 생성된 온라인 메시지들을 검증해야 한다. • 최종 개체에서 PKI(RA, CA)까지의 모든 메시지에 대해 발신처 인증을 수행해야 한다. • 키 생성 • 최종 개체를 위한 공개키 및 개인키 쌍이 처음으로 발생하는 것 • 어디서든지 생성되고 키 쌍은 해당 개체로 전송되어야 함 • 키를 생성 개체 : 최종 개체, RA, CA

42. (1) 초기 등록 및 인증 • 공개키/개인키 생성 방식 • 단말 개체에서 생성할 수 있는 방식 • 강력한 부인방지 기능 제공 • 안전성 높음 • 인증 기관 또는 제3의 신뢰기관에서 생성하는 집중형 키 생성 방식 • 단말개체에서 공개키/개인키 쌍을 생성할 수 없는 경우 • 키가 훼손된 경우에 키의 복구가 용이하다는 장점 • 최종 개체의 인증서 생성 후 인증 기관은 EE가 성공적으로 인증서를 수신했다는 것을 확신할 수 있어야 함 • 확신 메시지 -초기 인증키나 또는 다른 방법들에 의해 보호

43. 기본 키 생성 방식 1. Alice의 토큰 생성 6. LADP을 이용하여 인증서 공표 Directory Service CA 2. 생성된 토큰 Alice에게 전달 5. 인증 응답 4. 인증 요구 3. Alice는 자신의 공개키/개인키 쌍 생성 Alice

44. 중앙 집중형 키 생성 방식 6. LADP을 이용하여 인증서 공표 Directory Service CA 1. Alice의 개인키/공개키 쌍 생성 Alice의 인증서 생성 인증서를 토큰에 저장 2. 토큰을 Alice에게 전달 4. Alice는 인증서를 사용함 Alice

45. (2) 개인키 소유 증명(POP, Proof of Possession) • CA/RA는 최종 개체가 공개키에 대응하는 개인키를 소지하고 있다는 사실을 확신해야 한다. • 키의 유형에 따라 각각 다른 방법으로 수행될 수 있다. • 서명키 • 서명문을 작성, CA/RA로 전달하여 공개키로 서명문의 유효성을 검증함으로써 개인키 소유 검증 • 개인키 • CA/RA에 개인키를 제공하거나 특정값을 암호화한 암호문을 복호할 수 있는지를 판별함으로써 검증 • 키 일치키 • 최종 개체가 개인키를 소지 했음을 증명하기 위해 분배된 비밀키를 공유해야 한다.

46. (3) 루트 CA 키 갱신 • 루트 CA가 자신의 키 쌍을 갱신하는 절차 • CA는 새로운 공개키를 이전의 개인키를 이용하여 보호한다. • 키 변경 동작 절차 • 새로운 키 쌍 생성 • 새 개인키로 서명된 CA의 공개키를 포함하는 인증서를 생성 • 옛 개인키로 서명된 새로운 CA 공개키를 포함하는 인증서를 생성 • 새로운 개인키로 서명된 새로운 CA 공개키를 포함하는 인증서를 생성 • 디렉토리 혹은 다른 방법을 통하여 새 인증서를 공표 • 최종 개체가 새 CA 공개키를 획득한다.

47. (4) 인증서 취소 요구 및 처리 가. 키 손상 및 문제 발생 • 일부 개체의 키가 손상된 경우 개체와 관련된 인증서는 취소되어야 함 • 사용자의 소속이 변경되었을 경우에도 해당 사용자 또는 해당 CA의 공개키 인증서는 취소되어야 함 • 이러한 상황은 전화 혹은 기타 방법을 통하여 고지되어야 함 • 원칙적으로 키 손상 등의 문제 발생시 개체는 해당 CA에게 문제 발생을 고지할 책임이 있다. • CA • 해당 사용자에 대한 인증서 문제점 발생 여부 확인 • CRL 일렬번호와 차기 CRL 생성 일자를 첨부하여 해당 사용자의 인증서를 CRL에 추가시켜야 한다.

48. (나) 키 손상에 대한 복구 • CA 키의 손상 • 하부의 모든 사용자의 인증서를 재발급해야 함 • 인증서를 발급하기 이전에 모든 사용자들에 대한 생성과정이 선행되어야 함 • CA에게 매우 부담스러운 일 • 이중 CA구조를 가지고 있으며, • 두 개의 CA에 의해 발급된 공개키 인증서를 가지고 있다면 CA키 손상에 대한 회복 절차는 휠씬 용이

49. (다) CRL 획득 절차 • 모든 CA들은 CRL을 생성 • 주기적으로 생성 또는 취소 상황 발생시 마다 생성 • PKI에서 CRL을 얻기 위한 방법 • CA가 CRL을 생성하고 자동으로 하부 CA로 CRL을 보냄 • 즉각적인 통보가 필요 • 디렉토리에 문의하여 CRL을 얻는 방법 • 디렉토리 서비스 중단시 문제 발생, 비실용적 • CRL을 DB에서 획득하는 방법 • 제안되어 있는 대부분의 방법 • 모든 개체들은 디렉토리를 통해 CRL을 얻는다.

50. (라) 키 생성 및 재인증 • 키가 손상되지 않았을지라도 주기적으로 키 쌍을 재생성해야 함 • 키 변환 방법 • 매년 같은 날 모든 개체들이 키를 변환 • 각각의 개체에 의해 선택된 날에 키를 변환 • 어떠한 방법이라도 변경일 이전에 개체들은 새로운 키 쌍을 가져야 한다. • 새로운 키 쌍과 인증서는 변경일 이전에 생성되어야 함 • CA의 옛 개인키에 의해 서명되고 분배되어야 한다는 것을 의미 • 키 재생성 방법은 PKI내의 모든 계층에서 적용된다.