---
title: "GSSL Certificate Policy (CP) / Certification Practice Statement (CPS)"
language: "en"
source: "cps_v2.3_(ENG).pdf"
pages: 87
converted: "2026-11-02"
---

# GSSL Certificate Policy (CP) / Certification Practice Statement (CPS)

> 원본: `cps_v2.3_(ENG).pdf` · 87 pages

<!-- PDF page 1 -->

2026. 10.

Ministry of the Interior and Safety

<!-- PDF page 2 -->

### Revision History

| Version | Date | Revision Description | Prepared by | Approved by |
| --- | --- | --- | --- | --- |
| 1.0 | ‘23.2.9. | Creates first revision of certification practice<br>statement(CPS) in accordance with RFC 3647 and<br>CA/Browser Forum standards | Euiyeol<br>Choi | Changyun<br>Han |
| 1.1 | ‘23.4.14. | Details revised in accordance with RFC 3647 and<br>CA/Browser Forum standards | Euiyeol<br>Choi | Changyun<br>Han |
| 1.2 | ‘24.2.6. | Changed OCSP certificate validation period | Dongwha<br>Shin | Changyun<br>Han |
| 1.3 | ‘24.3.29. | Reflecting the latest CA Browser Forum TLS BRs:<br>- modified Section 9.4.6, Certificate Profile and<br>others<br>- updates to fixing terms and spelling errors | Dongwha<br>Shin | Changyun<br>Han |
| 1.4. | ‘24.6.25. | Compliance with Network security requirements<br>of CA/Browser Forum<br>- Add Content to “6.7 network security” | Uiseong<br>Jeong | TaeGeun<br>Han |
| 1.5 | ‘24.8.22. | Reflecting the latest CA Browser Forum TLS BRs:<br>- Add Content to “3.1, Support for Punycode<br>encoding for internationalized domains”<br>- Add Content to “3.4, 4.9.2, 4.9.12, Allow<br>certificate revocation requests by Any third<br>party in case of key compromise”<br>- updates to fixing terms and spelling errors | Jieun<br>Seong | ByoungHo<br>Park |
| 1.6 | ‘25.1.17. | Compliance with Network security requirements<br>of CA/Browser Forum<br>- Add Content to “3.2.2.4., Agreed-Upon Change<br>to Website - ACME (3.2.2.4.19)”<br>- updates to fixing terms and spelling errors | Jieun<br>Seong | ByoungHo<br>Park |
| 1.7 | ‘25.3.20. | Subscriber certificate profile change<br>- Removal of Client Authentication(1.3.6.1.5.5.7.3.2)<br>from the extendedKeyUsage extension | Jieun<br>Seong | ByoungHo<br>Park |
| 1.8 | ‘25.7.17. | Compliance with Network security requirements<br>of CA/Browser Forum<br>-<br>Removal of Email, Fax, SMS, or Postal Mail to<br>Domain (3.2.2.4.2); from 3.2.2.4.<br>- Add Content to “3.2.2.4., Agreed-Upon Change<br>to Website v2 (3.2.2.4.18)” | Jieun<br>Seong | ByoungHo<br>Park |
| 1.9 | ‘25.8.29. | Added compliance statement for Mass<br>Revocation Incident Preparation and Testing Plan,<br>‘MRIP&TP’ in Section 5.7.5 | Jieun<br>Seong | Misun Kim |

<!-- PDF page 3 -->

| Version | Date | Revision Description | Prepared by | Approved by |
| --- | --- | --- | --- | --- |
| 2.0 | ‘26.3.11. | Reflecting CA Browser Forum TLS BRs:<br>- Clarification of address validation procedures in<br>Section 3.2.2.1<br>- Structural adjustment of the CAA record<br>validation provisions in Section 3.2.2.8<br>- Addtion of Multi-Perspective Issuance<br>Corroboration(MPIC) in Section 3.2.2.9<br>- Removal of the CAA record validation<br>provisions from Section 4.2.4<br>- Modification of certificate validity period in<br>Section 4.3, 6.3.2<br>- Addition of role-based personnel requirements<br>in Section 5.2.2<br>- Addition of MPIC-related logging requirements<br>in Section 5.4.1 | Jieun<br>Seong | Sangchul<br>Park |
| 2.1 | ‘26.4.21. | - Standardization of Document Names and<br>Related terms(CP → CP/CPS)<br>- Addition of Acronym Definitions<br>- Updates to fixing terms and spelling errors | Yeonji<br>Seo | Sangchul<br>Park |
| 2.2 | ‘26.8.25. | Compliance with CCADB Policies and major<br>browser Root Program Policies in Section 1.1 | Yeonji<br>Seo | Sangchul<br>Park |
| 2.3 | ‘26.10.30. | - Revised CA warranties, liability limitations,<br>and compliance with external policies in<br>Section 1.1, 9.6.1, 9.8<br>- Aligned Korean and English IDN representations<br>in Section 3.1<br>- Clarified domain validation, non-reuse of<br>validation results, and IP address/Wildcard<br>Certificate non-issuance policies in Section<br>3.2.2.4, 4.2 3.2.2.5, 3.2.2.6<br>- Revised third-party Key Compromise<br>reporting, verification, and revocation<br>procedures in Section 3.4, 4.9.2, 4.9.3, 4.9.12<br>- Specified mass revocation planning in<br>Section 5.7.1, 5.7.5 | Yeonji<br>Seo | Sangchul<br>Park |

This work is licensed under the Creative Commons Attribution 4.0

International License.

<!-- PDF page 4 -->

## Table of Contents

- 1. INTRODUCTION (p. 1)
- 1.1. OVERVIEW (p. 1)
- 1.2. DOCUMENT NAME AND IDENTIFICATION (p. 2)
- 1.3. PKI PARTICIPANTS (p. 2)
- 1.3.1. Certification Authorities (p. 2)
- 1.3.2. Registration Authorities (p. 3)
- 1.3.3. Subscribers (p. 3)
- 1.3.4. Relying Parties (p. 3)
- 1.3.5. Other Participants (p. 4)
- 1.3.5.1. The Ministry of the Interior and Safety (The MOIS) (p. 4)
- 1.3.5.2. National Information Resources Service (p. 4)
- 1.3.5.3. Korea Local Information Research & Development Institute (p. 4)
- 1.4. CERTIFICATE USAGE (p. 5)
- 1.4.1. Appropriate Certificate Uses (p. 5)
- 1.4.2. Prohibited Certificate Uses (p. 5)
- 1.5. POLICY ADMINISTRATION (p. 5)
- 1.5.1. Organization Administering the Document (p. 5)
- 1.5.2. Contact Person (p. 6)
- 1.5.3. Person Determining CPS Suitability for the Policy (p. 6)
- 1.5.4. CPS Approval Procedures (p. 6)
- 1.6. DEFINITIONS AND ACRONYMS (p. 6)
- 1.6.1. Definitions (p. 6)
- 1.6.2. Acronyms (p. 8)
- 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES (p. 10)
- 2.1. REPOSITORIES (p. 10)
- 2.2. PUBLICATION OF CERTIFICATION INFORMATION (p. 10)
- 2.3. TIME OR FREQUENCY OF PUBLICATION (p. 10)
- 2.4. ACCESS CONTROLS ON REPOSITORIES (p. 11)
- 3. IDENTIFICATION AND AUTHENTICATION (p. 11)
- 3.1. NAMING (p. 11)
- 3.1.1. Types of Names (p. 11)
- 3.1.2. Need for Names to be Meaningful (p. 11)
- 3.1.3. Anonymity or Pseudonymity of Subscribers (p. 11)
- 3.1.4. Rules for Interpreting Various Name Forms (p. 11)
- 3.1.5. Uniqueness of Names (p. 12)
- 3.1.6. Recognition, Authentication, and Role of Trademarks (p. 12)
- 3.2. INITIAL IDENTITY VALIDATION (p. 12)
- 3.2.1. Method to Prove Possession of Private Key (p. 12)
- 3.2.2. Authentication of Organization Identity (p. 12)
- 3.2.2.1. Identity (p. 13)
- 3.2.2.2. DBA/Tradename (p. 15)

<!-- PDF page 5 -->
- 3.2.2.3. Verification of Country (p. 15)
- 3.2.2.4. Validation of Domain Authorization or Control (p. 15)
- 3.2.2.5. Authentication for an IP Address (p. 15)
- 3.2.2.6. Wildcard Domain Validation (p. 16)
- 3.2.2.7. Data Source Accuracy (p. 16)
- 3.2.2.8. CAA Records (p. 16)
- 3.2.2.9. Multi-Perspective Issuance Corroboration(MPIC) (p. 16)
- 3.2.3. Authentication of Individual Identity (p. 19)
- 3.2.4. Non-Verified Subscriber Information (p. 19)
- 3.2.5. Validation of Authority (p. 19)
- 3.2.6. Criteria for Interoperation (p. 20)
- 3.3. IDENTIFICATION AND AUTHENTICATION FOR RE-KEY REQUESTS (p. 20)
- 3.3.1. Identification and Authentication for Routine Re-key (p. 20)
- 3.3.2. Identification and Authentication for Re-key After Revocation (p. 20)
- 3.4. IDENTIFICATION AND AUTHENTICATION FOR REVOCATION REQUEST (p. 20)
- 4. CERTIFICATE LIFE CYCLE OPERATIONAL REQUIREMENTS (p. 21)
- 4.1. CERTIFICATE APPLICATION (p. 22)
- 4.1.1. Who Can Submit a Certificate Application (p. 22)
- 4.1.2. Enrollment Process and Responsibilities (p. 22)
- 4.2. CERTIFICATE APPLICATION PROCESSING (p. 23)
- 4.2.1. Performing Identification and Authentication Functions (p. 23)
- 4.2.2. Approval or Rejection of Certificate Applications (p. 23)
- 4.2.3. Time to Process Certificate Applications (p. 23)
- 4.3. CERTIFICATE ISSUANCE (p. 24)
- 4.3.1. CA Actions during Certificate Issuance (p. 24)
- 4.3.2. Notification to Subscriber by the CA of Issuance of Certificate (p. 25)
- 4.4. CERTIFICATE ACCEPTANCE (p. 25)
- 4.4.1. Conduct Constituting Certificate Acceptance (p. 25)
- 4.4.2. Publication of the Certificate by the CA (p. 25)
- 4.4.3. Notification of Certificate Issuance by the CA to Other Entities (p. 25)
- 4.5. KEY PAIR AND CERTIFICATE USAGE (p. 25)
- 4.5.1. Subscriber Private Key and Certificate Usage (p. 25)
- 4.5.2. Relying Party Public Key and Certificate Usage (p. 26)
- 4.6. CERTIFICATE RENEWAL (p. 26)
- 4.6.1. Circumstance for Certificate Renewal (p. 26)
- 4.6.2. Who May Request Renewal (p. 26)
- 4.6.3. Processing Certificate Renewal Requests (p. 26)
- 4.6.4. Notification of New Certificate Issuance to Subscriber (p. 26)
- 4.6.5. Conduct Constituting Acceptance of a Renewal Certificate (p. 26)
- 4.6.6. Publication of the Renewal Certificate by the CA (p. 27)
- 4.6.7. Notification of Certificate Issuance by the CA to Other Entities (p. 27)
- 4.7. CERTIFICATE RE-KEY (p. 27)
- 4.7.1. Circumstance for Certificate re-Key (p. 27)

<!-- PDF page 6 -->
- 4.7.2. Who May Request Certification of a New Public Key (p. 27)
- 4.7.3. Processing Certificate re-Keying Requests (p. 27)
- 4.7.4. Notification of New Certificate Issuance to Subscriber (p. 27)
- 4.7.5. Conduct Constituting Acceptance of a re-Keyed Certificate (p. 27)
- 4.7.6. Publication of the re-Keyed Certificate by the CA (p. 27)
- 4.7.7. Notification of Certificate Issuance by the CA to Other Entities (p. 28)
- 4.8. CERTIFICATE MODIFICATION (p. 28)
- 4.8.1. Circumstance for Certificate Modification (p. 28)
- 4.8.2. Who May Request Certificate Modification (p. 28)
- 4.8.3. Processing Certificate Modification Requests (p. 28)
- 4.8.4. Notification of New Certificate Issuance to Subscriber (p. 28)
- 4.8.5. Conduct Constituting Acceptance of Modified Certificate (p. 28)
- 4.8.6. Publication of the Modified Certificate by the CA (p. 28)
- 4.8.7. Notification of Certificate Issuance by the CA to Other Entities (p. 28)
- 4.9. CERTIFICATE REVOCATION AND SUSPENSION (p. 28)
- 4.9.1. Circumstances for Revocation (p. 29)
- 4.9.1.1. Reasons for Revoking a Subscriber Certificate (p. 29)
- 4.9.1.2. Reasons for Revoking a Subordinate CA Certificate (p. 30)
- 4.9.2. Who Can Request Revocation (p. 31)
- 4.9.3. Procedure for Revocation Request (p. 31)
- 4.9.4. Revocation Request Grace Period (p. 32)
- 4.9.5. Time within which CA Must Process the Revocation Request (p. 33)
- 4.9.6. Revocation Checking Requirement for Relying Parties (p. 33)
- 4.9.7. CRL Issuance Frequency (p. 34)
- 4.9.8. Maximum Latency for CRLs (p. 34)
- 4.9.9. On-line Revocation/Status Checking Availability (p. 34)
- 4.9.10. On-line Revocation Checking Requirements (p. 34)
- 4.9.11. Other Forms of Revocation Advertisements Available (p. 35)
- 4.9.12. Special Requirements re Key Compromise (p. 35)
- 4.9.13. Circumstances for Suspension (p. 35)
- 4.9.14. Who Can Request Suspension (p. 36)
- 4.9.15. Procedure for Suspension Request (p. 36)
- 4.9.16. Limits on Suspension Period (p. 36)
- 4.10. CERTIFICATE STATUS SERVICES (p. 36)
- 4.10.1. Operational Characteristics (p. 36)
- 4.10.2. Service Availability (p. 36)
- 4.10.3. Optional Features (p. 36)
- 4.11. END OF SUBSCRIPTION (p. 36)
- 4.12. KEY ESCROW AND RECOVERY (p. 36)
- 4.12.1. Key Escrow and Recovery Policy and Practices (p. 37)
- 4.12.2. Session Key Encapsulation and Recovery Policy and Practices (p. 37)
- 5. FACILITY, MANAGEMENT, AND OPERATION CONTROLS (p. 37)
- 5.1. PHYSICAL CONTROLS (p. 37)

<!-- PDF page 7 -->
- 5.1.1. Site Location and Construction (p. 37)
- 5.1.2. Physical Access (p. 37)
- 5.1.3. Power and Air Conditioning (p. 37)
- 5.1.4. Water Exposures (p. 38)
- 5.1.5. Fire Prevention and Protection (p. 38)
- 5.1.6. Media Storage (p. 38)
- 5.1.7. Waste Disposal (p. 38)
- 5.1.8. Off-site Backup (p. 38)
- 5.2. PROCEDURAL CONTROLS (p. 38)
- 5.2.1. Trusted Roles (p. 38)
- 5.2.2. Number of Persons Required per Task (p. 39)
- 5.2.3. Identification and Authentication for Each Role (p. 39)
- 5.2.4. Roles Requiring Separation of Duties (p. 40)
- 5.3. PERSONNEL CONTROLS (p. 40)
- 5.3.1. Qualifications, Experience, and Clearance Requirements (p. 40)
- 5.3.2. Background Check Procedures (p. 40)
- 5.3.3. Training Requirements (p. 40)
- 5.3.4. Retraining Frequency and Requirements (p. 41)
- 5.3.5. Job Rotation Frequency and Sequence (p. 41)
- 5.3.6. Sanctions for Unauthorized Actions (p. 41)
- 5.3.7. Independent Contractor Requirements (p. 41)
- 5.3.8. Documentation Supplied to Personnel (p. 41)
- 5.4. AUDIT LOGGING PROCEDURES (p. 42)
- 5.4.1. Types of Events Recorded (p. 42)
- 5.4.2. Frequency of Processing Log (p. 43)
- 5.4.3. Retention Period for Audit Log (p. 43)
- 5.4.4. Protection of Audit Log (p. 43)
- 5.4.5. Audit Log Backup Procedures (p. 43)
- 5.4.6. Audit Collection System (internal vs. external) (p. 44)
- 5.4.7. Notification to Event-causing Subject (p. 44)
- 5.4.8. Vulnerability Assessments (p. 44)
- 5.5. RECORDS ARCHIVAL (p. 44)
- 5.5.1. Types of Records Archived (p. 45)
- 5.5.2. Retention Period for Archive (p. 45)
- 5.5.3. Protection of Archive (p. 45)
- 5.5.4. Archive Backup Procedures (p. 45)
- 5.5.5. Requirements for Time-stamping of Records (p. 45)
- 5.5.6. Archive Collection System (internal or external) (p. 45)
- 5.5.7. Procedures to Obtain and Verify Archive Information (p. 45)
- 5.6. KEY CHANGEOVER (p. 45)
- 5.7. COMPROMISE AND DISASTER RECOVERY (p. 46)
- 5.7.1. Incident and Compromise Handling Procedures (p. 46)
- 5.7.2. Computing Resources, Software, and/or Data are Corrupted (p. 47)

<!-- PDF page 8 -->
- 5.7.3. Entity Private Key Compromise Procedures (p. 47)
- 5.7.4. Business Continuity Capabilities after a Disaster (p. 48)
- 5.7.5. Mass Certificate Revocation Response and Testing Plan (p. 48)
- 5.8. CA OR RA TERMINATION (p. 49)
- 6. TECHNICAL SECURITY CONTROLS (p. 49)
- 6.1. KEY PAIR GENERATION AND INSTALLATION (p. 49)
- 6.1.1. Key Pair Generation (p. 49)
- 6.1.2. Private Key Delivery to Subscriber (p. 49)
- 6.1.3. Public Key Delivery to Certificate Issuer (p. 50)
- 6.1.4. CA Public Key Delivery to Relying Parties (p. 50)
- 6.1.5. Key Sizes (p. 50)
- 6.1.6. Public Key Parameters Generation and Quality Checking (p. 50)
- 6.1.7. Key Usage Purposes(as per X.509 v3 Key Usage Field) (p. 50)
- 6.2. PRIVATE KEY PROTECTION AND CRYPTOGRAPHIC MODULE ENGINEERING CONTROLS ··51
- 6.2.1. Cryptographic Module Standards and Controls (p. 51)
- 6.2.2. Private Key (n out of m) Multi-person Control (p. 51)
- 6.2.3. Private Key Escrow (p. 51)
- 6.2.4. Private Key Backup (p. 51)
- 6.2.5. Private Key Archival (p. 51)
- 6.2.6. Private Key Transfer into or from a Cryptographic Module (p. 51)
- 6.2.7. Private Key Storage on Cryptographic Module (p. 51)
- 6.2.8. Method of Activating Private Key (p. 51)
- 6.2.9. Method of Deactivating Private Key (p. 52)
- 6.2.10. Method of Destroying Private Key (p. 52)
- 6.2.11. Cryptographic Module Rating (p. 52)
- 6.3. OTHER ASPECTS OF KEY PAIR MANAGEMENT (p. 52)
- 6.3.1. Public Key Archival (p. 52)
- 6.3.2. Certificate Operational Periods and Key Pair Usage Periods (p. 52)
- 6.4. ACTIVATION DATA (p. 52)
- 6.4.1. Activation Data Generation and Installation (p. 53)
- 6.4.2. Activation Data Protection (p. 53)
- 6.4.3. Other Aspects of Activation Data (p. 53)
- 6.5. COMPUTER SECURITY CONTROLS (p. 53)
- 6.5.1. Specific Computer Security Technical Requirements (p. 53)
- 6.5.2. Computer Security Rating (p. 54)
- 6.6. LIFE CYCLE TECHNICAL CONTROLS (p. 54)
- 6.6.1. System Development Controls (p. 54)
- 6.6.2. Security Management Controls (p. 54)
- 6.6.3. Life Cycle Security Controls (p. 54)
- 6.7. NETWORK SECURITY CONTROLS (p. 54)
- 6.8. TIME-STAMPING (p. 56)
- 7. CERTIFICATE, CRL, AND OCSP PROFILES (p. 56)
- 7.1. CERTIFICATE PROFILE (p. 56)

<!-- PDF page 9 -->
- 7.1.1. Version Number(s) (p. 56)
- 7.1.2. Certificate Extensions (p. 56)
- 7.1.3. Algorithm Object Identifiers (p. 56)
- 7.1.4. Name Forms (p. 56)
- 7.1.4.1. Name Encoding (p. 56)
- 7.1.4.2. Subject Information - Subscriber Certificates (p. 57)
- 7.1.4.3. Subject Information – CA Certificates (p. 57)
- 7.1.5. Name Constraints (p. 58)
- 7.1.6. Certificate Policy Object Identifier (p. 58)
- 7.1.7. Usage of Policy Constraints Extension (p. 58)
- 7.1.8. Policy Qualifiers Syntax and Semantics (p. 58)
- 7.1.9. Processing Semantics for the Critical Certificate Policies Extension (p. 58)
- 7.2. CRL PROFILE (p. 58)
- 7.2.1. Version number(s) (p. 58)
- 7.2.2. CRL and CRL Entry Extensions (p. 58)
- 7.3. OCSP PROFILE (p. 59)
- 7.3.1. Version Number(s) (p. 59)
- 7.3.2. OCSP Extensions (p. 59)
- 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS (p. 60)
- 8.1. FREQUENCY OR CIRCUMSTANCES OF ASSESSMENT (p. 60)
- 8.2. IDENTITY/QUALIFICATIONS OF ASSESSOR (p. 60)
- 8.3. ASSESSOR’S RELATIONSHIP TO ASSESSED ENTITY (p. 60)
- 8.4. TOPICS COVERED BY ASSESSMENT (p. 60)
- 8.5. ACTIONS TAKEN AS A RESULT OF DEFICIENCY (p. 61)
- 8.6. COMMUNICATION OF RESULTS (p. 61)
- 8.7. SELF-AUDITS (p. 61)
- 9. OTHER BUSINESS AND LEGAL MATTERS (p. 62)
- 9.1. FEES (p. 62)
- 9.1.1. Certificate Issuance or Renewal Fees (p. 62)
- 9.1.2. Certificate Access Fees (p. 62)
- 9.1.3. Revocation or Status Information Access Fees (p. 62)
- 9.1.4. Fees for Other Services (p. 62)
- 9.1.5. Refund Policy (p. 62)
- 9.2. FINANCIAL RESPONSIBILITY (p. 62)
- 9.2.1. Insurance Coverage (p. 62)
- 9.2.2. Other Assets (p. 62)
- 9.2.3. Insurance or Warranty Coverage for End-Entities (p. 62)
- 9.3. CONFIDENTIALITY OF BUSINESS INFORMATION (p. 62)
- 9.3.1. Scope of Confidential Information (p. 63)
- 9.3.2. Information Not Within the Scope of Confidential Information (p. 63)
- 9.3.3. Responsibility to Protect Confidential Information (p. 63)
- 9.4. PRIVACY OF PERSONAL INFORMATION (p. 64)
- 9.4.1. Privacy Plan (p. 64)

<!-- PDF page 10 -->
- 9.4.2. Information Treated as Private (p. 64)
- 9.4.3. Information Not Deemed Private (p. 64)
- 9.4.4. Responsibility to Protect Private Information (p. 64)
- 9.4.5. Notice and Consent to Use Private Information (p. 64)
- 9.4.6. Disclosure Pursuant to Judicial or Administrative Process (p. 64)
- 9.4.7. Other Information Disclosure Circumstances (p. 65)
- 9.5. INTELLECTUAL PROPERTY RIGHTS (p. 65)
- 9.5.1. Property Rights in Certificates and Revocation Information (p. 65)
- 9.5.2. Property Rights in the Agreement (p. 65)
- 9.5.3. Property Rights of Names (p. 65)
- 9.5.4. Property Rights in Key Pairs (p. 65)
- 9.6. REPRESENTATIONS AND WARRANTIES (p. 65)
- 9.6.1. CA Representations and Warranties (p. 65)
- 9.6.2. RA Representations and Warranties (p. 66)
- 9.6.3. Subscriber Representations and Warranties (p. 66)
- 9.6.4. Relying Party Representations and Warranties (p. 68)
- 9.6.5. Representations and Warranties of Other Participants (p. 68)
- 9.7. DISCLAIMERS OF WARRANTIES (p. 68)
- 9.8. LIMITATIONS OF LIABILITY (p. 68)
- 9.9. INDEMNITIES (p. 69)
- 9.10. TERM AND TERMINATION (p. 69)
- 9.10.1. Term (p. 69)
- 9.10.2. Termination (p. 69)
- 9.10.3. Effect of Termination and Survival (p. 69)
- 9.11. INDIVIDUAL NOTICES AND COMMUNICATIONS WITH PARTICIPANTS (p. 70)
- 9.12. AMENDMENTS (p. 70)
- 9.12.1. Procedure for Amendment (p. 70)
- 9.12.2. Notification Mechanism and Period (p. 71)
- 9.12.3. Circumstances under which OID Must Be Changed (p. 71)
- 9.13. DISPUTE RESOLUTION PROVISIONS (p. 71)
- 9.14. GOVERNING LAW (p. 71)
- 9.15. COMPLIANCE WITH APPLICABLE LAW (p. 71)
- 9.16. MISCELLANEOUS PROVISIONS (p. 71)
- 9.16.1. Entire Agreement (p. 71)
- 9.16.2. Assignment (p. 71)
- 9.16.3. Severability (p. 72)
- 9.16.4. Enforcement (Attorneys' fees and waiver of rights) (p. 72)
- 9.16.5. Force Majeure (p. 72)
- 9.17. OTHER PROVISIONS (p. 72)
- Appendix A. Certificate Profiles (p. 73)

<!-- PDF page 11 -->

## 1. INTRODUCTION

### 1.1. OVERVIEW

The MOIS SSL certificate infrastructure has been established as a PKI system dedicated to issuing TLS Certificates (hereinafter “GSSL Certificate” in abbreviation of “Government SSL Certificate”) by the Ministry of the Interior and Safety(hereinafter “the MOIS”) in order to provide integrity and confidentiality for e-government and public electronic services. This document defines certification policy and operational management procedures employed in certification authority services provided by the MOIS.

This document is structured in accordance with the Internet Engineering Task Force (IETF) standard RFC 3647, and the Certificate Authority issuing GSSL Certificate conforms to the current version of “Baseline Requirements for the Issuance and Management of Publicly‐Trusted TLS Server Certificate” published by CA/Browser Forum at http://www.cabforum.org. In the event of any inconsistency between this document and the TLS Baseline Requirements, the TLS Baseline Requirements take precedence over this document.

This document has been prepared in accordance with RFC 3647, Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework. The Certification Authority (CA) responsible for issuing Government SSL (GSSL) certificates of the Ministry of the Interior and Safety shall comply with the latest published version of the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates.

In addition, the CA shall comply with the latest publicly available versions of the CCADB Policy and the Chrome Root Program Policy, and shall comply

<!-- PDF page 12 -->

with the requirements of the Apple Root Program Policy, the Mozilla Root Store Policy, and the Microsoft Root Program Requirements applicable to the GSSL Certificate hierarchy.

In the event of any conflict or inconsistency between this CP/CPS and the applicable CA/Browser Forum Baseline Requirements, Root Program Policies, or CCADB policies, such applicable requirements and policies shall take precedence over this CP/CPS.

### 1.2. DOCUMENT NAME AND IDENTIFICATION

This document is Certificate Policy/Certification Practice Statement(CP/CPS) which describes the policies on the operation and management of the GSSL Root Certification Authority(hereinafter “GSSL Root CA”) and GSSL Certification Authority (hereinafter “GSSL Sub CA” and, together with Root CA, “GSSL CA”). In detail, it specifies the legal, and technical requirements of certification services that include approval, issuance, renewal, re-key, management, use, validation, and revocation of Certificates, for relying parties and subscribers.

### 1.3. PKI PARTICIPANTS

#### 1.3.1. Certification Authorities

The Root CA performs the following tasks:

- Validation of certificate authorities

- Revision of Certificate Policy/Certification Practice Statement(CP/CPS), Terms of Use, and Privacy Policy

- Issuance, renewal and revocation of certificates, and publication of Authority Revocation List(ARL)

- Validation of Certificate issued by root certification authority

- Safe storage and management of records related to certification tasks

- Inspection of CA operations to ensure safety and reliability of

<!-- PDF page 13 -->

certification tasks

- Public disclosure of subordinate CA certificates capable of issuing publicly trusted certificates in the Common CA Database (CCADB), and maintenance of associated CA information in a current and accurate state in accordance with the applicable CCADB Policy and applicable Root Store policies

The CA performs the following tasks:

- Issuance, renewal and revocation of subscriber certificates, and publication of Certification Revocation List(CRL)

- Validation of certificates issued by the CA

- Safe storage and management of records related to certification tasks

- Inspection of CA operations to ensure safety and reliability of certification tasks

#### 1.3.2. Registration Authorities

The Registration Authority (RA) refers to entities that approve and perform requests to issue, renew, reissue, and revoke subscriber certificates. The GSSL CA, as the RA, authenticate identities of applicant representatives and/or applicants requesting certificates and validate the submitted application information but does not operate any external RA.

#### 1.3.3. Subscribers

Subscribers are authorized governmental/public organization to use Subscriber Certificates issued by the GSSL CA. According to section 3.2, he/she must agree to the responsibilities and obligations described in the Terms of Use prior to issuing the Certificate in order to use the Certificate.

#### 1.3.4. Relying Parties

A relying party is an entity that verifies a digital signature with a certificate issued by GSSL CA or decrypts an encrypted document/message

<!-- PDF page 14 -->

with a certificate issued by GSSL CA.

#### 1.3.5. Other Participants

##### 1.3.5.1. The Ministry of the Interior and Safety (The MOIS)

The MOIS is the policy supervisory Ministry for the safe and reliable operation of the GSSL CA and is charged with the following.

- Establishment and operation of the GSSL CA

- Due diligence and Request corrective actions on the GSSL CA

- Amendments of CP/CPS

##### 1.3.5.2. National Information Resources Service

The National Information Resources Service(hereinafter the "NIRS") is a national agency that operates Critical Information Infrastructure of Korean government agencies. The GSSL CA systems are delegated to NIRS and managed, and operated in accordance with the National Mission-Critical IT infrastructure operational procedures of NIRS. In regard to certification service management duties, the NIRS takes charge of physical security for the certification system, access control and approval for the system.

##### 1.3.5.3. Korea Local Information Research & Development Institute

The Korea Local Information Research & Development Institute (hereinafter the “KLID”) is the authorized public entity entrusted with the operation of the GSSL Root CA and GSSL CA by the Minister of the MOIS. The GSSL Center is the dedicated organization which belongs to KLID to directly operate the GSSL CA. The GSSL Center(hereinafter the “Center”) performs the following.

- Issuance and management of CA Certificates

<!-- PDF page 15 -->

- Establishment of standards for facilities and equipment of CA

- Inspection of the safe operation of facilities and equipment of the CA or managerial activities corresponding thereto

- Publish CA Certificate and CRL of CA

- Archive all Certificates and CRL generated within GSSL CA.

- Maintaining information and records related to the management of CA.

- Training related to certification tasks for all personnel included in the GSSL chain of operations

- Other duties deemed necessary in connection with or to certification duties

### 1.4. CERTIFICATE USAGE

#### 1.4.1. Appropriate Certificate Uses

Certificates issued in accordance with this CP/CPS are used for the purposes of Server Authentication as defined in the Extended Key Usage field. The GSSL CA issues organization validated (OV) certificates.

#### 1.4.2. Prohibited Certificate Uses

Certificates are prohibited from the uses that are inconsistent with the scope and purpose for which it was issued. In addition, the use of terminated or revoked Certificates is prohibited. The certificate does not ensure the reliability, compliance, and safety of transaction, and only proves that the information in the certificate has been accurately validated at the time of certificate issuance. Subscriber Certificates uses are restricted to the encryption of the information exchange between end-entity browsers and the Subscriber's website which has been validated in accordance with section 3.2, section 4.2.

### 1.5. POLICY ADMINISTRATION

#### 1.5.1. Organization Administering the Document

The MOIS establishes the CP/CPS and amends the CP/CPS at least once a year to maintain its consistency with the latest requirements of the CA/Browser Forum.

<!-- PDF page 16 -->

#### 1.5.2. Contact Person

Contact details GSSL for requesting certificate revocation, reporting suspected key damage, misuse of certificates, or any other matter related to certificates are the following:

- Tel: +82 1661-9088(Ext. 2)

- Fax: +82 02)2031-9363

- URL: ssl.gpki.go.kr

- Email: gssl@klid.or.kr

- Address: 301, Seongam-ro, Mapo-gu, Seoul, Republic of Korea (03923)

#### 1.5.3. Person Determining CPS Suitability for the Policy

The MOIS minister is responsible for establishment and amendment of the CP/CPS. The amendment records in document history of the CP/CPS include the version of the CP/CPS, reason for change, etc.

#### 1.5.4. CPS Approval Procedures

The GSSL CA shall revise the CP/CPS with the approval of the MOIS upon technical or procedural changes. Any changes are disclosed at the location described in section 2. In case of a possibility of a significant impact on the subscriber due to the amendment, the subscriber may be notified.

### 1.6. DEFINITIONS AND ACRONYMS

#### 1.6.1. Definitions

- Applicant : Refers to a institution, or organization that has applied for a certificate to obtain a GSSL Certificate.

- Applicant Representative : Refers to an personnel representing an Applicant for the issuance of a GSSL Certificate.

- CA/Browser Forum : Refers to a voluntary group of certificate authorities (CAs), vendors of internet browser software, and suppliers of other applications that use X.509 digital certificates for TLS and code signing.

<!-- PDF page 17 -->

- Certification : Refers to the action that validates the GSSL Certificate key being the only key belonging to the Subscriber.

- Certification Authority(CA) : Refers to a trusted authority that issues digital signature Certificates, periodically issues a Certificate Revocation List(CRL), and is responsible for certification tasks such as posting the Certificate Authority(CA) Certificate and Certificate Revocation List(CRL) on the website.

- Certificate Revocation List(CRL) : Refers to a list of Certificates that lost Certificate validity, and means electronic information periodically issued by Certification Authority(CA).

- Certification tasks : Refers to the task of managing Certificates and records related to certification, such as Certificate issuance, renewal, revocation, Subscriber information registration, change, a notice of the Certificate, Certificate Revocation List(CRL), etc.

- Certificate Transparency: Refers to an Internet security standard that allows all certificates to be recorded and identified in the public log system to monitor and audit the issuance of Certificates.

- Cryptographically Secure Pseudo-Random Number Generator(CSPRNG) : A random number generator intended for use in cryptographic system.

- Distinguished Name(DN) : Refers to a unique name given to clearly distinguish a subscriber object.

- GSSL Certificate: Refers to electronic information issued to corporations, authorities, and organizations which belongs to the 9 of Article 2 of the Electronic Government Act and is used for encryption and decryption to safely protect information transmitted between electronic government websites and user browsers.

- GSSL Certificate Generation Key(Private Key) : Refers to electronic information held by subscribers and used to generate a GSSL Certificate.

- GSSL Certificate Validation Key(Public Key) : Refers to electronic information included in the Certificate and used to validate the GSSL Certificate.

- Hash function : Refers to a function that is mapping any length of the

<!-- PDF page 18 -->

character string to the fixed length of the binary character string. It produces results with methods of cutting and substituting data or changing the position and these results are called hash values. A hash function is one of the important functions applied in the integrity, certification, and non-repudiation of data.

- Internet Corporation for Assigned Name and Numbers(ICANN) : Refers to the organization established in 1998, composed of Internet business, technical, academic, and user organizations. It plays a role in coordinating tasks such as IP address space allocation, protocol parameter specification, and root server system management.

- National Intelligence Service : The Chief Management/Control Authority in national Cyber Security in South Korean governmental/public information systems.

- Object Identifier(OID) : Refers to the basic information of GSSL Certificates such as the Subscriber (DN), issuer, version, and etc. Additionally, it includes details like the algorithm, certificate policy, key usage, and certificate properties. The information represented by these details is referred to as an "object." The method used to assign a unique number to each object, ensuring no overlap, is called an Object Identifier (OID)"

- Online Certificate Status Protocol(OCSP) : Refers to the protocol that is used to verify the Certificate status in real time without obtaining Certificate Revocation List(CRL).

- Subject : Refers to the unique name of the owner written in the certificate.

- Subscriber : Refers to an organization or a group receiving a Certificate issued by a Certification Authority(CA).

- OV certificate: TLS certificate issued through verification of both identity and domain ownership of the applicant, and the verified information is displayed on the certificate so that can confirm the ownership of the site.

#### 1.6.2. Acronyms

<!-- PDF page 19 -->

- ARL: Authority Revocation List

- CA: Certificate Authority or Certification Authority

- CAA: Certification Authority Authorization

- CABF: CA/Browser Forum

- CPS: Certification Practice Statement

- CP: Certificate Policy

- CRL: Certificate Revocation List

- CSR: Certificate Signing Request

- CT: Certificate Transparency

- DN: Distinguished Name

- DNS: Domain Name System or Domain Name Service

- FIPS: (US Government) Federal Information Processing Standard

- FQDN: Fully Qualified Domain Name

- HSM: Hardware Security Module

- HTTP: Hypertext Transfer Protocol

- ICANN: Internet Corporation for Assigned Names and Numbers

- IETF: Internet Engineering Task Force

- NIS: National Intelligence Service

- NTP: Network Time Protocol

- OCSP: Online Certificate Status Protocol

- OID: Object Identifier

- OV: Organization Validation

- PKCS: Public Key Cryptography Standard

- PKI: Public Key Infrastructure

- PKIX: IETF Working Group on Public Key Infrastructure

- RA: Registration Authority

- RFC: Request for Comments (IETF.org)

- SCT: Signed Certificate Timestamp

- SHA: Secure Hashing Algorithm

- SSL: Secure Sockets Layer

- TLS: Transport Layer Security

- URL: Uniform Resource Locator

- UTC: Coordinated Universal Time

<!-- PDF page 20 -->

## 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES

The GSSL CA records and keeps the document history of the CP/CPS and links to all historic versions on its website.

### 2.1. REPOSITORIES

The GSSL CA makes the following information accessible via the online repository including GSSL CA CP/CPS.

- GSSL CA CP/CPS

- Most recently issued certificate revocation list(CRL)

- Most recently issued CA certificate revocation list(ARL)

- Root CAs and CA certificates issued by GSSL CA

- Other documents or information deemed necessary for the disclosure

The GSSL CA publishes the amended CP/CPS in the online repository within seven (7) days after the CP/CPS amendment.

### 2.2. PUBLICATION OF CERTIFICATION INFORMATION

The GSSL CA makes the Certificate issuance and management information accessible via the website for everyone with ease.

- Website: ssl.gpki.go.kr

- Email: gssl@klid.or.kr

- By Mail address to :301, Seongam-ro, Mapo-gu, Seoul, Republic of Korea (03923)

- Tel: +82 1661-9088(Ext. 2)

- Fax: +82 02)2031-9363

### 2.3. TIME OR FREQUENCY OF PUBLICATION

The CRL of the Subscriber Certificate is updated daily basis, and the CA CRL(ARL) of the CA certificate is updated at least every 364 days. The GSSL CA shall amend the CP/CPS at least once a year in accordance with the

<!-- PDF page 21 -->

latest CA/Browser Forum(CABF) Baseline Requirement.

### 2.4. ACCESS CONTROLS ON REPOSITORIES

The Repository is publicly available in a read-only manner. Logical and physical controls are implemented to prevent unauthorized modification or deletion of repository entries.

## 3. IDENTIFICATION AND AUTHENTICATION

### 3.1. NAMING

The Certificate naming and Distinguished Name(hereinafter the "DN") conform with ITU X.509 standard. For internationalized domain names, the value encoded by Punycode algorithm shall be listed in the SubjectAltName extension as a Punycode(A-label) value.

#### 3.1.1. Types of Names

Subscriber OV Certificate's DN contains the following attributes.

- CN=Common Name

- O=Organization Name

- L=Locality Name

- S=State or Province

- C=Country Code

#### 3.1.2. Need for Names to be Meaningful

The GSSL CA puts meaningful names in both the subject DN and the issuer DN of Certificates which identify the subject and issuer respectively.

#### 3.1.3. Anonymity or Pseudonymity of Subscribers

The GSSL CA does not issue anonymous or pseudonymous Certificates.

#### 3.1.4. Rules for Interpreting Various Name Forms

The name forms used in basic field of Certificates are interpreted using

<!-- PDF page 22 -->

X.500 standards and ASN.1 syntax.

#### 3.1.5. Uniqueness of Names

The DN of the Certificate contains the domain name, and the uniqueness of the domain name is managed by the International Internet Address Management Organization(hereinafter the “ICANN”). The Fully Qualified Domain Name (FQDN) specified in the Subject Alternative Name is validated in accordance with section 3.2.2.4, and the serial number of the GSSL Certificate is unique and not reused.

#### 3.1.6. Recognition, Authentication, and Role of Trademarks

No stipulation.

### 3.2. INITIAL IDENTITY VALIDATION

#### 3.2.1. Method to Prove Possession of Private Key

The GSSL Root CA issues CA Certificate only to the GSSL Sub CA officially notified by the Minister of the MOIS. The CA Certificate is issued after confirming the public key of the CSR file. A certificate applicant shall prove ownership of the Private Key by providing GSSL CA with a CSR in PKCS#10 format or a cryptographically equivalent proof.

#### 3.2.2. Authentication of Organization Identity

The GSSL CA identifies and validates the applicant and every personnel, entities and domains specified in a Certificate in the following circumstances:

- During the Certificate application

- During the Certificate reissuance application

The validation of an Applicant Representative is conducted to ensure the legitimate authority to request SSL certificate issuance upon the circumstances specified in this CP/CPS. All subject information in a certificate shall conform to the requirements of this CP/CPS and be

<!-- PDF page 23 -->

validated in accordance with the procedures in this CP/CPS in order to:

- Identify the applicant and applicant representative requesting a Certificate

- Confirm the name and existence of the applicant

- Confirm presence of the applicant at the physical location(address)

- Confirm the ownership of domain names to be included in the Certificate

- Confirm whether the applicant has the authority to request a Certificate

##### 3.2.2.1. Identity

For OV Certificate application, the GSSL CA validates the identity and address of the Applicant using documentation provided by, or communication with, at least one of the following:

- A government agency in the jurisdiction of the Applicant’s legal creation, existence, or recognition

- A third party database that is periodically updated and considered a Reliable Data Source

- A site visit by the CA

Generally, the Certificate application is submitted online. When an Applicant completes and submits an online form on the official website, the GSSL CA verifies :

- The identity of the applicant and applicant representative; and

- The address of the applicant

| Identity Validation Target | Identity Validation Methods |
| --- | --- |
| Applicant Representative | ·Collect Applicant Representative information(name,<br>contact information, employment status, qualification<br>for certificate issuance) at submission and/or through<br>the Certificate application process. |
| Applicant | · The Applicant submits demonstrative information to<br>the GSSL CA (e.g., an English Certificate of<br>Business Registration issued by Home-Tax website<br>of the National Tax Service within three (3) months).<br>· Inquire and validate the information submitted by the<br>Applicant by a reliable third-party database (e.g., |

<!-- PDF page 24 -->

| 열 1 | 열 2 |
| --- | --- |
|  | validation on the Home-Tax website of the National<br>Tax Service).<br>·Validate the Applicant information (name, employment,<br>qualification, etc.) by calling the Applicant and<br>Applicant representative phone number confirmed in a<br>trusted third-party database (e.g., 114.co.kr, etc.).<br>Note: 114.co.kr is government licensed Phone Number<br>Directory service |
| Address of the Applicant | The Subject field of an OV Certificate SHALL contain<br>only validated geographic address information attributes.<br>The address information submitted by the Applicant<br>SHALL be validated by comparison with a trusted<br>third-party database. For example, the Applicant’s<br>address information may be verified using an<br>authoritative database such as the Road Name Address<br>System (juso.go.kr).<br>If an international standard or an official government<br>standard exists for address notation, such standard<br>SHALL be prioritized.<br>The general criteria used by the CA to determine the<br>address included in the Subject field of the Certificate<br>are as follows:<br><br>- Country Name(C): Use of two-letter country code<br>according to ISO 3166-1 Alpha-2<br>(If the Country Name field is present, the GSSL CA<br>blocks the proxy server to prevent Certificate<br>applications from IP addresses assigned to countries<br>other than the country where the Applicant<br>Representative is physically located.)<br><br>- State or Province(S): Use of unabbreviated,<br>subdivision names of states or provinces according<br>to ISO 3166-2<br><br>- Locality or City(L): Use of the official English name<br>of the city or town<br>In particular, if the address information validated during<br>the Applicant identity verification process is identical to<br>the address information provided in the application, the<br>Applicant address validation procedure is considered<br>complete. |

In special cases, the GSSL CA may validate the identity of the Applicant through site visit and/or face-to-face methods.

<!-- PDF page 25 -->

##### 3.2.2.2. DBA/Tradename

No stipulation.

##### 3.2.2.3. Verification of Country

See section 3.2.2.1.

##### 3.2.2.4. Validation of Domain Authorization or Control

Prior to issuing a Certificate, the CA shall validate the Applicant’s authorization to use or control over each requested Fully-Qualified Domain Name (hereinafter “FQDN”) using one of the following validation methods specified in the CA/Browser Forum TLS Baseline Requirements (hereinafter “TLS BR”). For the purposes of this section, the Applicant includes the Applicant’s Parent Company, Subsidiary Company, or Affiliate.

- DNS Change (3.2.2.4.7) or

- Agreed-Upon Change to Website - v2 (3.2.2.4.18) or

- Agreed-Upon Change to Website - ACME (3.2.2.4.19)

When performing domain validation, the CA shall select a validation method for each applied-for FQDN and then designate the applied-for FQDN, without modification, as the Authorization Domain Name (hereinafter “ADN”) to validate the Applicant’s control. This policy applies equally to all validation methods listed above.

##### 3.2.2.5. Authentication for an IP Address

The CA shall not issue Certificates containing IP addresses as identifiers in the Subject Alternative Name (SAN) extension. The CA shall not permit applications for such Certificates and shall block them at the application stage in the Certificate application system to prevent them from proceeding to subsequent Certificate issuance procedures.

<!-- PDF page 26 -->

##### 3.2.2.6. Wildcard Domain Validation

The CA shall not issue Certificates containing Wildcard Domain Names. The CA shall not permit applications for such Certificates and shall block them at the application stage in the Certificate application system to prevent them from proceeding to subsequent Certificate issuance procedures.

##### 3.2.2.7. Data Source Accuracy

All data sources are verified for reliability, accuracy, and stability from counterfeiting before being used for identification and authentication purposes. Evaluation of the data source accuracy and reliability is conducted in accordance with section 3.2.2.7 of the CA/Browser Forum Baseline Requirements.

##### 3.2.2.8. CAA Records

The GSSL CA reviews the CAA record for each dNSName in the subjectAltName extension field of the Certificate to be issued, following the procedure described in RFC 8659. The following Issuer Domain Names in CAA ‘issue’ or ‘issuewild’ records recognize that the GSSL CA can issue a Subscriber Certificate.

- ssl.gpki.go.kr

The GSSL CA documents potential issuance that was prevented by a CAA record in detail to provide feedback to the CA/Browser Forum.

##### 3.2.2.9. Multi-Perspective Issuance Corroboration(MPIC)

This CA performs the Multi-Perspective Issuance Corroboration (hereinafter “MPIC”) procedure in order to cross-validate the results of domain validation and CAA record checks performed prior to certificate issuance. This procedure is intended to strengthen protection against network layer attacks.

This CA performs the MPIC procedure to validate the following items:

- Domain Authorization or Control validation

<!-- PDF page 27 -->

- CAA (Certification Authority Authorization) record verification

When performing the above two validations, this CA may use the same set of network perspectives or different sets of network perspectives.

Validation Result Verification Responses collected from trusted network perspectives during the MPIC procedure shall provide information enabling confirmation of the following: ① The presence of the following items required according to the applied validation methods (Section 3.2.2.4 and 3.2.2.5 of this document)

- Random Value

- Request Token

- Persistent DCV TXT Record

② Whether this CA is authorized to issue a certificate for the requested domain (including verification of the CAA record of the domain)

Principles for Processing Validation Data Validation results or information obtained from one network perspective shall not be reused or cached during the validation process of another network perspective. Each network perspective shall perform validation independently, and it is not permitted for different network perspectives to use a shared DNS cache.

DNS Resolver Usage Requirements A network perspective may use a recursive DNS resolver that is not located in the same location as that network perspective. However, the following conditions shall be met: ① The DNS resolver must be located within the same Regional Internet Registry (RIR) service region as the network perspective. ② The straight-line distance between DNS resolvers used during the MPIC validation process must be at least 500 km.

<!-- PDF page 28 -->

The location of a DNS resolver shall be determined based on the following criterion:

- The point at which an unencapsulated (outbound) DNS query is first delivered to the Internet connectivity infrastructure.

Validation Retry This CA may immediately retry the MPIC procedure using the same validation method or a different validation method. However, when retrying validation, the CA shall not rely on corroboration results obtained from previous validation attempts. In addition, there is no limit on the number of validation attempts that may be performed during a specific period.

Quorum Requirements When performing the MPIC procedure, this CA applies the following quorum rules to determine the reliability of validation results.

| 열 1 | 열 2 |
| --- | --- |
| Number of distinct remote network perspectives |  |
| Acceptable | non-corroboration |
| 2 ~ 5 | 1 |
| 6 or more | 2 (planned) |

Network perspectives are considered distinct when the straight-line distance between two locations is at least 500 km. A network perspective is considered a remote network perspective if it meets the following conditions:

- It exists in a location different from the first network perspective

- It exists in a location different from other network perspectives included in the same quorum

If different sets of network perspectives are used for Domain Authorization validation and CAA Record validation, the quorum requirements must be satisfied for each validation set separately. The CAA validation result shall not be reused and shall be validated each time a certificate is issued.

<!-- PDF page 29 -->

Network Infrastructure Requirements Remote network perspectives performing the MPIC procedure shall use network infrastructure that implements measures to mitigate BGP routing incidents that may occur in the global Internet routing environment.

Examples: Internet Service Provider (ISP) networks Cloud Provider networks

Phased Implementation Schedule This CA shall implements the MPIC requirements in accordance with the phased implementation schedule specified in the CA/Browser Forum Baseline Requirements. procedure according to the following schedule. March 15, 2026 At least three (3) Remote Network Perspectives shall be used, and two or more different RIR service regions must be included. June 15, 2026 At least four (4) Remote Network Perspectives shall be used, and two or more different RIR service regions must be included. December 15, 2026 At least five (5) Remote Network Perspectives shall be used, and two or more different RIR service regions must be included. If the quorum requirements are not satisfied, the certificate shall not be issued.

#### 3.2.3. Authentication of Individual Identity

The GSSL CA does not issue Certificates to individuals.

#### 3.2.4. Non-Verified Subscriber Information

A Certificate contains only validated information; optional subfields within the Subject field must contain the validated information or leave it empty.

#### 3.2.5. Validation of Authority

<!-- PDF page 30 -->

The GSSL CA validates the authenticity of the request for a Certificate using Reliable Method of Communication. The GSSL CA uses the methods listed in section 3.2.2.1 as Reliable Method of Communication. The authority of applicant representatives to request Certificates on behalf of requesting organization is verified in accordance with section 3.2.2.1. The GSSL CA only accepts applications for Certificate issuance from applicants validated in Reliable Method of Communication.

#### 3.2.6. Criteria for Interoperation

No stipulation.

### 3.3. IDENTIFICATION AND AUTHENTICATION FOR RE-KEY REQUESTS

The GSSL CA does not provide Certificate re-key. Procedures for re-key requests are the same as for Initial Certificate applications in section 3.2.

#### 3.3.1. Identification and Authentication for Routine Re-key

See Section 3.2.2.

#### 3.3.2. Identification and Authentication for Re-key After Revocation

No stipulation.

### 3.4. IDENTIFICATION AND AUTHENTICATION FOR REVOCATION

REQUEST

A Subscriber may request Certificate revocation through the CA’s website using an ID/password or other means when the Certificate is no longer used or Key Pair compromise is suspected. Relevant web browser vendors may also request Certificate revocation if they possess evidence indicating suspected compromise.

If the CA’s or a Subscriber’s Key Pair is compromised or suspected of being compromised, the relevant CA Certificate or Subscriber Certificate may

<!-- PDF page 31 -->

be revoked in accordance with Section 4.9.1 (Circumstances for Revocation) of this CP/CPS. The CA shall notify the affected Subscriber of the Certificate revocation.

A third party may report suspected compromise or exposure of the Private Key corresponding to a Subscriber Certificate through a reporting channel designated by the CA.

Where a third party reports Private Key Compromise on the basis that it possesses the Private Key, it may demonstrate control over the Private Key by submitting a Certificate Signing Request (CSR) signed with the Private Key corresponding to the Public Key in the affected Certificate, or equivalent proof accepted by the CA.

The CA shall investigate whether Private Key Compromise has occurred by reviewing the third party’s report and the supporting evidence submitted, and shall process the report in accordance with Sections 4.9.2, 4.9.3, and 4.9.12 of this CP/CPS. If Private Key Compromise is confirmed, the Certificate revocation criteria specified in Section 4.9.1 shall apply.

## 4. CERTIFICATE LIFE CYCLE OPERATIONAL REQUIREMENTS

This section describes the Certificate application procedure, requirements for Subscribers, and other Relying Parties related to the Certificate life cycle.

- Certificate Application

- Certificate Application Processing

- Certificate Issuance

- Certificate Acceptance

- Key Pair and Certificate Usage

- Certificate Reissuance

- Certificate Revocation and Suspension

<!-- PDF page 32 -->

- Certificate Status Service

- End of Subscription

- Key Escrow and Recovery

### 4.1. CERTIFICATE APPLICATION

#### 4.1.1. Who Can Submit a Certificate Application

CA certificate issuance is requested through submission of the CA public key in the form of PKCS#10 CSR. The only organization authorized as GSSL CA operator by the Minister of the MOIS pursuant to Article 89 (1) of the Enforcement Decree of the Electronic Government Act can apply for a CA Certificate. A subscriber certificate application must be submitted in an online application form on the website of the CA. An applicant is a governmental department or public organization stipulated in Articles 2 (9) of the Electronic Government Act that applies for a certificate to obtain a GSSL Certificate. All certificate applicants are required to register as members on the website and agree to the Subscriber Agreement.

- When applying for a certificate, they must submit a English business registration certificate necessary for organization validation.

- Domain validation is performed using one of the methods specified in Section 3.2.2.4.

- Certificate requests must contain domain names to be included in the SubjectAlternativeName extension (SAN) of Certificates.

- Certificates revoked due to suspected phishing or fraud, and/or application information rejected for issuance, are stored in the internal database, which can be used to screen suspicious issuance requests.

#### 4.1.2. Enrollment Process and Responsibilities

Regarding CA certificate issuance, the GSSL Root CA verifies that the application form and procedure for the CA have been completed. The CA is then responsible for the reliability of the application.

Regarding subscriber certificate issuance, the CA confirms that an applicant

<!-- PDF page 33 -->

has completed application requirements below before issuing the Certificate.

- Submission of electronic certificate application form

- An agreement to Terms of Use

- Submission of the supporting documents specified in application form

- Generation of key pair and CSR using secure tool

- Submission of CSR containing the public key

### 4.2. CERTIFICATE APPLICATION PROCESSING

The CA shall verify the accuracy of the information submitted by the Applicant Organization. The Applicant Organization shall submit its Public Key to the CA in the form of a PKCS#10 Certificate Signing Request (CSR).

The CA shall perform fresh domain ownership or control validation (DCV) for each Certificate issuance and shall not reuse domain validation results obtained during a previous Certificate issuance process.

#### 4.2.1. Performing Identification and Authentication Functions

Identification and authentication of the information submitted by the Applicant are performed in accordance with the procedures specified in section 3.2.

#### 4.2.2. Approval or Rejection of Certificate Applications

The GSSL CA approves the Certificate request once the validation of the application information is completed. The GSSL CA rejects the certificate request if any of the following conditions apply:

- The application information is not validated

- The request does not comply with the CP/CPS

- The Public key does not meet requirements set forth in sections 6.1.5, 6.1.6 of CA/Browser Forum Baseline Requirements

- The Private key is weak (such as Debian weak key, see https://wiki.debian.org/SSLkeys)

#### 4.2.3. Time to Process Certificate Applications

Unless it is specified in the contract, there is no stipulated time required to process the Certificate application, and if the application form and

<!-- PDF page 34 -->

submission documents are validated properly, the GSSL CA issues the Certificate within about 30 days from applying for the Certificate.

### 4.3. CERTIFICATE ISSUANCE

Certificates issued by the GSSL CA shall include the following information in accordance with the latest CA/Browser Forum Baseline Requirements:

- Distinguished domain Names

- Certificate validation key (public key)

- A serial number of the Certificate - All Certificates must contain a serial number greater than zero, a number of no less than 64 bits of output from a CSPRNG.

- Reference Table for Maximum Validity Periods of Subscriber Certificates

| Subscriber Certificate Issuance Date | Maximum Validity Period |
| --- | --- |
| Before March 15, 2026 | MUST NOT exceed 397 days |
| On or after March 15, 2026 and before March 15, 2027 | MUST NOT exceed 200 days |
| On or after March 15, 2027 and before March 15, 2029 | MUST NOT exceed 100 days |
| On or after March 15, 2029 | MUST NOT exceed 47 days |

- Contents concerning restrictions on the scope or purpose of use of a certificate

Before issuing a Subscriber Certificate, the CA obtains Subscriber Agreement or a Terms of Use according to section 9.6.3 of the CA/Browser Forum Baseline Requirements.

#### 4.3.1. CA Actions during Certificate Issuance

Regarding Certificate Issuance by GSSL Root CA, it is required for an authorized CA Engineer to deliberately issue a direct command in order to perform the certificate signing operation.

Regarding Subscriber certificate, once the Identification and Authentication procedures are completed in accordance with this CP/CPS, the Certificate is generated and the appropriate key usage extension field is added.

The GSSL CA performs conformance linting by linting tools prior to signing a Certificate over the pre-certificate and the issued certificate.

<!-- PDF page 35 -->

Nonconformity found in linting is logged and issuance is rejected.

In support of Certificate transparency, Subscriber Certificates submit Certificates to three (3) or more CT log to receive a Signed Certificate Timestamp(hereinafter “SCT”) and include it in Certificate's extended field.

#### 4.3.2. Notification to Subscriber by the CA of Issuance of Certificate

The GSSL CA delivers within a reasonable time after issuing certificate. As for subscriber certificate, notification is sent to the applicant via email. Subscriber can download the certificate on WebSite or get by ACME client.

### 4.4. CERTIFICATE ACCEPTANCE

#### 4.4.1. Conduct Constituting Certificate Acceptance

The CA Certificate shall be stored in a security medium and be received by the CA, and shall not be rejected unless there is a special reason. The Subscriber Certificate is downloaded by the applicant himself/herself via the website of the CA.

#### 4.4.2. Publication of the Certificate by the CA

The GSSL CA publishes the Root CA certificate and the CA certificates in the repository.

#### 4.4.3. Notification of Certificate Issuance by the CA to Other Entities

No stipulation.

### 4.5. KEY PAIR AND CERTIFICATE USAGE

#### 4.5.1. Subscriber Private Key and Certificate Usage

The Private Key of the Certificate is used only for encryption of transmission information between the validated Subscriber's website and the access browser. The GSSL CA shall require, as part of the Terms of Use, that the subscriber makes the commitments and warranties in Section 9.6.3, provision

<!-- PDF page 36 -->

2) and provision 4) in this CP/CPS.

#### 4.5.2. Relying Party Public Key and Certificate Usage

No stipulation.

### 4.6. CERTIFICATE RENEWAL

#### 4.6.1. Circumstance for Certificate Renewal

Certificate renewal refers to issuing a new Certificate with an extended expiration date without changing the same key pair and Subject information. The CA Certificate may be renewed within the validity period of the Root CA Certificate, and the GSSL CA does not offer Subscriber Certificate renewal, but Subscriber Certificate renewal is not offered by. Hence, the Subscriber must apply for certificate reissuance wihtin 30 days before the certificate expires. Subscribers may request certificate for the following reasons, and the CA, upon approving the reissuance request, will issue a new certificate in accordance with section 4.1

- In the case where the certificate has expired;

- In the case where it is suspected that the Certificate Private Key has been exposed, compromised, lost, or modified; or

- In the case where the Certificate-related information has changed

#### 4.6.2. Who May Request Renewal

See section 4.1.1.

#### 4.6.3. Processing Certificate Renewal Requests

See section 4.2.

#### 4.6.4. Notification of New Certificate Issuance to Subscriber

See section 4.3.2.

#### 4.6.5. Conduct Constituting Acceptance of a Renewal Certificate

See section 4.4.1.

<!-- PDF page 37 -->

#### 4.6.6. Publication of the Renewal Certificate by the CA

See section 4.4.2.

#### 4.6.7. Notification of Certificate Issuance by the CA to Other Entities

No stipulation.

### 4.7. CERTIFICATE RE-KEY

#### 4.7.1. Circumstance for Certificate re-key

Certificate re-key means the issuance of a new Certificate with a new public key, without changing the validity period or any other information in the Certificate. The GSSL CA does not provide Certificate re-key and treats requests for certificate re-key as requests for the issuance of a new Certificate, to which section 4.1 shall apply. The GSSL CA discards the CA Certificate in the event of a disaster including compromise of the CA Certificate Private Key, and issue a new CA Certificate according to application stated in the section 4.1.

#### 4.7.2. Who May Request Certification of a New Public Key

See section 4.1.1.

#### 4.7.3. Processing Certificate re-Keying Requests

See section 4.2.

#### 4.7.4. Notification of New Certificate Issuance to Subscriber

See section 4.3.2.

#### 4.7.5. Conduct Constituting Acceptance of a re-Keyed Certificate

See section 4.4.1.

#### 4.7.6. Publication of the re-Keyed Certificate by the CA

See section 4.4.2.

<!-- PDF page 38 -->

#### 4.7.7. Notification of Certificate Issuance by the CA to Other Entities

No stipulation.

### 4.8. CERTIFICATE MODIFICATION

#### 4.8.1. Circumstances for Certificate Modification

The GSSL CA does not modify previously issued subscriber certificates. Any request for certificate modification will be treated as a request for the issuance of a new Certificate.

#### 4.8.2. Who May Request Certificate Modification

See section 4.1.1.

#### 4.8.3. Processing Certificate Modification Requests

See section 4.2.

#### 4.8.4. Notification of New Certificate Issuance to Subscriber

See section 4.3.2.

#### 4.8.5. Conduct Constituting Acceptance of a Modified Certificate

See section 4.4.1.

#### 4.8.6. Publication of the Modified Certificate by the CA

See section 4.4.2.

#### 4.8.7. Notification of Certificate Modification by the CA to Other Entities

No stipulation.

### 4.9. CERTIFICATE REVOCATION AND SUSPENSION

The GSSL CA supports Certificate revocation but does not allow temporary suspension or recovery of Certificates. When a Certificate is revoked, its corresponding certificate serial number is added to the CRL and marked

<!-- PDF page 39 -->

revoked. Responses to revocation requests and inquiries are available 24/7.

#### 4.9.1. Circumstances for Revocation

##### 4.9.1.1. Reasons for Revoking a Subscriber Certificate

The GSSL CA revokes the Subscriber Certificate within 24 hours under the following circumstances:

- A Subscriber submits a written request to the CA for certificate revocation;

- The Subscriber notifies the GSSL CA that the original certificate request was unauthorized and does not retroactively grant authorization;

- The GSSL CA obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate, has been compromised;

- The GSSL CA obtains evidence that the validation of domain authorization or control for any Fully-Qualified Domain Name or IP address in the Certificate should not be trusted.

- The GSSL CA becomes aware of a proven method that can easily compute the Subscriber's private key corresponding to the public key of the Certificate (e.g., refer to https://wiki.debian.org/SSLkeys for the Debian vulnerable key)

The GSSL CA revokes the Subscriber Certificate within five (5) days under the following circumstances:

- The Certificate no longer complies with the requirements of Section 6.1.5 and Section 6.1.6;

- The GSSL CA obtains evidence that the Certificate was misused;

- The GSSL CA becomes aware that a Subscriber has violated one or more of its material obligations under the Terms of Use;

- The GSSL CA becomes aware of any circumstance indicating that use of a Fully‐Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a

<!-- PDF page 40 -->

Domain Name Registrant’s right to use the Domain Name, a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated, or the Domain Name Registrant has failed to renew the Domain Name);

- The GSSL CA becomes aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully‐ Qualified Domain Name;

- The GSSL CA becomes aware of a material change in the information contained in the Certificate;

- The GSSL CA becomes aware that the Certificate was not issued in accordance with these Requirements or the GSSL CA’s CP/CPS;

- The GSSL CA determines or becomes aware that any of the information shown in the Certificate is inaccurate;

- The GSSL CA’s right to issue Certificates under these Requirements may expire, be revoked, or terminated unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository;

- Revocation is required by the GSSL CA’s CP/CPS; or

- The GSSL CA becomes aware of a demonstrated or proven method that exposes the Subscriber’s Private Key to compromise, or there is clear evidence that the specific method used to generate the Private Key was flawed.

##### 4.9.1.2. Reasons for Revoking a Subordinate CA Certificate

The GSSL CA revokes the CA Certificate within seven (7) days under following circumstances:

- The Subordinate CA submits a written request to the GSSL CA for CA Certificate revocation;

- The GSSL Sub CA notifies the GSSL CA that the original certificate request was unauthorized and does not retroactively grant authorization;

- The GSSL CA obtains evidence that the Subordinate CA’s Private Key corresponding to the Public Key in the Certificate, has been

<!-- PDF page 41 -->

compromised or no longer complies with the requirements of Section 6.1.5 and Section 6.1.6;

- The GSSL CA obtains evidence that the Certificate was misused;

- The GSSL CA becomes aware that the Certificate was not issued in accordance with or that Subordinate CA has not complied with this document or the applicable CP/CPS;

- The GSSL CA determines that any of the information shown in the Certificate is inaccurate or misleading;
- The GSSL CA or Subordinate CA ceases operations for any reason and has not made arrangements for another CA to provide revocation support for the Certificate;
- The GSSL CA’s or Subordinate CA’s right to issue Certificates under these Requirements may expire, be revoked, or terminated unless the GSSL CA has made arrangements to continue maintaining the CRL/OCSP Repository; or

- Revocation is required by the GSSL CA’s CP/CPS.

#### 4.9.2. Who Can Request Revocation

Revocation of a CA Certificate may be requested by an organization to which the Minister of the Interior and Safety has entrusted certification operations. Revocation of a Subscriber Certificate may be requested by the responsible personnel of an Applicant Organization meeting the criteria in Section 4.1.1 (Certificate Application Criteria). A Subscriber possessing evidence indicating suspected Key Compromise shall also request revocation. A third party may report suspected compromise of the Private Key corresponding to a Subscriber Certificate to the CA in accordance with Sections 3.4 and 4.9.12.

#### 4.9.3. Procedure for Revocation Request

The GSSL CA revokes of the CA Certificate in accordance with the procedures below when the revocation requirements meet the section 4.9.1.

1. Report immediately to related authorities including the MOIS and the

National Intelligence Service(NIS), and send an official letter of revocation of the CA Certificate.

<!-- PDF page 42 -->

2. When the CA Certificate is revoked, the CA CRL(ARL) is updated and

the relevant authority is notified if necessary.

Subscriber Certificate revocation is processed according to the following procedure.

1. GSSL CA logs the identity of the requester who has filed the

revocation of Certificate and the reason of reqeuest according to section 3.4. GSSL CA may include its own reasons in the log.

2. GSSL CA may request confirmation of certificate revocation from the

requester, where applicable, via out-of-band communication (e.g. telephone, fax, e-mail etc.).

3. If request is confirmed as originated from GSSL Sub CA or the

Subscriber, the Certificate is revoked immediately.

4. If a third party reports suspected compromise of the Private Key

corresponding to a Subscriber Certificate, the CA shall process the report in accordance with the verification procedure specified in Section 4.9.12. If the Private Key corresponding to the Certificate is determined to have been compromised in accordance with Section 4.9.12, the CA shall revoke the Certificate within 24 hours after receipt of the report.

5. If GSSL CA determines that revocation is appropriate, GSSL CA

revokes the Certificate and update the CRL.

GSSL CA maintains capabilities to receive Certificate revocation requests and Certificate Problem Reports 24/7.

#### 4.9.4. Revocation Request Grace Period

Subscribers are required to 24 hours suspend usage of Certificate Generation Key(Private Key) and Certificate and request revocation to GSSL Center in the following cases:

1. When the Certificate Generation Key(Private Key) is considered to be

lost, damaged, stolen or leaked

2. Inaccurate or incomplete information of the Certificate 3. Expiration or revocation of the Certificate

<!-- PDF page 43 -->

4. Modification of information of the Certificate

#### 4.9.5. Time within which CA Must Process the Revocation Request

Requests for CA certificate revocation from the GSSL CA is processed within seven (7) days of receipt, and the CA CRL(ARL) is published in the public repository. Regarding Subscriber Certificate revocation process, the GSSL CA initiates revocation procedure immediately after receiving the request. After the revocation of the Certificate, the reflection of revocation to the CRL shall not exceed 24 hours. The GSSL CA investigates the facts and circumstances associated with the report and provides a preliminary report on its findings to the Subscriber or the entity that filed the problem report within 24 hours of after receiving the Certificate Problem Report. After the review of facts and circumstances, the GSSL CA cooperates with subscriber and entity, who reported the Certificate Problem Report or other revocation-related notices, to determine whether the Certificate shall be revoked or not. If revocation is required, the set time for the certificate revocation is within 24 hours.The period from receipt of the Certificate issue report or notice related to the revocation to the revocation of the Certificate shall not exceed the period specified in section 4.9.1.1, 4.9.1.2. The date of revocation selected by GSSL CA considers the following criteria.

- The nature of the alleged problem (scope, context, severity, magnitude, risk of harm);

- The consequences of revocation (direct and collateral impacts to Subscribers and Relying Parties);

- The number of Certificate Problem Reports received about a particular Certificate or Subscriber;

- The report of complaints (for example, a complaint from a law enforcement official that a Web site is engaged in illegal activities should carry more weight than a complaint from a consumer alleging that they didn’t receive the goods they ordered); and

- Relevant legislation.

#### 4.9.6. Revocation Checking Requirement for Relying Parties

<!-- PDF page 44 -->

Relying Parties are required to confirm the validity of each Certificate in the certificate chain by checking CRL or OCSP responder before relying on a GSSL Certificate.

#### 4.9.7. CRL Issuance Frequency

The CA Certificate CRL(ARL) is updated at least every 364 days and within 24 hours after the CA certificate is revoked, and the value of the nextUpdate field does not exceed 12 months over the value of the thisUpdate field. The Subscriber CRL is updated at least every day, and the value of the nextUpdate field does not exceed 10 days over the value of the thisUpdate field.

#### 4.9.8. Maximum Latency for CRLs

The CA Certificate CRL(ARL) and Subscriber Certificate CRL are posted to the repository within one hour from generation.

#### 4.9.9. On-line Revocation/Status Checking Availability

The GSSL CA supports Online Certificate Status Protocol(hereinafter the “OCSP”) in issuing CA and Subscriber Certificates. OCSP addresses are:

- CA Certificate's OCSP : http://ocsp-rca-ssl.gpki.go.kr

- Subscriber Certificate's OCSP : http://ocsp-ca-ssl.gpki.go.kr

OCSP responses comply with RFC 6960. The GSSL CA issues a separate Certificate for signing OCSP responses. An OCSP Certificate signed by a CA contains an extension of the id-pkix-ocsp-nocheck type as defined in RFC 6960.

#### 4.9.10. On-line Revocation Checking Requirements

The validity interval of OCSP response messages must be greater than or equal to eight (8) hours and less than or equal to ten (10) days. If the validity interval is less than 16 hours, the information must be updated prior to one‐half of the validity period before the nextUpdate. If the validity interval is greater than or equal to 16 hours, the information is updated at least eight (8) hours prior to the nextUpdate and no later than four (4) days after the thisUpdate. An OCSP responder uses the HTTP GET method for

<!-- PDF page 45 -->

requesting OCSP and receiving it. As for the CA Certificate, the OCSP response message should be updated at least every 12 months, and within 24 hours after the CA Certificate is revoked.

#### 4.9.11. Other Forms of Revocation Advertisements Available

No stipulation.

#### 4.9.12. Special Requirements Regarding Key Compromise

If the CA’s Private Key is compromised or suspected of being compromised, the CA shall take action in accordance with applicable laws and regulations and incident response procedures. If the Private Key corresponding to a Subscriber’s Certificate is compromised or suspected of being compromised, the Subscriber shall notify the CA without delay and request Certificate revocation. Subscribers, Relying Parties, and other third parties may report suspected Private Key Compromise to the CA or submit relevant evidence.

Private Key Compromise may be demonstrated by a Certificate Signing Request (CSR) or digital signature data signed with the Private Key, verifiable security incident or vulnerability information, or other evidence that the CA can objectively verify. The CA shall determine whether Private Key Compromise has occurred by examining the CSR signature, whether the Public Key matches, and the validity and reliability of the submitted evidence.

Reports of Private Key Compromise shall be received through the channels specified in Section 1.5.2, and the CA shall process such reports in accordance with Sections 4.9.3 and 4.9.5. If Private Key Compromise is demonstrated, the CA shall revoke the Certificate in accordance with Section 4.9.1.1.

#### 4.9.13. Circumstances for Suspension

No stipulation.

<!-- PDF page 46 -->

#### 4.9.14. Who Can Request Suspension

No stipulation.

#### 4.9.15. Procedure for Suspension Request

No stipulation.

#### 4.9.16. Limits on Suspension Period

No stipulation.

### 4.10. CERTIFICATE STATUS SERVICES

#### 4.10.1. Operational Characteristics

CRL or OCSP operates to respond within 10 seconds. Revocation entries on a CRL or OCSP responses must not be removed until after the expiry date of the revoked Certificate.

#### 4.10.2. Service Availability

The CRL and OCSP services of all unexpired certificates issued by the CA is available online 24/7, unless it is terporarily unavailable due to maintenance or service failure.

#### 4.10.3. Optional Features

No stipulation.

### 4.11. END OF SUBSCRIPTION

A Subscriber's use of the certification services terminates when the Subscriber Certificate is revoked, or when the Certificate expires and no new Certificate is issued or reissued thereafter.

The reasons for Certificate revocation and the procedures for requesting and processing revocation shall be governed by Section 4.9 of this CP/CPS.

### 4.12. KEY ESCROW AND RECOVERY

No stipulation.

<!-- PDF page 47 -->

#### 4.12.1. Key Escrow and Recovery Policy and Practices

No stipulation.

#### 4.12.2. Session Key Encapsulation and Recovery Policy and Practices

No stipulation.

## 5. FACILITY, MANAGEMENT AND OPERATIONAL CONTROLS

### 5.1. PHYSICAL CONTROLS

The GSSL CA facility is protected from physical threats such as intrusion or unauthorized access. Critical CA system tasks are performed in a physically secure zone with more than four (4) security layers, and physically separated from other systems to prevent non-authorized access.

#### 5.1.1. Site Location and Construction

The GSSL CA system is located in the Critical Information Infrastructure facility designated by the government and performs physical access control according to the national management regulations. Physical barriers (e.g., 3.0 T or more steel) are in place to shield electromagnetic wave emissions caused from system operation (e.g., key generation or authentication of CA Certificates) related to the Root CA.

#### 5.1.2. Physical Access

An access control system is operated to control access to the control area by 2-Factor authentication (fingerprint recognition, vein recognition, etc.), and access rights are periodically reviewed. When entering the security area where CA system is placed, the access date and time is recorded for audit trailing, and activities within the area are monitored by CCTV.

#### 5.1.3. Power and Air Conditioning

The GSSL CA operates an uninterruptable power supply(UPS) to protect CA facility against blackouts and other electrical anomalies. Cables in the CA facility that support power, communication, data transmission, or CA

<!-- PDF page 48 -->

services are protected from being blocked or damaged. The GSSL CA installs and operates an air conditioning system to maintain constant temperature and humidity.

#### 5.1.4. Water Exposures

The CA facilities are equipped with flood control facilities.

#### 5.1.5. Fire Prevention and Protection

The CA facility is operated in a place equipped with fire detectors, portable fire extinguishers, and automatic fire extinguishing facilities in compliance with fire extinguishing regulations.

#### 5.1.6. Media Storage

The GSSL CA controls physical access by keeping storage and recording media used for the CA service in a fireproof safe. All equipment containing storage media(fixed and removable disks) should be examined prior to disposal to ensure it does not contain any sensitive data. Storage media containing sensitive data shall be reinitialized using methods to make existing data unrecoverable before disposal or reuse.

#### 5.1.7. Waste Disposal

The GSSL CA performs processing according to the internal procedures or complete destruction in disposing of any media storing keys, activation data, or sensitive files.

#### 5.1.8. Off-site Backup

The GSSL CA performs remote backup for the CA service. The backup site maintains a level of security and control equivalent to the site where the main facility is installed.

### 5.2. PROCEDURAL CONTROLS

#### 5.2.1. Trusted Roles

The operation manager designates and approves the Trusted Roles based on

<!-- PDF page 49 -->

the principle of least privilege. The list of designated Trusted Roles is reviewed and updated at least once a year. For the security and reliability of the operation of the CA system, the roles listed below are separated, and there is no conflict of interest for each person. Trusted Roles are defined as follows.

- Management Manager : In charge of the overall CA tasks and approval of policies.

- Policy Administrator : In charge of policy establishment and amendment and performing training

- Security Manager: In charge of CA system security management

- Internal Auditor : In charge of CA system audit log review.

- Key Manager : In charge of key generation, transfer, and destruction procedures.

- Key Shareholder : In charge of performing M of N procedures during the key generation/transfer/destruction procedures.

- Fireproof safe Manager : In charge of HSM and backup management(fireproof safe at Main CA facility), remote backup management(DR facility)

- CA system Administrator: In charge of Certificate management(CA), Certificate Lifecycle, CRL, Administrator Certificate Management
- CA system Operator: In charge of server/DB/network Operation

- Subscriber Application Validator: In charge of validating and obtaining the application and identification documents regarding the Applicant Representative and domain validation.

- CA System Developer : In charge of Source code development and maintenance.

#### 5.2.2. Number of Persons Required per Task

Physical access to the CA’s secure room SHALL be performed with the simultaneous presence of at least two authorized personnel. Key activation operations for the generation, backup, storage, and recovery of the CA’s cryptographic keys SHALL be performed in accordance with an M-of-N control procedure involving at least three authorized personnel.

#### 5.2.3. Identification and Authentication for Each Role

<!-- PDF page 50 -->

Each individual in a Trusted Role uses unique credential so that his/her identity can be verified by the CA system. Multi-Factor Authentication(hereinafter the “MFA”) is applied to enter a security area and/or high-level security area.

#### 5.2.4. Roles Requiring Separation of Duties

Responsibilities and tasks assigned to each individual in a Trusted Role is documented. In addition, the duties of the each individual in a Trusted Role must be separated based at the security-related aspects of the functions to be performed. Security Manager and internal auditors cannot take other Trusted Roles. Management manager and policy administrator do not perform CA system operation, Certificate management, or registration management roles.

### 5.3. PERSONNEL CONTROLS

The R&R(responsibilities and roles) assigned to the Trusted Role is documented, and separation of duties for the Trusted Role is implemented based on security concerns of the function to be performed.

#### 5.3.1. Qualifications, Experience, and Clearance Requirements

Operating personnel is required to acquire IT-related qualifications recognized by the government or have work experience equivalent to them. Prior to participate in the Certificate management as an employee, representative, or independent contractor, the CA validates the identity and authenticity. The CA evaluates personnel assigned to the Trusted Roles, and shall be able to meet the performance requirement in his/her duties.

#### 5.3.2. Background Check Procedures

Operating personnel is required to pass national background check. All employees must wear an identifiable identification card.

#### 5.3.3. Training Requirements

All personnel performing certification tasks must complete security

<!-- PDF page 51 -->

regulations, internal management procedures, and technical training necessary to his/her duties. The contents of training are as follows.

- Information security (laws, regulations, manuals, etc.) and personal data protection training, etc.

- CA Operation procedures and roles and responsibilities of each person in charge

- TLS technology and training on the latest certification trend, etc.

- Training on the identity verification procedure and method for the person in charge

#### 5.3.4. Retraining Frequency and Requirements

Personnel performing certification tasks complete security and related technical training every year.

#### 5.3.5. Job Rotation Frequency and Sequence

No stipulation.

#### 5.3.6. Sanctions for Unauthorized Actions

Personnel who engage in unauthorized actions are disciplined in accordance with relevant regulations and laws.

#### 5.3.7. Independent Contractor Requirements

No stipulation.

#### 5.3.8. Documentation Supplied to Personnel

Personnel in trusted roles are provided with the internal documents necessary to perform their task.

<!-- PDF page 52 -->

### 5.4. AUDIT LOGGING PROCEDURES

Audit logging is implemented to monitor, detect, and report configuration changes related to the security of a CA system in a security support system under the control of a CA or a trusted third-party.

#### 5.4.1. Types of Events Recorded

The CA system records the following events on the CA system and applications, and generates and records the certificate management log from collected data according to internal audit procedures. 1. CA and Key life cycle Management Records

- Key generation, backup, storage recovery, migration, transfer, storage, and destruction

- Certificate request, renewal, and revocation

- Approval and rejection of Certificate requests

- Cryptographic device life cycle management history

- Creation of CRL and OCSP entries

- Creation of a new Certificate profile and revocation of Certificate profiles

2. Subscriber Certificate life cycle Management Records

- Certificate request and revocation

- All verification activities specified in CA/Browser Forum Baseline Requirements and CA’s CP/CPS

- Approval and rejection of Certificate requests

- Certificate issuance

- Creation of CRL and OCSP entries

- Multi-Perspective Issuance Corroboration(MPIC) Records

- Records of Multi-Perspective Issuance Corroboration attempts performed from each network perspective during the domain validation and CAA verification processes

- An identifier that uniquely identifies the network perspective used in the validation attempt

- The domain name that was the subject of the validation attempt

<!-- PDF page 53 -->

- The result of each validation attempt(e.g., domain validtation success/failure, CAA issuance permitted/prohibited)

- The quorum result of the Multi-Perspective Issuance Corroboration process performed for each domain name included in the certificate request

3. Security records

- Success and failure of CA system access attempts

- Record of works related to CA and security system

- Change security settings

- Software installation, update, and removal for CA system

- System crashes, hardware failures, and other anomalies

- Firewall and router logs

- CA facility access record 4. All log records include:

- Log date and time

- ID of the subject generating the log
- Description of the log

#### 5.4.2. Frequency of Processing Log

The log is reviewed once a month by a log auditor, and the log related to the CA key life cycle is reviewed on a quarterly basis.

#### 5.4.3. Retention Period for Audit Log

Logs are retained for two (2) years depending on the type of log defined in consideration of storage space availability and management efficiency.

#### 5.4.4. Protection of Audit Log

The GSSL CA implements procedures to safely protect stored data from threats including unauthorized modification and/or compromise of the integrity of the log until the audit log retention period expires.

- Only CA system Administrator and internal auditors have rights to access audit logs

- Modification or deletion of the audit logs is not allowed

#### 5.4.5. Audit Log Backup Procedures

<!-- PDF page 54 -->

Logs shall be backed up in real-time, and a copy of the logs is stored in a safe off-site location.

#### 5.4.6. Audit Collection System (Internal vs. External)

Audit collection system is operated directly by the CA.

#### 5.4.7. Notification to Event-causing Subject

The GSSL CA system is monitored by automated methods such as log analysis and event notification to notify important security events to operating personnel.

#### 5.4.8. Vulnerability Assessments

The GSSL CA continuously monitors external and internal vulnerabilities, identifies the scope of risk assessment, and performs the following risk assessments at least every year on a regular basis. When performing vulnerability assessment and penetration testing on the CA system and infrastructure, external personnel should be hired for independency and objectivity.

- Identify foreseeable internal and external threats that could lead to unauthorized access, disclosure, misuse, alteration, or destruction of Certificate data or Certificate management processes

- Evaluate the adequacy of policies, procedures, information systems, and technologies prepared by the CA to respond to these threats

For public and private IP addresses used in the CA system, a vulnerability scan shall be performed as follows.

- At least every three (3) months

- Within one (1) week after receiving the request from CA/Browser Forum

- When changing the system or network that the CA determines to be critical

The GSSL CA executes measures within 96 hours of a discovery of critical vulnerabilities with high risk. If not possible, the GSSL CA establishes action plan and countermeasures to mitigate vulnerabilities.

### 5.5. RECORDS ARCHIVAL

<!-- PDF page 55 -->

#### 5.5.1. Types of Records Archived

As for the records to be archived, refer to items specified in section 5.4.1.

#### 5.5.2. Retention Period for Archive

The GSSL CA retains all documents related to certificate requests, certificate issuance and certificate revocation for at least two (2) years after the certificates become invalid or revoked.

#### 5.5.3. Protection of Archive

The GSSL CA manages backups archived at a distinct and separate location to prevent unauthorized changes, leakage, and destruction.

#### 5.5.4. Archive Backup Procedures

The backup archives are utilized in the occurrence of loss or destruction of information in accordance with the backup and recovery procedures.

#### 5.5.5. Requirements for Time-stamping of Records

All archived records are time-stamped using NTP(Network Time Protocol).

#### 5.5.6. Archive Collection System (Internal or External)

No stipulation.

#### 5.5.7. Procedures to Obtain and Verify Archive Information

Information related to the CA system is requested through an official document in the name of the requesting organization after prior consultation with the GSSL CA. The GSSL CA replies to the request via an official document.

### 5.6. KEY CHANGEOVER

In case of CA key expiration or compromise, the procedure for providing a new CA certificate to a subject following a re-key is the same as the procedure for initially providing the CA certificate.

<!-- PDF page 56 -->

### 5.7. COMPROMISE AND DISASTER RECOVERY

#### 5.7.1. Incident and Compromise Handling Procedures

The GSSL CA maintains controls to provide reasonable assurance that damage caused by security failures and malfunctions can be minimized through incident reporting and response procedures. In preparation for disaster, security failure, or business failure, the GSSL CA documents the business continuity and disaster recovery procedures to notify and protect affected Subscribers and Relying Parties. Procedures shall be in place to transfer relevant archival records to the responsible person. The business continuity plan is not subject to external disclosure. However, the internal auditor of the GSSL CA has rights to access the business continuity plan and security plan upon request. The GSSL CA annually reviews and updates the business continuity plan, and conducts disaster recovery exercise according to the business continuity plan. The items to be included in the business continuity plan are as follows.

1. The conditions for activating the plan; 2. Emergency procedures; 3. Fallback procedures; 4. Resumption procedures; 5. A maintenance schedule for the plan; 6. Awareness and education requirements; 7. The responsibilities of involved individuals; 8. Recovery time objective (RTO); 9. Regular testing of contingency plans; 10. A plan to maintain or restore the CA’s business operations in a timely manner following interruption to or failure of critical business processes; 11. A requirement to store critical cryptographic materials (i.e., secure cryptographic device and activation materials) at an alternate location; 12. A definition of acceptable system outage and recovery times;

<!-- PDF page 57 -->

13. The frequency at which backup copies of essential business information and software are made; 14. The distance between CA sites; and 15. Procedures for securing an affected facility following a disaster and prior to restoring it either at the original or a different location.

The GSSL CA maintains documented procedures for the identification, assessment, reporting, and management of reportable incidents affecting publicly trusted certificate operations.

Where applicable, reportable incidents are disclosed, updated, and managed in accordance with the CCADB Incident Reporting Guidelines and applicable Root Store policies. The GSSL CA ensures that reportable incidents are evaluated for timely public disclosure and appropriate corrective actions.

The CA shall establish and maintain a comprehensive and actionable mass Certificate revocation response and testing plan to address mass Certificate revocation events.

The CA shall annually test, review, and update the plan and procedures, and shall incorporate lessons learned and improvements identified through testing and actual incidents into the plan to continually improve its response capabilities. The contents and testing of the plan shall be governed by Section 5.7.5 of this CP/CPS.

#### 5.7.2. Computing Resources, Software, and/or Data are Corrupted

The GSSL CA uses archived data for recovery when the critical data of the CA system are compromised or destroyed.

#### 5.7.3. Entity Private Key Compromise Procedures

If the GSSL CA has recognized that private key of subscriber used in the certification service is not secure, it revokes those certificates containing public keys corresponding. If the subscribers want to re-issue certificates,

<!-- PDF page 58 -->

they should apply certificates with new key pairs. Once a Root CA or CA private key is compromised, the GSSL CA informs browser vendors of the compromise and best estimate of the date of compromise by our business continuity plan.

#### 5.7.4. Business Continuity Capabilities after a Disaster

According to the national business continuity guidance, the GSSL CA establishes and implements a business continuity plan to prevent certificate life cycle tasks and CA facilities from being interrupted by disasters such as failures, terrorism, power outages, earthquakes, fires, storms, floods, etc.

#### 5.7.5. Mass Certificate Revocation Response and Testing Plan

The GSSL CA establishes and maintains a Mass Revocation Incident Preparation and Testing Plan, and shall conduct at least one simulation exercise per year.

The CA shall document the mass Certificate revocation response and testing plan specified in Section 5.7.1 and include the following:

1. Specific, objective, and measurable criteria for activating the plan. 2. Storage, maintenance, and updating of Subscriber contact information. 3. Processes that are automated, processes that can be automated, and

processes requiring manual intervention.

4. Targets and timelines for initial incident assessment, revocation

initiation, Certificate replacement, and post-event review.

5. Methods for notifying affected Subscribers. 6. Roles and responsibilities of personnel responsible for initiating,

coordinating, and executing the plan.

7. Education and training for responsible personnel and support

personnel.

8. Methods for annual operational testing and assessment of

implementation feasibility.

9. Procedures for incorporating lessons learned from testing and actual

<!-- PDF page 59 -->

incidents, and the frequency of plan review and updating.

Testing shall use one or more of tabletop exercises, simulations, parallel testing, or controlled test environments, and shall be conducted without actually revoking active Subscriber Certificates.

### 5.8. CA OR RA TERMINATION

When a CA terminates operations, the GSSL CA provides notice and takes the following measures to minimize the impact of the termination.

- If a successor CA is designated, records related to service and operation are handed over

- Preserving all records described in this CP/CPS for a minimum of one (1) year

- Revoking all Certificates issued by the CA no later than at the time of termination

## 6. TECHNICAL SECURITY CONTROLS

### 6.1. KEY PAIR GENERATION AND INSTALLATION

#### 6.1.1. Key Pair Generation

The CA key is generated inside a HSM certified FIPS 140-2 Level 3 or higher. The generated private key cannot be extracted outside the HSM except for the purposes permitted by the GSSL CA. The Subscriber key pair is generated by the Subscriber. Requests for Subscriber Certificates are rejected if the Public Key does not meet the requirements in Sections 6.1.5 and 6.1.6 or if it has a Private Key that is known to be weak. At least three (3) of the designated personnel participate in key pair generation ceremonies of RootCA or CA and perform the task in the presence of internal or external auditors.

#### 6.1.2. Private Key Delivery to Subscriber

The GSSL CA does not generate or archive Subscriber key pairs.

<!-- PDF page 60 -->

#### 6.1.3. Public Key Delivery to Certificate Issuer

When issuing a CA Certificate, the CA submits a request for signing a CSR in PKCS#10 format to the GSSL Root CA. Subscribers submit a CSR in PKCS#10 format to the GSSL CA via the official website to which the TLS certificate is applied.

#### 6.1.4. CA Public Key Delivery to Relying Parties

The CA public key is electronically signed by the GSSL Root CA. The GSSL CA provides chain validation procedures for Subscriber Certificates by posting Certificates of the Root CA and CA on the website.

#### 6.1.5. Key Sizes

The certificates must meet the following requirements for algorithm type and key size. The Root CA Certificate, CA Certificate, and Subscriber Certificate must all meet the same requirements.

- Digest Algorithms : SHA-256, SHA-384 or SHA-512

- Minimum RSA Module Size (Unit: bits)

- Root CA Certificate : 4096

- CA Certificate : 3072

- Subscriber Certificate : 2048

#### 6.1.6. Public Key Parameters Generation and Quality Checking

In the case of the RSA key, the GSSL CA confirms that the public exponent of the RSA key is an odd number equal to three (3) or more.

#### 6.1.7. Key Usage Purposes(as per X.509 v3 Key Usage Field)

The cases where the Root CA private key is used to sign a Certificate are as follows.

- Self-signed Certificates to represent the Root CA itself

- CA Certificate

- Certificates for infrastructure purposes (e.g., Certificates for CA administrator, Certificates for internal CA operation devices, etc.)

- OCSP Response Verification Certificates

<!-- PDF page 61 -->

### 6.2. PRIVATE KEY PROTECTION AND CRYPTOGRAPHIC MODULE

ENGINEERING CONTROLS

#### 6.2.1. Cryptographic Module Standards and Controls

The GSSL CA key pairs are backed up and operated in HSM certified FIPS 140-2 Level 3 or higher.

#### 6.2.2. Private Key (n out of m) Multi-person Control

The GSSL CA generates the CA key pair in accordance with an internal key generation procedure. At least three (3) of the five (5) designated personnel participate in key pair generation ceremonies.

#### 6.2.3. Private Key Escrow

The GSSL CA does not escrow the CA key pair to a third-party.

#### 6.2.4. Private Key Backup

The Root CA private key and CA private key is backed up and stored in a secure location according to the backup procedure. The backed-up private key is stored in a HSM and safely stored in a fireproof safe.

#### 6.2.5. Private Key Archival

The GSSL CA does not separately archive CA private keys.

#### 6.2.6. Private Key Transfer into or from a Cryptographic Module

The Root CA private key and CA private key may be extracted according to a secure procedure specified by the HSM vendor under GSSL CA's approval for backup and recovery purposes.

#### 6.2.7. Private Key Storage on Cryptographic Module

The private key of the GSSL CA is created and stored in the HSM that meets the requirements of section 6.2.1 of this CP/CPS.

#### 6.2.8. Method of Activating Private Key

The Root CA private key and CA private key stored in the HSM can be activated by multiple controls according to the procedure specified by the HSM vendor under the approval of the GSSL CA.

<!-- PDF page 62 -->

#### 6.2.9. Method of Deactivating Private Key

The Root CA private key and CA private key stored in the HSM can be deactivated by multiple controls according to the procedure specified by the HSM vendor under the approval of the GSSL CA.

#### 6.2.10. Method of Destroying Private Key

GSSL CA may destroy CA private keys for the following reasons.

- the Root CA or CA Certificate expired

- In case where there is a possibility that the private key of the CA has been compromised, leaked, or damaged

The GSSL CA can delete the private key stored in HSM by destroying the private key. Additionally, the GSSL CA can destroy backup tokens by zeroization of HSM according to the HSM specification. If zeroization or initialization fails, the equipment can be physically destroyed in a manner of removing the ability to extract the private keys.

#### 6.2.11. Cryptographic Module Rating

A HSM that meets the requirements of section 6.2.1 must be used.

### 6.3. OTHER ASPECTS OF KEY PAIR MANAGEMENT

#### 6.3.1. Public Key Archival

CA and Subscriber Certificates are archived in accordance with backup procedures.

#### 6.3.2. Certificate Operational Periods and Key Pair Usage Periods

Certificates validity expires at the end of the validity period specified in the Certificate field. The maximum validity period of the issued Subscriber Certificate SHALL comply with Section 4.3(Certificate Issuance).

### 6.4. ACTIVATION DATA

Hardware security module (HSM) activation key is stored in corresponding HSM and can be used by key administrators authorized by the GSSL CA. Module activation for using a key pair in a HSM is performed according to a

<!-- PDF page 63 -->

multiple controls procedure implemented with equipment that requires physical access control.

#### 6.4.1. Activation Data Generation and Installation

Activation data is generated according to the specification of the HSM. This hardware security module is required to be certified for FIPS 140-2 Level 3.

#### 6.4.2. Activation Data Protection

The procedure used to activate the HSM data depends on the HSM keypad(hereinafter the “PED”) and the access authentication key. The access authentication key is managed by a designated multiple controls procedure, and the PED is managed by a key manager.

#### 6.4.3. Other Aspects of Activation Data

No stipulation.

### 6.5. COMPUTER SECURITY CONTROLS

#### 6.5.1. Specific Computer Security Technical Requirements

Information of the GSSL CA system is protected protected through a combination of server/OS control, physical control, and network control. Network security controls are specified in section 6.7. Multi-factor authentication is implemented for all accounts used for the lifecycle management of the certificates issued by the GSSL CA system.

- Permit access to authorized personnel to manage the CA system and ask for the responsibility for the CA system security

- Review all accounts in the system at least every three (3) months and deactivate the accounts that are no longer necessary for operation

- Restrict the access for a certain period if access attempts to the CA system fail more than five (5) times

- Retrieve the user's authority to the CA system within 24 hours once the job role changes or contract expires

- Apply MFA to all the CA systems that can be accessed from the security zone (including accounts that approve the equally applied to

<!-- PDF page 64 -->

delegated third-parties for Certificate issuance)

- Apply Logout or session timeout when the workstation is no longer in use by the CA system-related administrator, operator, or person in charge

- Apply recommended security patch to the CA system within six months since its provided unless there is an evidence stating that the security patch causes additional vulnerabilities or instability outweighs the benefit of the security patch application

#### 6.5.2. Computer Security Rating

No stipulation.

### 6.6. LIFE CYCLE TECHNICAL CONTROLS

#### 6.6.1. System Development Controls

Actions on the Certification system such as function changes and performance improvement are carried out under approval of the governing organization.

#### 6.6.2. Security Management Controls

Seperation of duties and least privilege principle must be applied to all computers that have access to the GSSL CA system. Access rights are given under approval of the CA, and immediately withdrawn upon termination of duties.

#### 6.6.3. Life Cycle Security Controls

No stipulation.

### 6.7. NETWORK SECURITY CONTROLS

The GSSL CA system is protected in accordance with the CA/Browser Forum's Network and Certificate System Security Requirements, and includes the following controls:

1. Segment Certificate Systems into networks based on their functional or

logical relationship

2. Apply equivalent security controls to all systems located in the same area

with the CA system

<!-- PDF page 65 -->

3. Maintain Root CA Systems in a High Security Zone and in an offline

state or air‐gapped from all other networks

4. Maintain and protect Issuing Systems, Certificate Management Systems,

and Security Support Systems in at least a Secure Zone

5. Implement and configure Security Support Systems that protect systems

and communications between systems inside Secure Zones and High Security Zones, and communications with non‐Certificate Systems outside those zones and those on public networks

6. Configure each network boundary control (firewall, switch, router,

gateway, or other network control device or system) with rules that support only the services, protocols, ports, and communications that the GSSL CA has identified as necessary to its operations

7. Remove or disable all accounts, applications, services, protocols, and ports

that are not used by the CA, and allow only the accounts, applications, services, protocols, and ports authorized by the CA

8. Ensure that the CA’s security policies encompass a change management

process, following the principles of documentation, approval and review, and to ensure that all changes to GSSL CA systems

9. Grant administration access to Certificate Systems only to persons acting

in Trusted Roles and require their accountability for the Certificate System’s security

10. Implement Multi‐Factor Authentication to each component of the

Certificate System that supports Multi‐Factor Authentication

11. Change authentication keys and passwords for any privileged account or

service account on a Certificate System whenever a person’s authorization to administratively access that account on the Certificate System is changed or revoked

12. Apply recommended security patches to Certificate Systems within six

(6) months of the security patch’s availability, unless the CA documents that the security patch would introduce additional vulnerabilities or instabilities that outweigh the benefits of applying the security patch.

<!-- PDF page 66 -->

### 6.8. TIME-STAMPING

The audit logs created by the certificates, CRL, and other certificate life cycles contain time information. The GSSL CA uses the NTP to synchronize system clocks at least once every eight (8) hours and all times are updated to the Universal Time Coordinated(hereinafter the “UTC”) time zone.

## 7. CERTIFICATE, CRL, AND OCSP PROFILES

### 7.1. CERTIFICATE PROFILE

Certificates issued by the GSSL CA conform to both RFC 5280 and the latest CA/Browser Forum Baseline Requirements. If the stipulations of RFC 5280 and CA/Browser Forum Baseline Requirements are different, the CA/Browser Forum Baseline Requirements take precedence.

When issuing a new TLS Subordinate CA Certificate, the Certificate shall comply with the certificate profile requirements of the CA/Browser Forum Baseline Requirements and the applicable Root Program policies in effect at the time of issuance and the time of disclosure in the CCADB.

#### 7.1.1. Version Number(s)

CA and Subscriber Certificates issued by the GSSL CA are based on X.509 Version 3.

#### 7.1.2. Certificate Extensions

The Certificate issued by the GSSL CA uses the Certificate extension field specified in the “Appendix A. Certificate Profiles” and complies with CA/Browser Forum Baseline Requirements section 7.1.2 and technical standard RFC 5280.

#### 7.1.3. Algorithm Object Identifiers

Certificate Algorithm OID uses the OID specified in the “Appendix A.

<!-- PDF page 67 -->

Certificate Profiles”.

#### 7.1.4. Name Forms

##### 7.1.4.1. Name Encoding

The encoded value of the Issuer DN field of all Certificates except for the Root CA Certificate must match the encoded value of the Subject DN field of the CA that issued the Certificate.

##### 7.1.4.2. Subject Information - Subscriber Certificates

By issuing the Certificate, the GSSL CA represents that it has conformed with the procedure specified in this CP/CPS to verify that all subject information is accurate as of the Certificate's issuance date. The GSSL CA verifies Certificate request information by comparison with a trusted third-party database. The GSSL Certificate does not include a domain name in the Subject field, except as specified in section 3.2.2.4. The GSSL Certificate only contains information that is verified according to section 3.2 and does not include information that is not verified. The subject:organizationName, subject:localityName and subject:countryName attributes are verified according to section 3.2.2.1. The Subject attribute cannot use metadata such as ‘.’, ‘-’and ‘ ’ (i.e. space) characters by itself, and no other indications may be used if the value is missing, incomplete, or No stipulation. The GSSL CA will not issue Certificates containing reserved IP addresses or internal names in subjectAlternativeName field or subject:commonName attribute. Entries in dNSName must not contain the underscore character (‘_’) as they must be in the “Preferred name syntax” specified in RFC 5280.

##### 7.1.4.3. Subject Information – CA Certificates

The GSSL CA complies with the CP/CPS and the CA/Browser Forum Baseline Requirements to ensure that all subject information is accurate as of the date of issuance of the Certificate. The subject:commonName attribute may be used as an identifier for the CA Certificate. The subject:commonName attribute of the GSSL CA Certificate must be unique.

<!-- PDF page 68 -->

The GSSL Certificate includes the name of the CA in the subject:organizationName attribute. If it is a locally accepted abbreviation, it may contain somewhat different information, such as a verified name and a general variant or abbreviation. For example, if the official name is “Company Name Incorporated”, the GSSL CA may use “Company Name Inc.” or “Company Name”. The subject:countryName property contains the ISO 3166-1 country code identified in accordance with section 3.2.2.1.

#### 7.1.5. Name Constraints

No stipulation.

#### 7.1.6. Certificate Policy Object Identifier

The certificates issued under GSSL CA use this CP/CPS as a certificate policy, and the related policy identifiers are as follows.

- Subscriber OV Certificate : 1.2.410.100001.100.1.2.2

- OCSP Certificate : 1.2.410.100001.100.1.3.2

The following policy identifiers assigned by the CA/Browser Forum are also used for Subscriber Certificates.

- OV Certificate : {joint-iso-itu-t(2) international-organizations (23) ca-browser-forum(140) certificate-policies(1) baseline- requirements(2) organization-validated(2)} (2.23.140.1.2.2)

#### 7.1.7. Usage of Policy Constraints Extension

No stipulation.

#### 7.1.8. Policy Qualifiers Syntax and Semantics

No stipulation.

#### 7.1.9. Processing Semantics for the Critical Certificate Policies Extension

No stipulation.

7.2 CRL PROFILE CRLs issued by the GSSL CA comply with the RFC 5280 standard.

<!-- PDF page 69 -->

#### 7.2.1. Version Number(s)

All CRLs are issued as X.509 V2.

#### 7.2.2. CRL and CRL Entry Extensions

- CRL Number : Use repeated monotonically increasing integer
- Authority Key Identifier : Same as the Subject Key Identifier of the Certificate
- Validity Date : UTC format (Optional)
- Reason Code : Reason for revocation (Optional) - keyCompromise(1) - affiliationChanged(3) - superseded(4) - cessationOfOperation(5) - privilegeWithdrawn(9)

### 7.3. OCSP PROFILE

OCSP responses conform with RFC 6960. The responses to OCSP requests are provided to the Authority Information Access via an OCSP responder URL. The OCSP responder does not respond with a “Good” for a Certificate that has not been issued. OCSP responses are signed by:

- the CA that issued the Certificates whose revocation status is being checked, or

- an OCSP Responder whose Certificate is signed by the CA that issued the Certificate whose revocation status is being checked (the OCSP signing Certificate must contain an extension of type id-pkix-ocsp-nocheck, as defined by RFC6960). If an OCSP response is for a Root CA or Subordinate CA Certificate, including Cross Certificates, and that certificate has been revoked, then the revocationReason field within the RevokedInfo of the CertStatus MUST be present.

7.3.1 Version Number(s) The GSSL CA OCSP response conforms with version 1 as defined in RFC 6960. In detail, the OCSP response may not include a random value in the response, even if the request contains a random value.

<!-- PDF page 70 -->

7.3.2 OCSP Extensions No stipulation.

## 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS

An annual audit is performed by an independent external auditor to assess compliance of GSSL CA with the WebTrust for CAs criteria. The audit report must meet CA/Browser Forum Baseline Requirements section 8.6.

### 8.1. FREQUENCY OR CIRCUMSTANCES OF ASSESSMENT

The audit of the certification service is conducted at least once a year.

### 8.2. IDENTITY/QUALIFICATIONS OF ASSESSOR

Audits must be performed by a legal entity with the following qualifications and skills.

- Independence from the subject of the audit

- The capability and experience to process and audit against WebTrust or equivalent international certification audit standards

- proficiency in examining Public Key Infrastructure technology, information security tools and techniques, information technology and security auditing, and the third-party attestation function

- In case of WebTrust Audit, a person licensed by WebTrust.org (WebTrust Practitioner)

- Bound by law, government regulation, or professional code of ethics

- Auditing agencies that maintain Professional Liability/Errors & Omissions insurance with a policy limit of at least one (1) million dollars in insurance coverage, except for internal government auditing agencies

### 8.3. ASSESSOR’S RELATIONSHIP TO ASSESSED ENTITY

The auditor should not have a financial or business interest with the subject

<!-- PDF page 71 -->

of the audit.

### 8.4. TOPICS COVERED BY ASSESSMENT

Annual audits validate the GSSL CA's service in compliance with the WebTrust Audit Criteria and the CA Browser Forum Baseline Requirements.

### 8.5. ACTIONS TAKEN AS A RESULT OF DEFICIENCY

The GSSL CA take administrative and technical measures according to findings in the audit report.

### 8.6. COMMUNICATION OF RESULTS

An audit report contains the contents of the certificates issued by GSSL CA and related systems, policies, and procedures. The GSSL CA will publish the audit report on its website. The GSSL CA is not required to disclose any general audit finding that does not affect the overall audit opinion. The Audit Report contains at least the following clearly-labelled information:

- Name of the organization being audited

- The name and address of the organization performing the audit

- SHA-256 fingerprints of all Root CAs and CAs, including Cross-Certificates

- The audit criteria(including version) used to audit each Certificate and associated key

- List of policy documents referenced when performing an audit (including versions)

- Whether the audit is an evaluation of a specific period or point in time

- The start and end dates of an audit period that includes a period of time

- A point in time date for a specific point in time

- The date the report was issued (Must be after the audit end date or the designated date)

### 8.7. SELF-AUDITS

<!-- PDF page 72 -->

The GSSL CA conducts self-audits at least once in a quarter basis for compliance with the CP/CPS and CA/Browser Forum Baseline Requirements. Self-audit is conducted upon a randomly selected sample of at least three (3)% of Certificates issued since the previous self-audit.

## 9. OTHER BUSINESS AND LEGAL MATTERS

### 9.1. FEES

#### 9.1.1. Certificate Issuance or Renewal Fees

GSSL Certificate system is an information protection infrastructure operated by the government. It does not charge Subscribers for the issuance, re-key, and renewal of Certificates and other fees.

#### 9.1.2. Certificate Access Fees

No extra fee is charged.

#### 9.1.3. Revocation or Status Information Access Fees

No extra fee is charged.

#### 9.1.4. Fees for Other Services

No extra fee is charged.

#### 9.1.5. Refund Policy

No stipulation.

### 9.2. FINANCIAL RESPONSIBILITY

#### 9.2.1. Insurance Coverage

The GSSL CA does not provide any monetary indemnities for problems related to a GSSL Certificate.

#### 9.2.2. Other Assets

<!-- PDF page 73 -->

No stipulation.

#### 9.2.3. Insurance or Warranty Coverage for End-Entities

No stipulation.

### 9.3. CONFIDENTIALITY OF BUSINESS INFORMATION

The GSSL CA observes applicable regulations on the protection of personal information deemed to be the confidential information by the relevant laws and CP/CPS section 9.4.1.

#### 9.3.1. Scope of Confidential Information

The GSSL CA keeps the following types of information confidential and maintains reasonable controls to prevent the exposure of such records to non-trusted personnel. The following information is considered confidential and protected against disclosure using a reasonable degree of care:

- Certificate application records and documents

- External or internal audit trail records and reports, except for WebTrust audit reports

- Emergency plans and Disaster Recovery Plans

- Private key

- Private key activation data

- Audit logs and archival records

- Personal information

#### 9.3.2. Information Not Within the Scope of Confidential Information

Items specified in section 9.3.1 of the CP/CPS are considered confidential information, and other information is considered public information. However, the registered Certificate and revocation information is not considered confidential information. Subscribers consent that the revocation data of all GSSL Certificates are public information and are posted every 24 hours. Subscriber application information marked as “Public” in Terms of Use or application submitted as part of the Certificate application information is published within the issued Certificate, so that such

<!-- PDF page 74 -->

information does not fall within the scope of confidential information.

#### 9.3.3. Responsibility to Protect Confidential Information

Confidential information on the GSSL Certificate is safely stored and managed by authorized personnel. The executives, employees, outsourcers, and contractors are responsible for protecting confidential information and have contractual obligations. All of these people must be trained in processing confidential information.

### 9.4. PRIVACY OF PERSONAL INFORMATION

#### 9.4.1. Privacy Plan

The GSSL CA follows the Privacy Policy posted on the website when processing personal information. Personal information is only disclosed when the disclosure is required by law or when requested by the data subject of personal information.

#### 9.4.2. Information Treated as Private

Personal information is collected and held in accordance with the Privacy Policy posted on the website.

#### 9.4.3. Information Not Deemed Private

Information disclosed in Certificates, CRLs or OCSP is not deemed personal information.

#### 9.4.4. Responsibility to Protect Private Information

The GSSL CA complies with related laws and regulations, such as the Personal Information Protection Act, and collects, holds, and processes personal information in accordance with the Privacy Policy posted on the website.

#### 9.4.5. Notice and Consent to Use Private Information

The GSSL CA complies with related laws and regulations, such as the Personal Information Protection Act, notifies the use of personal

<!-- PDF page 75 -->

information, and obtains consent of a data subject through the website and application document.

#### 9.4.6. Disclosure Pursuant to Judicial or Administrative Process

The GSSL Certificate Issuing System processes personal information of data subjects only within the scope specified in Section 9.4.2, and discloses personal information to third parties only if the disclosure is required under specifications of Articles 17 and 18 of the Personal Information Protection Act, such as the consent of the data subject and special provisions of the law.

#### 9.4.7. Other Information Disclosure Circumstances

No stipulation.

### 9.5. INTELLECTUAL PROPERTY RIGHTS

All intellectual rights arising from the GSSL certification system belong to the MOIS.

#### 9.5.1. Property Rights in Certificates and Revocation Information

The MOIS reserves the right to revoke certificates at any time and is responsible for maintaining the revocation information.

#### 9.5.2. Property Rights in the Agreement

Participants in the GSSL service acknowledge that the MOIS holds all intellectual property rights to this CP/CPS.

#### 9.5.3. Property Rights of Names

The Subscriber reserves all rights to DN information, such as the authority name and domain included in the Subscriber Certificate.

#### 9.5.4. Property Rights in Key Pairs

The Subscriber reserves all rights to the Subscriber's private and public keys.

<!-- PDF page 76 -->

### 9.6. REPRESENTATIONS AND WARRANTIES

#### 9.6.1. CA Representations and Warranties

The CA shall comply with the following, and its representations and warranties shall not be limited to the following:

- Compliance with applicable domestic and foreign laws, statutes, implementing regulations, and policies. • Regular publication and updating of CRLs and OCSP responses. • Compliance with the minimum requirements specified in this CP/CPS and the CA/Browser Forum Baseline Requirements. • Maintenance of a Repository on its website.

By issuing a Certificate, the CA provides the Certificate Warranties specified in Section 9.6.1 of the CA/Browser Forum Baseline Requirements to the Certificate Beneficiaries identified in that section.

The CA represents and warrants that, during the period when the Certificate is valid, it has complied with the CA/Browser Forum Baseline Requirements and this CP/CPS in issuing and managing the Certificate.

Nothing in this section shall be construed as limiting or excluding the CA’s warranty obligations under Section 9.6.1 of the CA/Browser Forum Baseline Requirements.

#### 9.6.2. RA Representations and Warranties

No stipulation.

#### 9.6.3. Subscriber Representations and Warranties

The GSSL CA requires the Applicant Representative to make an agreement and guarantee this item for the benefit of the CA and the recipient of the Certificate as part of the Subscriber Agreement or Terms of Use. The GSSL CA collects one of the following for the explicit interests of certification agencies and Certificate recipients before issuing Certificates.

- Consent of the Applicant to the Subscriber Agreement

- Approval of the Applicant to the Terms of Use

The GSSL CA will implement a procedure to check whether the Subscriber

<!-- PDF page 77 -->

Agreement or Terms of Use are legally applicable to the Applicant. In both cases, consent applies to Certificates issued at the request of Certificates. As long as each Certificate issued by the CA to the Subscriber is clearly subject to the application of the Subscriber Agreement or Terms of Use, separate consent can be obtained for each Certificate request or processed with a single consent for multiple Certificate requests and results. The Applicant MUST follow the obligation and guarantees included in Subscriber Agreement or Terms of Use following:

- Accuracy of Information: An obligation and warranty to provide accurate and complete information at all times to the CA, both in the certificate request and as otherwise requested by the CA in connection with the issuance of the Certificate(s) to be supplied by the CA;

- Protection of Private Key: An obligation and warranty by the Applicant to take all reasonable measures to maintain sole control of, keep confidential, and properly protect at all times the Private Key that correspond to the Public Key to be included in the requested Certificate(s);

- Acceptance of Certificate: An obligation and warranty that the Subscriber will review and verify the Certificate contents for accuracy;

- Use of Certificate: An obligation and warranty to install the Certificate only on servers that are accessible at the subjectAltName(s) listed in the Certificate, and to use the Certificate solely in compliance with all applicable laws and solely in accordance with the Subscriber Agreement or Terms of Use;

- Reporting and Revocation: An obligation and warranty to: (a) promptly request revocation of the Certificate, and cease using it and its associated Private Key, if there is any actual or suspected misuse or compromise of the Subscriber's Private Key associated with the Public Key included in the Certificate, and (b) promptly request revocation of the Certificate, and cease using it, if any information in the Certificate is or becomes incorrect or inaccurate.

- Termination of Use of Certificate: An obligation and warranty to promptly cease all use of the Private Key corresponding to the Public

<!-- PDF page 78 -->

Key included in the Certificate upon revocation of that Certificate for reasons of Key Compromise.

- Responsiveness: An obligation to respond to the CA's instructions concerning key compromise or Certificate misuse within a specified time period.

- Acknowledgment and Acceptance: An acknowledgment and acceptance that the CA is entitled to revoke the certificate immediately if the Applicant were to violate the terms of the Subscriber Agreement or Terms of Use or if the CA discovers that the Certificate is being used to enable criminal activities such as phishing attacks, fraud, or the distribution of malware.

#### 9.6.4. Relying Party Representations and Warranties

No stipulation.

#### 9.6.5. Representations and Warranties of Other Participants

No stipulation.

### 9.7. DISCLAIMERS OF WARRANTIES

EXCEPT AS EXPRESSLY STATED IN THIS CP/CPS, ALL CERTIFICATES AND ANY RELATED SOFTWARE AND SERVICES ARE PROVIDED “AS IS” AND “AS AVAILABLE”. THE GSSL CA DISCLAIMS ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND ANY WARRANTY OF ACCURACY OF INFORMATION PROVIDED WITH RESPECT TO CERTIFICATES ISSUED BY THE MOIS, THE CRL, AND ANY PARTICIPANT'S OR THIRD PARTY'S PARTICIPATION IN THE MOIS PKI, INCLUDING USE OF KEY PAIRS, CERTIFICATES, THE CRL OR ANY OTHER GOODS OR SERVICES PROVIDED BY THE MOIS TO THE PARTICIPANT. EXCEPT AS EXPRESSLY STATED IN SECTION 9.6.1 OF THIS CP/CPS, THE GSSL CA DOES NOT WARRANT THAT ANY SERVICE OR PRODUCT WILL MEET ANY EXPECTATIONS OR THAT ACCESS TO CERTIFICATES WILL BE TIMELY OR ERROR‐FREE. THE GSSL CA DOES NOT GUARANTEE THE AVAILABILITY OF ANY PRODUCTS OR SERVICES AND MAY MODIFY OR

<!-- PDF page 79 -->

DISCONTINUE ANY PRODUCT OR SERVICE OFFERING AT ANY TIME. A FIDUCIARY DUTY IS NOT CREATED SIMPLY BECAUSE AN INDIVIDUAL OR ENTITY USES SERVICES OF THE MOIS.

### 9.8. LIMITATIONS OF LIABILITY

Subscriber Certificates issued by the CA shall be issued and operated in accordance with the Electronic Government Act and applicable laws and regulations.

If the CA has issued and managed a Certificate in compliance with the CA/Browser Forum Baseline Requirements and this CP/CPS, the CA may limit its liability for losses or damages arising from the use of or reliance on that Certificate to the extent provided by applicable laws and regulations and this CP/CPS.

This section does not exclude the CA’s warranty obligations under Section 9.6.1 of the CA/Browser Forum Baseline Requirements, and any limitation of the CA’s liability shall be subject to applicable laws and regulations and applicable requirements.

### 9.9. INDEMNITIES

No stipulation.

### 9.10. TERM AND TERMINATION

#### 9.10.1. Term

This CP/CPS is effective once it is published to the online repository.

#### 9.10.2. Termination

The CP/CPS and any related policy documents remain in effect until it is replaced with a newer version.

<!-- PDF page 80 -->

#### 9.10.3. Effect of Termination and Survival

The following rights, responsibilities, and obligations survive the termination of the CP/CPS for Certificates issued under this CP/CPS.

- All responsibilities and obligations related to confidential information, including those stated in section 9.3 of the CP/CPS

- All responsibilities and obligations to protect private information, including those stated in section 9.4.4 of the CP/CPS

- All representations and warranties, including those stated in section 9.6 of the CP/CPS

- All limitations of liability are provided for in section 9.8 of the CP/CPS

Even if this CP/CPS is terminated, all Subscriber Agreements or Terms of Use remain in effect until the Certificate is revoked or expired.

### 9.11. INDIVIDUAL NOTICES AND COMMUNICATIONS WITH

PARTICIPANTS

Regarding this CP/CPS, the GSSL CA mainly communicates with entities or individuals via email. The notification is considered valid as replied via e-mail. If the sender does not receive the email reply within five (5) days, the written notice shall be submitted to the following address.

- Korea Local Information Research & Development Institute, GSSL Center

- 301, Seongam-ro, Mapo-gu, Seoul, Republic of Korea (03923)

- E-mail: gssl@klid.or.kr

### 9.12. AMENDMENTS

In the case where the MOIS makes a significant change of policy, the latest version of the CP/CPS is released using the new version number in the repository of the GSSL CA(ssl.gpki.go.kr/legal/cps). This CP/CPS is updated at least once a year. In case of minor changes or error corrections that do not affect users and Certificates, the version number of the existing CP/CPS can be maintained and modified without notifying users of the CP/CPS.

<!-- PDF page 81 -->

#### 9.12.1. Procedure for Amendment

Amendments to this CP/CPS are made with the approval of the MOIS. The MOIS approves amendments to this CP/CPS, and the GSSL CA publishes the amendments to the repository. Modifications may be updated, modified, or changed to this CP/CPS, and details are described in the CP/CPS. If there is a reason for minor changes or error corrections that are not related to the practices of the CP/CPS, it may be modified without prior approval.

#### 9.12.2. Notification Mechanism and Period

Amendments to the CP/CPS of the GSSL are posted on the online repository to notify users.

#### 9.12.3. Circumstances under which OID Must Be Changed

The MOIS is solely responsible for determining whether an amendment to the CP/CPS requires OID changes of certificate policy.

### 9.13. DISPUTE RESOLUTION PROVISIONS

To the extent permitted by applicable law, Subscriber Agreement or Terms of Use shall contain a dispute resolution clause. Disputes regarding GSSL certification system is subject to the decision of the Minister of the MOIS.

### 9.14. GOVERNING LAW

This CP/CPS is governed, construed, and interpreted in accordance with the laws of the Republic of Korea. This particular jurisdiction's choice of law applies equally to providers, vendors, beneficiaries or other contractual relationships of GSSL implicitly or explicitly applicable to Certificates and services to ensure a comprehensive interpretation of this CP/CPS regardless of location, place of use, and other products and services.

### 9.15. COMPLIANCE WITH APPLICABLE LAW

This CP/CPS is subject to the Electronic Government Act and related laws.

<!-- PDF page 82 -->

### 9.16. MISCELLANEOUS PROVISIONS

#### 9.16.1. Entire Agreement

No stipulation.

#### 9.16.2. Assignment

No stipulation.

#### 9.16.3. Severability

No stipulation.

#### 9.16.4. Enforcement (Attorney's fees and waiver of rights)

No stipulation.

#### 9.16.5. Force Majeure

No stipulation.

### 9.17. OTHER PROVISIONS

No stipulation.

<!-- PDF page 83 -->

Appendix A. Certificate Profiles 1. Root CA Certificate (Currently Operational Certificate)

| 열 1 | 열 2 | 열 3 | 열 4 |
| --- | --- | --- | --- |
| Fields | Req. | Value |  |
| Version | (0x2) | 3 (0x2) |  |
| Serial Number | CSPRNG random<br>value of more than<br>8 byte | (Required) |  |
| Signature Algorithm | SHA256 RSA | sha256WithRSAEncryption (1.2.840.113549.1.1.11) |  |
| Issuer | Equivalent to<br>Subject value | commonName = MOIS SSL Root CA<br>organizationName = Ministry of the Interior and Safety<br>countryName = KR |  |
| Validity | 20 years | (Required) |  |
| Subject | Mandatory Attributes<br>CN, O, C | commonName = MOIS SSL Root CA<br>organizationName = Ministry of the Interior and Safety<br>countryName = KR |  |
| Subject Public Key Info | RSA 4096 bit | Public Key Algorithm : rsaEncryption<br>RSA Public-Key : (4096 bit) |  |
| Subject Key Identifier | Public Key Hash<br>20 byte | non-critical | (Required) |
| Key Usage | (0x06) | critical | keyCertSign, cRLSign (0x06) |
| Basic Constraints | Fixed Value | critical | Subject Type = CA<br>Path Length Constraint = None |

2. CA Certificate (Currently Operational Certificate)

| 열 1 | 열 2 | 열 3 | 열 4 |
| --- | --- | --- | --- |
| Fields | Req. | Value |  |
| Version | (0x2) | 3 (0x2) |  |
| Serial Number | CSPRNG random<br>value of more than<br>8 byte | (Required) |  |
| Signature Algorithm | SHA256 RSA | sha256WithRSAEncryption (1.2.840.113549.1.1.11) |  |
| Issuer | Root CA<br>Subject Value | commonName = MOIS SSL Root CA<br>organizationName = Ministry of the Interior and Safety<br>countryName = KR |  |
| Validity | 10 years | (Required) |  |
| Subject | Mandatory Attributes<br>CN, O, C | commonName = MOIS SSL Server CA<br>organizationName = Ministry of the Interior and Safety<br>countryName = KR |  |
| Subject Public Key Info | RSA 3072 bit | Public Key Algorithm : rsaEncryption RSA Public-Key : (3072 bit) |  |
| Authority Key<br>Identifier | Root CA SKI Value | non-critical | (Required) |
| Subject Key Identifier | Public Key Hash | non-critical | (Required) |

<!-- PDF page 84 -->

| 열 1 | 열 2 | 열 3 | 열 4 |
| --- | --- | --- | --- |
|  | 20 byte |  |  |
| Key Usage | (0x86) | critical | keyCertSign, cRLSign, digitalSignature (0x86) |
| Basic Constraints | Fixed Value | critical | Subject Type = CA<br>Path Length Constraint = 0 |
| Certificate Policy | CPS OID and<br>URL(HTTP) | non-critical | [1]Certificate Policy: Policy<br>Identifier=anyPolicy<br>[1,1]Policy Qualifier Info:<br>Policy Qualifier Id=CPS<br>Qualifier:<br>http://ssl.gpki.go.kr/legal/cps |
| Extended Key Usage | Fixed Value | non-critical | Server Authentication (1.3.6.1.5.5.7.3.1)<br>Client Authentication (1.3.6.1.5.5.7.3.2) |
| CRL Distribution<br>Points | CRL URL<br>(HTTP) | non-critical | [1]CRL Distribution Point<br>Distribution Point Name:<br>Full Name:<br>URL=http://ssl.gpki.go.kr/arl/SSL-RootCA.crl |
| Authority Information<br>Access | Root CA Certificate<br>and OCSP URL<br>(HTTP) | non-critical | [1]Authority Info Access<br>Access Method=caIssuers (1.3.6.1.5.5.7.48.2)<br>Alternative Name:<br>URL=http://ssl.gpki.go.kr/certs/ssl-rootca.cer<br>[2]Authority Info Access<br>Access Method=ocsp (1.3.6.1.5.5.7.48.1)<br>Alternative Name:<br>URL=http://ocsp-rca-ssl.gpki.go.kr |

3. Organization Validation Subscriber Certificate

| Fields | Req. | Value |
| --- | --- | --- |
| Version | (0x2) | 3 (0x2) |
| Serial Number | CSPRNG random<br>value of more than<br>8 byte | (Required) |
| Signature Algorithm | SHA256 RSA | sha256WithRSAEncryption (1.2.840.113549.1.1.11) |
| Issuer | CA Subject Value | commonName = MOIS SSL Server CA<br>organizationName = Ministry of the Interior and Safety<br>countryName = KR |
| Validity | In accordance with<br>Section<br>4.3(Certificate<br>Issuance) | (Required) |
| Subject | Attributes<br>CN, O, L, S, C | commonName = (Domain Name Required)<br>organizationName = (Organization’s English Name Required)<br>locality = (City/County/District,etc. Optional) |

<!-- PDF page 85 -->

| 열 1 | 열 2 | 열 3 | 열 4 |
| --- | --- | --- | --- |
|  |  | stateOrProvince = (State/Province,etc. Required)<br>countryName = KR |  |
| Subject Public Key Info | RSA 2048 bit | Public Key Algorithm : rsaEncryption<br>RSA Public-Key : (2048 bit) |  |
| Authority Key<br>Identifier | CA SKI Value | non-critical | (Required) |
| Subject Key Identifier | Public Key Hash 20<br>byte | non-critical | (Required) |
| Key Usage | (0xA0) | critical | digitalSignature, keyEncipherment (0xA0) |
| Basic Constraints | Fixed Value | critical | Subject Type = End Entity<br>Path Length Constraint = None |
| Certificate Policy | CPS OID and<br>URL(HTTP) | non-critical | [1]Certificate Policy:<br>Policy Identifier=2.23.140.1.2.2<br>[2]Certificate Policy:<br>Policy Identifier=1.2.410.100001.100.1.2.2 |
| Subject Alternative Name | FQDN | non-critical | (Case1: for single domain)<br>DNS Name = Domain Name 1<br>or<br>(Case2: for multiple domain)<br>DNS Name = Domain Name 1<br>DNS Name = Domain Name 2<br>DNS Name = Domain Name 3<br>... |
| Extended Key Usage | Fixed Value | non-critical | Server Authentication (1.3.6.1.5.5.7.3.1) |
| CRL Distribution<br>Points | CRL URL<br>(HTTP) | non-critical | [1]CRL Distribution Point<br>Distribution Point Name:<br>Full Name:<br>URL=http://ssl.gpki.go.kr/crl/ca/Crl#1p#2Dp#3.crl |
| Authority Information<br>Access | CA Certificate and<br>OCSP URL<br>(HTTP) | non-critical | [1]Authority Info Access<br>Access Method=caIssuers (1.3.6.1.5.5.7.48.2)<br>Alternative Name:<br>URL=http://ssl.gpki.go.kr/certs/ssl-ca.cer<br>[2]Authority Info Access<br>Access Method=ocsp (1.3.6.1.5.5.7.48.1)<br>Alternative Name:<br>URL=http://ocsp-ca-ssl.gpki.go.kr |
| SCT List | more than 3<br>of CT logs | non-critical | (Required) |

4. OCSP Responder Certificate Profile

<!-- PDF page 86 -->

○ CA Certificate OCSP URL : http://ocsp-rca-ssl.gpki.go.kr ○ Subscriber Certificate OCSP URL : http://ocsp-ca-ssl.gpki.go.kr

| 열 1 | 열 2 | 열 3 | 열 4 |
| --- | --- | --- | --- |
| Fields | Req. | Value |  |
| Version | (0x02) | V3 (0x02) |  |
| Serial Number | CSPRNG random<br>value of more<br>than 8 byte | (Required) |  |
| Signature<br>Algorithm | SHA256 RSA | sha256WithRSAEncryption (1.2.840.113549.1.1.11) |  |
| Issuer | Issuer Subject<br>Value | (Required) |  |
| Validity | Maximum of<br>3 years | (Required) |  |
| Subject | Required<br>Attributes<br>CN, O, C | (CA Certificate OCSP)<br>commonName = MOIS SSL CA OCSP Responder #(n)<br>(n = 1, 2, 3, ...)<br>organizationName = Ministry of the Interior and Safety<br>countryName = KR<br>(Subscriber Certificate OCSP)<br>commonName = MOIS SSL Subscriber CA OCSP Responder #(n)<br>(n = 1, 2, 3, ...)<br>organizationName = Ministry of the Interior and Safety<br>countryName = KR |  |
| Subject Public<br>Key Info | RSA 2048 bit | Public Key Algorithm : rsaEncryption<br>RSA Public-Key : (2048 bit) |  |
| Basic<br>Constraints | Fixed Value | critical | Subject Type=End Entity<br>Path Length Constraint=None |
| Subject Key<br>Identifier | Public Key<br>Hash 20 byte | non-critical | (Required) |
| Authority Key<br>Identifier | CA SKI Value | non-critical | (Required) |
| Key Usage | (0x80) | critical | Digital Signature (80) |
| Extended Key<br>Usage | Fixed Value | non-critical | OCSP Signing (1.3.6.1.5.5.7.3.9) |
| Authority<br>Information<br>Access | OCSP URL<br>(HTTP) | non-critical | (CA Certificate OCSP)<br>[1]Authority Info Access<br>Access Method=ocsp (1.3.6.1.5.5.7.48.1)<br>Alternative Name:<br>URL=http://ocsp-rca-ssl.gpki.go.kr<br>(Subscriber Certificate OCSP)<br>[1]Authority Info Access<br>Access Method=ocsp (1.3.6.1.5.5.7.48.1) |

<!-- PDF page 87 -->

| 열 1 | 열 2 | 열 3 | 열 4 |
| --- | --- | --- | --- |
|  |  |  | Alternative Name:<br>URL=http://ocsp-ca-ssl.gpki.go.kr |
| OCSP No<br>Revocation<br>Checking | Fixed Value | non-critical | id-pkix-ocsp-nocheck (1.3.6.1.5.5.7.48.1.5) |