--- title: SECOM Publicly Trusted Certificate Policy/Certification Practice Statement / SECOM パブリックトラスト証明書ポリシー/認証運用規程 subtitle: Version 1.00 author: SECOM Trust Systems Co., Ltd. / セコムトラストシステムズ株式会社 date: 2025-05-26 copyright: © 2025 SECOM Trust Systems Co., Ltd. This CP/CPS is licensed under the Creative Commons Attribution 4.0 International license. --- # Table of Contents - [Table of Contents](#table-of-contents) - 目次 - [1. INTRODUCTION](#1-introduction) - 概説 - [1.1 Overview](#11-overview) - 概要 - [1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) - 基準、評価基準および規則 - [1.2 Document name and identification](#12-document-name-and-identification) - 文書名と識別 - [1.2.1 Revisions](#121-revisions) - 改訂 - [1.3 PKI Participants](#13-pki-participants) - PKI関係者 - [1.3.1 Certification Authorities](#131-certification-authorities) - 認証局（CA） - [1.3.2 Registration Authorities](#132-registration-authorities) - 登録局（RA） - [1.3.2.1 Enterprise registration authorities (S/MIME Certificates)](#1321-enterprise-registration-authorities-smime-certificates) - Enterprise RA (S/MIME 証明書) - [1.3.3 Subscribers](#133-subscribers) - 利用者 - [1.3.4 Relying Parties](#134-relying-parties) - 検証者 - [1.3.5 Other Participants](#135-other-participants) - その他関係者 - [1.4 Certificate Usage](#14-certificate-usage) - 証明書の用途 - [1.4.1 Appropriate Certificate Uses](#141-appropriate-certificate-uses) - 適切な証明書の用途 - [1.4.2 Prohibited Certificate Uses](#142-prohibited-certificate-uses) - 禁止される証明書の用途 - [1.5 Policy administration](#15-policy-administration) - ポリシー管理 - [1.5.1 Organization Administering the Document](#151-organization-administering-the-document) - 文書を管理する組織 - [1.5.2 Contact Person](#152-contact-person) - 連絡先 - [1.5.3 Person Determining CPS suitability for the policy](#153-person-determining-cps-suitability-for-the-policy) - ポリシー適合性決定者 - [1.5.4 CPS approval procedures](#154-cps-approval-procedures) - CPS承認手続 - [1.6 Definitions and Acronyms](#16-definitions-and-acronyms) - 定義と頭字語 - [1.6.1 Definitions](#161-definitions) - 定義 - [1.6.2 Acronyms](#162-acronyms) - 頭字語 - [1.6.3 References](#163-references) - 参照 - [1.6.4 Conventions](#164-conventions) - 慣例 - [2. PUBLICATION AND REPOSITORY RESPONSIBILITIES](#2-publication-and-repository-responsibilities) - 公開およびリポジトリーに関する責任 - [2.1 Repositories](#21-repositories) - リポジトリー - [2.2 Publication of information](#22-publication-of-information) - 情報公開 - [2.3 Time or frequency of publication](#23-time-or-frequency-of-publication) - 公開時期または頻度 - [2.4 Access controls on repositories](#24-access-controls-on-repositories) - リポジトリーのアクセス管理 - [3. IDENTIFICATION AND AUTHENTICATION](#3-identification-and-authentication) - 識別と認証 - [3.1 Naming](#31-naming) - 識別名 - [3.1.1 Types of names](#311-types-of-names) - 識別名タイプ - [3.1.2 Need for names to be meaningful](#312-need-for-names-to-be-meaningful) - 識別名の意味付け - [3.1.3 Anonymity or pseudonymity of subscribers](#313-anonymity-or-pseudonymity-of-subscribers) - 利用者の匿名性または仮名性 - [3.1.4 Rules for interpreting various name forms](#314-rules-for-interpreting-various-name-forms) - 識別名の解釈規則 - [3.1.5 Uniqueness of names](#315-uniqueness-of-names) - 識別名の一意性 - [3.1.6 Recognition, authentication, and role of trademarks](#316-recognition-authentication-and-role-of-trademarks) - 商標の認識、認証および役割 - [3.2 Initial identity validation](#32-initial-identity-validation) - 初回の利用者本人確認 - [3.2.1 Method to prove possession of private key](#321-method-to-prove-possession-of-private-key) - 私有鍵の所持を証明する方法 - [3.2.2 Authentication of Organization and Domain Identity](#322-authentication-of-organization-and-domain-identity) - 組織とドメインの認証 - [3.2.2.1 Identity](#3221-identity) - アイデンティティ - [3.2.2.1.1 Validating authority over mailbox via domain (S/MIME Certificates)](#32211-validating-authority-over-mailbox-via-domain-smime-certificates) - ドメイン経由のメールボックス権限検証 (S/MIME 証明書) - [3.2.2.1.2 Validating control over mailbox via email (S/MIME Certificates)](#32212-validating-control-over-mailbox-via-email-smime-certificates) - Emailによるメールボックス管理検証 (S/MIME 証明書) - [3.2.2.1.3 Validating applicant as operator of associated mail server(s) (S/MIME Certificates)](#32213-validating-applicant-as-operator-of-associated-mail-servers-smime-certificates) - 申請者が関連メールサーバーの運営者であることの検証（S/MIME証明書） - [3.2.2.2 DBA/Tradename](#3222-dbatradename) - 商号/商標名 - [3.2.2.2.1 Verification of Applicant's Legal Existence and Identity (EV TLS Server Certificates)](#32221-verification-of-applicants-legal-existence-and-identity-ev-tls-server-certificates) - 申請者の法的存在と身元の検証（EV TLSサーバー証明書） - [3.2.2.2.1.1 Verification Requirements](#322211-verification-requirements) - 検証要件 - [3.2.2.2.1.2 Acceptable Method of Verification](#322212-acceptable-method-of-verification) - 許容される検証方法 - [3.2.2.2.2 Verification of Applicant's Legal Existence and Identity – Assumed Name (EV TLS Server Certificates)](#32222-verification-of-applicants-legal-existence-and-identity--assumed-name-ev-tls-server-certificates) - 申請者の法的存在と身元の検証 - 仮名 (EV TLSサーバー証明書) - [3.2.2.2.2.1 Verification Requirements](#322221-verification-requirements) - 検証要件 - [3.2.2.2.2.2 Acceptable Method of Verification](#322222-acceptable-method-of-verification) - 許容される検証方法 - [3.2.2.2.3 Verification of Applicant's Physical Existence (EV TLS Server Certificates)](#32223-verification-of-applicants-physical-existence-ev-tls-server-certificates) - 申請者の実在検証（EV TLSサーバー証明書） - [3.2.2.2.3.1 Address of Applicant's Place of Business](#322231-address-of-applicants-place-of-business) - 申請者の事業所住所 - [3.2.2.2.4 Verified Method of Communication (EV TLS Server Certificates)](#32224-verified-method-of-communication-ev-tls-server-certificates) - 検証済み通信方法（EV TLSサーバー証明書） - [3.2.2.2.4.1 Verification Requirements](#322241-verification-requirements) - 検証要件 - [3.2.2.2.4.2 Acceptable Methods of Verification](#322242-acceptable-methods-of-verification) - 許容される検証方法 - [3.2.2.2.5 Verification of Applicant's Operational Existence (EV TLS Server Certificates)](#32225-verification-of-applicants-operational-existence-ev-tls-server-certificates) - 申請者の運用上の存在の検証（EV TLSサーバー証明書） - [3.2.2.2.5.1 Verification Requirements](#322251-verification-requirements) - 検証要件 - [3.2.2.2.5.2 Acceptable Methods of Verification](#322252-acceptable-methods-of-verification) - 許容される検証方法 - [3.2.2.2.6 Verification of Applicant's Domain Name (EV TLS Server Certificates)](#32226-verification-of-applicants-domain-name-ev-tls-server-certificates) - 申請者のドメイン名検証（EV TLSサーバー証明書） - [3.2.2.2.6.1 Verification Requirements](#322261-verification-requirements) - 検証要件 - [3.2.2.2.7 Verification of Name, Title, and Authority of Contract Signer and Certificate Approver (EV TLS Server Certificates)](#32227-verification-of-name-title-and-authority-of-contract-signer-and-certificate-approver-ev-tls-server-certificates) - 契約署名者および証明書承認者の氏名、役職、権限検証 (EV TLSサーバー証明書) - [3.2.2.2.7.1 Verification Requirements](#322271-verification-requirements) - 検証要件 - [3.2.2.2.7.2 Acceptable Methods of Verification – Name, Title and Agency](#322272-acceptable-methods-of-verification--name-title-and-agency) - 許容される検証方法 – 氏名、役職、所属組織 - [3.2.2.2.7.3 Acceptable Methods of Verification – Authority](#322273-acceptable-methods-of-verification--authority) - 許容される検証方法 – 権限 - [3.2.2.2.7.4 Pre-Authorized Certificate Approver](#322274-pre-authorized-certificate-approver) - 事前承認証明書承認者 - [3.2.2.2.8 Verification of Signature on Subscriber Agreement and EV Certificate Requests (EV TLS Server Certificates)](#32228-verification-of-signature-on-subscriber-agreement-and-ev-certificate-requests-ev-tls-server-certificates) - 利用者契約およびEV証明書申請 (EV TLSサーバー証明書) の署名検証 - [3.2.2.2.8.1 Verification Requirements](#322281-verification-requirements) - 検証要件 - [3.2.2.2.8.2 Acceptable Methods of Signature Verification](#322282-acceptable-methods-of-signature-verification) - 許容される署名検証の方法 - [3.2.2.2.9 Verification of Approval of EV Certificate Request (EV TLS Server Certificates)](#32229-verification-of-approval-of-ev-certificate-request-ev-tls-server-certificates) - EV 証明書要求の承認の検証 (EV TLSサーバー証明書) - [3.2.2.2.9.1 Verification Requirements](#322291-verification-requirements) - 検証要件 - [3.2.2.2.9.2 Acceptable Methods of Verification](#322292-acceptable-methods-of-verification) - 許容される検証方法 - [3.2.2.2.10 Verification of Certain Information Sources (EV TLS Server Certificates)](#322210-verification-of-certain-information-sources-ev-tls-server-certificates) - 特定の情報源の検証（EV TLSサーバー証明書） - [3.2.2.2.10.1 Verified Legal Opinion](#3222101-verified-legal-opinion) - 検証済み法律意見書 - [3.2.2.2.10.2 Verified Accountant Letter](#3222102-verified-accountant-letter) - 検証済み会計士確認書 - [3.2.2.2.10.3 Face-to-Face Validation](#3222103-face-to-face-validation) - 対面による検証 - [3.2.2.2.10.4 Independent Confirmation From Applicant](#3222104-independent-confirmation-from-applicant) - 申請者から独立した確認 - [3.2.2.2.10.5 Qualified Independent Information Source](#3222105-qualified-independent-information-source) - 認定独立情報源 - [3.2.2.2.10.6 Qualified Government Information Source](#3222106-qualified-government-information-source) - 認定政府情報源 - [3.2.2.2.10.7 Qualified Government Tax Information Source](#3222107-qualified-government-tax-information-source) - 認定政府税務情報源 - [3.2.2.2.11 Other Verification Requirements (EV TLS Server Certificates)](#322211-other-verification-requirements-ev-tls-server-certificates) - その他の検証要件 (EV TLSサーバー証明書) - [3.2.2.2.11.1 High Risk Status](#3222111-high-risk-status) - ハイリスクステータス - [3.2.2.2.11.2 Denied Lists and Other Legal Block Lists](#3222112-denied-lists-and-other-legal-block-lists) - 拒否リストおよびその他法的ブロックリスト - [3.2.2.2.11.3 Parent/Subsidiary/Affiliate Relationship](#3222113-parentsubsidiaryaffiliate-relationship) - 親会社/子会社/関連会社との関係 - [3.2.2.2.12 Final Cross-Correlation and Due Diligence (EV TLS Server Certificates)](#322212-final-cross-correlation-and-due-diligence-ev-tls-server-certificates) - 最終的な相互照合と適切な精査 (EV TLSサーバー証明書) - [3.2.2.2.13 Requirements for Re-use of Existing Documentation (EV TLS Server Certificates)](#322213-requirements-for-re-use-of-existing-documentation-ev-tls-server-certificates) - 既存ドキュメントの再利用に関する要件 (EV TLSサーバー証明書) - [3.2.2.2.13.1 Validation For Existing Subscribers](#3222131-validation-for-existing-subscribers) - 既存の利用者検証 - [3.2.2.2.13.2 Re-issuance Requests](#3222132-re-issuance-requests) - 再発行要求 - [3.2.2.2.13.3 Age of Validated Data](#3222133-age-of-validated-data) - 検証済みデータの有効期限 - [3.2.2.3 Verification of Country](#3223-verification-of-country) - 国名検証 - [3.2.2.4 Validation of Domain Authorization or Control](#3224-validation-of-domain-authorization-or-control) - ドメイン認証または管理の検証 - [3.2.2.4.1 Validating the Applicant as a Domain Contact](#32241-validating-the-applicant-as-a-domain-contact) - ドメイン連絡先としての申請者の検証 - [3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact](#32242-email-fax-sms-or-postal-mail-to-domain-contact) - ドメイン連絡先へのEmail、FAX、SMSまたは郵便 - [3.2.2.4.3 Phone Contact with Domain Contact](#32243-phone-contact-with-domain-contact) - ドメイン連絡先への電話連絡 - [3.2.2.4.4 Constructed Email to Domain Contact](#32244-constructed-email-to-domain-contact) - ドメイン連絡先への指定アドレス宛Email - [3.2.2.4.5 Domain Authorization Document](#32245-domain-authorization-document) - ドメイン認証文書 - [3.2.2.4.6 Agreed-Upon Change to Website](#32246-agreed-upon-change-to-website) - ウェブサイトへの合意に基づく変更 - [3.2.2.4.7 DNS Change](#32247-dns-change) - DNS変更 - [3.2.2.4.8 IP Address](#32248-ip-address) - IPアドレス - [3.2.2.4.9 Test Certificate](#32249-test-certificate) - テスト証明書 - [3.2.2.4.10 TLS Using a Random Value](#322410-tls-using-a-random-value) - ランダム値を使用したTLS - [3.2.2.4.11 Any Other Method](#322411-any-other-method) - その他の方法 - [3.2.2.4.12 Validating Applicant as a Domain Contact](#322412-validating-applicant-as-a-domain-contact) - ドメイン連絡先としての申請者検証 - [3.2.2.4.13 Email to DNS CAA Contact](#322413-email-to-dns-caa-contact) - DNS CAA連絡先へのEmail - [3.2.2.4.14 Email to DNS TXT Contact](#322414-email-to-dns-txt-contact) - DNS TXT連絡先へのEmail - [3.2.2.4.15 Phone Contact with Domain Contact](#322415-phone-contact-with-domain-contact) - ドメイン連絡先への電話連絡 - [3.2.2.4.16 Phone Contact with DNS TXT Record Phone Contact](#322416-phone-contact-with-dns-txt-record-phone-contact) - DNS TXT連絡先への電話連絡 - [3.2.2.4.17 Phone Contact with DNS CAA Phone Contact](#322417-phone-contact-with-dns-caa-phone-contact) - DNS CAA連絡先への電話連絡 - [3.2.2.4.18 Agreed-Upon Change to Website v2](#322418-agreed-upon-change-to-website-v2) - ウェブサイトへの合意に基づく変更 v2 - [3.2.2.4.19 Agreed-Upon Change to Website - ACME](#322419-agreed-upon-change-to-website---acme) - ウェブサイトへの合意に基づく変更 - ACME - [3.2.2.4.20 TLS Using ALPN](#322420-tls-using-alpn) - ALPNを使用したTLS - [3.2.2.5 Authentication for an IP Address](#3225-authentication-for-an-ip-address) - IPアドレス認証 - [3.2.2.6 Wildcard Domain Validation](#3226-wildcard-domain-validation) - ワイルドカードドメイン認証 - [3.2.2.7 Data Source Accuracy](#3227-data-source-accuracy) - データソースの正確性 - [3.2.2.8 CAA Records](#3228-caa-records) - CAAレコード - [3.2.2.9 Multi-Perspective Issuance Corroboration](#3229-multi-perspective-issuance-corroboration) - マルチパースペクティブ発行検証 - [3.2.3 Authentication of individual identity](#323-authentication-of-individual-identity) - 個人認証 - [3.2.3.1 Attribute collection of organization identity (S/MIME Certificates)](#3231-attribute-collection-of-organization-identity-smime-certificates) - 組織のアイデンティティ属性の収集 (S/MIME 証明書) - [3.2.4 Non-verified subscriber information](#324-non-verified-subscriber-information) - 未検証の利用者情報 - [3.2.5 Validation of authority](#325-validation-of-authority) - 権限検証 - [3.2.6 Criteria for Interoperation or Certification](#326-criteria-for-interoperation-or-certification) - 相互運用または認証の基準 - [3.3 Identification and authentication for re-key requests](#33-identification-and-authentication-for-re-key-requests) - 鍵更新申請時の本人性確認と認証 - [3.3.1 Identification and authentication for routine re-key](#331-identification-and-authentication-for-routine-re-key) - 通常の鍵更新時における本人性確認と認証 - [3.3.2 Identification and authentication for re-key after revocation](#332-identification-and-authentication-for-re-key-after-revocation) - 証明書失効後の鍵更新における本人性確認と認証 - [3.4 Identification and authentication for revocation request](#34-identification-and-authentication-for-revocation-request) - 失効申請時の本人性確認と認証 - [4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS](#4-certificate-life-cycle-operational-requirements) - 証明書ライフサイクルの運用要件 - [4.1 Certificate Application](#41-certificate-application) - 証明書申請 - [4.1.1 Who can submit a certificate application](#411-who-can-submit-a-certificate-application) - 証明書を申請できる者 - [4.1.2 Enrollment process and responsibilities](#412-enrollment-process-and-responsibilities) - 申請手続および責任 - [4.2 Certificate application processing](#42-certificate-application-processing) - 証明書申請手続 - [4.2.1 Performing identification and authentication functions](#421-performing-identification-and-authentication-functions) - 本人性確認と認証の実施 - [4.2.2 Approval or rejection of certificate applications](#422-approval-or-rejection-of-certificate-applications) - 証明書申請の承認または却下 - [4.2.2.1 Certification authority authorization (CAA) (S/MIME Certificates)](#4221-certification-authority-authorization-caa-smime-certificates) - 認証局認可 (CAA) (S/MIME 証明書) - [4.2.2.2 Multi-perspective issuance corroboration (S/MIME Certificates)](#4222-multi-perspective-issuance-corroboration-smime-certificates) - マルチパースペクティブ発行検証 (S/MIME 証明書) - [4.2.3 Time to process certificate applications](#423-time-to-process-certificate-applications) - 証明書申請の処理時間 - [4.3 Certificate issuance](#43-certificate-issuance) - 証明書発行 - [4.3.1 CA actions during certificate issuance](#431-ca-actions-during-certificate-issuance) - 証明書発行時の処理手続 - [4.3.1.1 Manual authorization of certificate issuance for Root CAs](#4311-manual-authorization-of-certificate-issuance-for-root-cas) - Root CAの証明書発行の手動承認 - [4.3.1.2 Linting of to-be-signed Certificate content](#4312-linting-of-to-be-signed-certificate-content) - 署名される証明書のリンティング - [4.3.1.3 Linting of issued Certificates](#4313-linting-of-issued-certificates) - 発行済み証明書のリンティング - [4.3.2 Notification to subscriber by the CA of issuance of certificate](#432-notification-to-subscriber-by-the-ca-of-issuance-of-certificate) - CAによる利用者への証明書発行通知 - [4.4 Certificate acceptance](#44-certificate-acceptance) - 証明書受領確認 - [4.4.1 Conduct constituting certificate acceptance](#441-conduct-constituting-certificate-acceptance) - 証明書受領確認手続 - [4.4.2 Publication of the certificate by the CA](#442-publication-of-the-certificate-by-the-ca) - CAによる証明書公開 - [4.4.3 Notification of certificate issuance by the CA to other entities](#443-notification-of-certificate-issuance-by-the-ca-to-other-entities) - CAによる他の関係者への証明書発行通知 - [4.5 Key pair and certificate usage](#45-key-pair-and-certificate-usage) - 鍵ペアおよび証明書の用途 - [4.5.1 Subscriber private key and certificate usage](#451-subscriber-private-key-and-certificate-usage) - 利用者における私有鍵および証明書の用途 - [4.5.2 Relying party public key and certificate usage](#452-relying-party-public-key-and-certificate-usage) - 検証者における公開鍵と証明書の用途 - [4.6 Certificate renewal](#46-certificate-renewal) - 鍵更新をともなわない証明書更新 - [4.6.1 Circumstance for certificate renewal](#461-circumstance-for-certificate-renewal) - 鍵更新をともなわない証明書更新の要件 - [4.6.2 Who may request renewal](#462-who-may-request-renewal) - 鍵更新をともなわない証明書更新申請の処理手続 - [4.6.3 Processing certificate renewal requests](#463-processing-certificate-renewal-requests) - 鍵更新をともなわない証明書更新申請の処理手続 - [4.6.4 Notification of new certificate issuance to subscriber](#464-notification-of-new-certificate-issuance-to-subscriber) - 利用者への新更新証明書の発行通知 - [4.6.5 Conduct constituting acceptance of a renewal certificate](#465-conduct-constituting-acceptance-of-a-renewal-certificate) - 鍵更新をともなわない更新証明書の受領確認手続 - [4.6.6 Publication of the renewal certificate by the CA](#466-publication-of-the-renewal-certificate-by-the-ca) - CAによる鍵更新をともなわない更新証明書の公開 - [4.6.7 Notification of certificate issuance by the CA to other entities](#467-notification-of-certificate-issuance-by-the-ca-to-other-entities) - CAによる他の関係者への証明書発行通知 - [4.7 Certificate re-key](#47-certificate-re-key) - 証明書鍵更新 - [4.7.1 Circumstance for certificate re-key](#471-circumstance-for-certificate-re-key) - 証明書鍵更新に関する要件 - [4.7.2 Who may request certification of a new public key](#472-who-may-request-certification-of-a-new-public-key) - 鍵更新をともなう新証明書の申請を行うことができる者 - [4.7.3 Processing certificate re-keying requests](#473-processing-certificate-re-keying-requests) - 鍵更新をともなう証明書申請の処理手続 - [4.7.4 Notification of new certificate issuance to subscriber](#474-notification-of-new-certificate-issuance-to-subscriber) - 利用者への新証明書発行通知 - [4.7.5 Conduct constituting acceptance of a re-keyed certificate](#475-conduct-constituting-acceptance-of-a-re-keyed-certificate) - 鍵更新をともなう証明書受領確認手続 - [4.7.6 Publication of the re-keyed certificate by the CA](#476-publication-of-the-re-keyed-certificate-by-the-ca) - CAによる鍵更新された証明書の公開 - [4.7.7 Notification of certificate issuance by the CA to other entities](#477-notification-of-certificate-issuance-by-the-ca-to-other-entities) - CAによる他の関係者への証明書発行通知 - [4.8 Certificate modification](#48-certificate-modification) - 証明書記載事項変更による証明書変更 - [4.8.1 Circumstance for certificate modification](#481-circumstance-for-certificate-modification) - 証明書記載事項変更による証明書変更の要件 - [4.8.2 Who may request certificate modification](#482-who-may-request-certificate-modification) - 証明書記載事項変更による証明書変更を要求できる者 - [4.8.3 Processing certificate modification requests](#483-processing-certificate-modification-requests) - 証明書変更要求の処理 - [4.8.4 Notification of new certificate issuance to subscriber](#484-notification-of-new-certificate-issuance-to-subscriber) - 利用者への新証明書発行通知 - [4.8.5 Conduct constituting acceptance of modified certificate](#485-conduct-constituting-acceptance-of-modified-certificate) - 変更された証明書受領確認手続 - [4.8.6 Publication of the modified certificate by the CA](#486-publication-of-the-modified-certificate-by-the-ca) - CAによる変更済み証明書の公開 - [4.8.7 Notification of certificate issuance by the CA to other entities](#487-notification-of-certificate-issuance-by-the-ca-to-other-entities) - CAによる他の関係者への証明書発行通知 - [4.9 Certificate revocation and suspension](#49-certificate-revocation-and-suspension) - 証明書の失効と一時停止 - [4.9.1 Circumstances for revocation](#491-circumstances-for-revocation) - 証明書失効要件 - [4.9.1.1 Reasons for Revoking a Subscriber Certificate](#4911-reasons-for-revoking-a-subscriber-certificate) - 利用者証明書の失効理由 - [4.9.1.2 Reasons for Revoking a Subordinate CA Certificate](#4912-reasons-for-revoking-a-subordinate-ca-certificate) - 下位CA証明書の失効理由 - [4.9.2 Who can request revocation](#492-who-can-request-revocation) - 証明書の失効申請を行うことができる者 - [4.9.3 Procedure for revocation request](#493-procedure-for-revocation-request) - 失効申請手続 - [4.9.4 Revocation request grace period](#494-revocation-request-grace-period) - 失効申請の猶予期間 - [4.9.5 Time within which CA must process the revocation request](#495-time-within-which-ca-must-process-the-revocation-request) - CAが失効処理する時間 - [4.9.6 Revocation checking requirement for relying parties](#496-revocation-checking-requirement-for-relying-parties) - 検証者に対する失効確認要件 - [4.9.7 CRL issuance frequency](#497-crl-issuance-frequency) - CRLの発行頻度 - [4.9.8 Maximum latency for CRLs (if applicable)](#498-maximum-latency-for-crls-if-applicable) - CRL発行の最大遅延 (該当する場合) - [4.9.9 On-line revocation/status checking availability](#499-on-line-revocationstatus-checking-availability) - オンライン失効/ステータス確認の可用性 - [4.9.10 On-line revocation checking requirements](#4910-on-line-revocation-checking-requirements) - オンライン失効確認の要件 - [4.9.11 Other forms of revocation advertisements available](#4911-other-forms-of-revocation-advertisements-available) - その他の形式での証明書有効性確認方法 - [4.9.12 Special requirements re key compromise](#4912-special-requirements-re-key-compromise) - 鍵危殆化の特別要件 - [4.9.13 Circumstances for suspension](#4913-circumstances-for-suspension) - 証明書一時停止の要件 - [4.9.14 Who can request suspension](#4914-who-can-request-suspension) - 証明書一時停止を要求できる者 - [4.9.15 Procedure for suspension request](#4915-procedure-for-suspension-request) - 証明書一時停止要求の手順 - [4.9.16 Limits on suspension period](#4916-limits-on-suspension-period) - 一時停止可能期間 - [4.10 Certificate status services](#410-certificate-status-services) - 証明書有効性確認サービス - [4.10.1 Operational characteristics](#4101-operational-characteristics) - 運用特性 - [4.10.2 Service availability](#4102-service-availability) - サービスの可用性 - [4.10.3 Optional features](#4103-optional-features) - オプション機能 - [4.11 End of subscription](#411-end-of-subscription) - 利用者の利用終了 - [4.12 Key escrow and recovery](#412-key-escrow-and-recovery) - キーエスクロー（鍵預託）と鍵回復 - [4.12.1 Key escrow and recovery policy and practices](#4121-key-escrow-and-recovery-policy-and-practices) - キーエスクロー（鍵預託）と回復に関するポリシーと実施手順 - [4.12.2 Session key encapsulation and recovery policy and practices](#4122-session-key-encapsulation-and-recovery-policy-and-practices) - セッション鍵のカプセル化および鍵回復に関するポリシーと実施手順 - [5. MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS](#5-management-operational-and-physical-controls) -管理、運用、物理的制御 - [5.1 Physical Security Controls](#51-physical-security-controls) - 物理的セキュリティ管理 - [5.1.1 Site location and construction](#511-site-location-and-construction) - 立地場所と建築構造 - [5.1.2 Physical access](#512-physical-access) - 物理的アクセス - [5.1.3 Power and air conditioning](#513-power-and-air-conditioning) - 電力と空調 - [5.1.4 Water exposures](#514-water-exposures) - 水害対策 - [5.1.5 Fire prevention and protection](#515-fire-prevention-and-protection) - 防火対策 - [5.1.6 Media storage](#516-media-storage) - 媒体保管 - [5.1.7 Waste disposal](#517-waste-disposal) - 廃棄処理 - [5.1.8 Off-site backup](#518-off-site-backup) - オフサイトバックアップ - [5.2 Procedural controls](#52-procedural-controls) - 手順の管理 - [5.2.1 Trusted roles](#521-trusted-roles) - 信頼された役割 - [5.2.2 Number of Individuals Required per Task](#522-number-of-individuals-required-per-task) - 職務ごとに必要とされる人数 - [5.2.3 Identification and authentication for each role](#523-identification-and-authentication-for-each-role) - 各役割の本人性確認と認証 - [5.2.4 Roles requiring separation of duties](#524-roles-requiring-separation-of-duties) - 各役割の権限分割 - [5.3 Personnel controls](#53-personnel-controls) - 人事管理 - [5.3.1 Qualifications, experience, and clearance requirements](#531-qualifications-experience-and-clearance-requirements) - 資格、経歴およびクリアランス要件 - [5.3.2 Background check procedures](#532-background-check-procedures) - 身元調査の手順 - [5.3.3 Training Requirements and Procedures](#533-training-requirements-and-procedures) - 教育要件と手順 - [5.3.4 Retraining frequency and requirements](#534-retraining-frequency-and-requirements) - 再教育の頻度および要件 - [5.3.5 Job rotation frequency and sequence](#535-job-rotation-frequency-and-sequence) - ジョブローテーションの頻度と方法 - [5.3.6 Sanctions for unauthorized actions](#536-sanctions-for-unauthorized-actions) - 不正行為に対する制裁 - [5.3.7 Independent Contractor Controls](#537-independent-contractor-controls) - 委託契約の要件 - [5.3.8 Documentation supplied to personnel](#538-documentation-supplied-to-personnel) - 担当者に提供される文書 - [5.4 Audit logging procedures](#54-audit-logging-procedures) - 監査ログ手順 - [5.4.1 Types of events recorded](#541-types-of-events-recorded) - 記録されるイベントの種類 - [5.4.1.1 Router and firewall activities logs](#5411-router-and-firewall-activities-logs) - ルーターとファイアウォールのアクティビティログ - [5.4.1.2 Types of events recorded for Timestamp Authorities](#5412-types-of-events-recorded-for-timestamp-authorities) - タイムスタンプ局に記録されるイベントの種類 - [5.4.2 Frequency of processing audit log](#542-frequency-of-processing-audit-log) - 監査ログの処理頻度 - [5.4.3 Retention period for audit log](#543-retention-period-for-audit-log) - 監査ログの保管期間 - [5.4.4 Protection of audit log](#544-protection-of-audit-log) - 監査ログの保護 - [5.4.5 Audit log backup procedures](#545-audit-log-backup-procedures) - 監査ログのバックアップ手順 - [5.4.6 Audit collection System (internal vs. external)](#546-audit-collection-system-internal-vs-external) - 監査収集システム（内部および外部） - [5.4.7 Notification to event-causing subject](#547-notification-to-event-causing-subject) - イベントの要因となるサブジェクトへの通知 - [5.4.8 Vulnerability assessments](#548-vulnerability-assessments) - 脆弱性アセスメント - [5.5 Records archival](#55-records-archival) - 記録のアーカイブ - [5.5.1 Types of records archived](#551-types-of-records-archived) - アーカイブされる記録の種類 - [5.5.2 Retention period for archive](#552-retention-period-for-archive) - アーカイブ保存期間 - [5.5.3 Protection of archive](#553-protection-of-archive) - アーカイブ保護 - [5.5.4 Archive backup procedures](#554-archive-backup-procedures) - アーカイブバックアップ手順 - [5.5.5 Requirements for time-stamping of records](#555-requirements-for-time-stamping-of-records) - 記録のタイムスタンプ要件 - [5.5.6 Archive collection system (internal or external)](#556-archive-collection-system-internal-or-external) - アーカイブ収集システム (内部または外部) - [5.5.7 Procedures to obtain and verify archive information](#557-procedures-to-obtain-and-verify-archive-information) - アーカイブ情報の取得および検証手順 - [5.6 Key changeover](#56-key-changeover) - 鍵の切り替え - [5.7 Compromise and disaster recovery](#57-compromise-and-disaster-recovery) - 危殆化および災害復旧 - [5.7.1 Incident and compromise handling procedures](#571-incident-and-compromise-handling-procedures) - インシデントおよび危殆化対応手順 - [5.7.2 Recovery Procedures if Computing resources, software, and/or data are corrupted](#572-recovery-procedures-if-computing-resources-software-andor-data-are-corrupted) - コンピューティングリソース、ソフトウェア、データが破損した場合の復旧手順 - [5.7.3 Recovery Procedures after Key Compromise](#573-recovery-procedures-after-key-compromise) - 鍵危殆化発生後の復旧手順 - [5.7.4 Business continuity capabilities after a disaster](#574-business-continuity-capabilities-after-a-disaster) - 災害後の事業継続 - [5.8 CA or RA termination](#58-ca-or-ra-termination) - CAまたはRAの終了 - [6. TECHNICAL SECURITY CONTROLS](#6-technical-security-controls) - 技術的セキュリティ管理 - [6.1 Key pair generation and installation](#61-key-pair-generation-and-installation) - 鍵ペアの生成とインストール - [6.1.1 Key pair generation](#611-key-pair-generation) - 鍵ペアの生成 - [6.1.1.1 CA Key Pair Generation](#6111-ca-key-pair-generation) - CA鍵ペアの生成 - [6.1.1.2 RA Key Pair Generation](#6112-ra-key-pair-generation) - RA鍵ペアの生成 - [6.1.1.3 Subscriber Key Pair Generation](#6113-subscriber-key-pair-generation) - 利用者鍵ペアの生成 - [6.1.2 Private key delivery to subscriber](#612-private-key-delivery-to-subscriber) - 利用者への私有鍵配布 - [6.1.3 Public key delivery to certificate issuer](#613-public-key-delivery-to-certificate-issuer) - 証明書発行者への公開鍵配布 - [6.1.4 CA public key delivery to relying parties](#614-ca-public-key-delivery-to-relying-parties) - 検証者へのCA公開鍵配布 - [6.1.5 Key sizes](#615-key-sizes) - 鍵サイズ - [6.1.6 Public key parameters generation and quality checking](#616-public-key-parameters-generation-and-quality-checking) - 公開鍵パラメーターの生成と品質確認 - [6.1.7 Key usage purposes (as per X.509 v3 key usage field)](#617-key-usage-purposes-as-per-x509-v3-key-usage-field) - 鍵の使用目的（X.509 v3 key usageフィールドに準拠） - [6.2 Private Key Protection and Cryptographic Module Engineering Controls](#62-private-key-protection-and-cryptographic-module-engineering-controls) - 私有鍵の保護および暗号モジュールの運用管理 - [6.2.1 Cryptographic module standards and controls](#621-cryptographic-module-standards-and-controls) - 暗号モジュールの規格と管理 - [6.2.2 Private key (n out of m) multi-person control](#622-private-key-n-out-of-m-multi-person-control) - 私有鍵の複数人管理 - [6.2.3 Private key escrow](#623-private-key-escrow) - 私有鍵のエスクロー - [6.2.4 Private key backup](#624-private-key-backup) - 私有鍵のバックアップ - [6.2.5 Private key archival](#625-private-key-archival) - 私有鍵のアーカイブ - [6.2.6 Private key transfer into or from a cryptographic module](#626-private-key-transfer-into-or-from-a-cryptographic-module) - 私有鍵の暗号モジュールへの移行または暗号モジュールからの移行 - [6.2.7 Private key storage on cryptographic module](#627-private-key-storage-on-cryptographic-module) - 暗号モジュールでの私有鍵保管 - [6.2.8 Activating Private Keys](#628-activating-private-keys) - 私有鍵の活性化 - [6.2.9 Deactivating Private Keys](#629-deactivating-private-keys) - 私有鍵の非活性化 - [6.2.10 Destroying Private Keys](#6210-destroying-private-keys) - 私有鍵の破棄 - [6.2.11 Cryptographic Module Rating](#6211-cryptographic-module-rating) - 暗号モジュールの評価 - [6.3 Other aspects of key pair management](#63-other-aspects-of-key-pair-management) - 鍵ペア管理に関するその他の事項 - [6.3.1 Public key archival](#631-public-key-archival) - 公開鍵のアーカイブ - [6.3.2 Certificate operational periods and key pair usage periods](#632-certificate-operational-periods-and-key-pair-usage-periods) - 証明書有効期間と鍵ペア使用期間 - [6.4 Activation data](#64-activation-data) - アクティベーションデータ - [6.4.1 Activation data generation and installation](#641-activation-data-generation-and-installation) - アクティベーションデータの生成と設定 - [6.4.2 Activation data protection](#642-activation-data-protection) - アクティベーションデータの保護 - [6.4.3 Other aspects of activation data](#643-other-aspects-of-activation-data) - アクティベーションデータに関するその他の事項 - [6.5 Computer security controls](#65-computer-security-controls) - コンピューターのセキュリティ管理 - [6.5.1 Specific computer security technical requirements](#651-specific-computer-security-technical-requirements) - 特定のコンピューターのセキュリティ技術要件 - [6.5.2 Computer security rating](#652-computer-security-rating) - コンピューターのセキュリティ評価 - [6.6 Life cycle technical controls](#66-life-cycle-technical-controls) - ライフサイクルの技術的管理 - [6.6.1 System development controls](#661-system-development-controls) - システム開発の管理 - [6.6.2 Security management controls](#662-security-management-controls) - セキュリティ運用管理 - [6.6.3 Life cycle security controls](#663-life-cycle-security-controls) - ライフサイクルセキュリティの管理 - [6.7 Network security controls](#67-network-security-controls) - ネットワークセキュリティの管理 - [6.8 Time-stamping](#68-time-stamping) - タイムスタンプ - [7. CERTIFICATE, CRL, AND OCSP PROFILES](#7-certificate-crl-and-ocsp-profiles) - 証明書、CRLおよびOCSP プロファイル - [7.1 Certificate profile](#71-certificate-profile) - 証明書プロファイル - [7.1.1 Version number(s)](#711-version-numbers) - バージョン番号 - [7.1.2 Certificate Content and Extensions](#712-certificate-content-and-extensions) - 証明書拡張 - [7.1.2.1 Root CA Certificate Profile](#7121-root-ca-certificate-profile) - Root CA 証明書プロファイル - [7.1.2.1.1 Root CA Validity](#71211-root-ca-validity) - Root CA の有効期間 - [7.1.2.1.2 Root CA Extensions](#71212-root-ca-extensions) - Root CA 拡張 - [7.1.2.1.3 Root CA Authority Key Identifier](#71213-root-ca-authority-key-identifier) - Root CA 認証局鍵識別子 - [7.1.2.1.4 Root CA Basic Constraints](#71214-root-ca-basic-constraints) - Root CA の基本制約 - [7.1.2.2 Cross-Certified Subordinate CA Certificate Profile](#7122-cross-certified-subordinate-ca-certificate-profile) - クロス認証下位CA証明書プロファイル - [7.1.2.2.1 Cross-Certified Subordinate CA Validity](#71221-cross-certified-subordinate-ca-validity) - クロス認証下位CAの有効期間 - [7.1.2.2.2 Cross-Certified Subordinate CA Naming](#71222-cross-certified-subordinate-ca-naming) - クロス認証下位CAの識別名 - [7.1.2.2.3 Cross-Certified Subordinate CA Extensions](#71223-cross-certified-subordinate-ca-extensions) - クロス認証下位CA拡張 - [7.1.2.2.4 Cross-Certified Subordinate CA Extended Key Usage - Unrestricted](#71224-cross-certified-subordinate-ca-extended-key-usage---unrestricted) - クロス認証下位CA拡張鍵使用法 - 制約無し - [7.1.2.2.5 Cross-Certified Subordinate CA Extended Key Usage - Restricted](#71225-cross-certified-subordinate-ca-extended-key-usage---restricted) - クロス認証下位CA拡張鍵使用法 - 制約あり - [7.1.2.2.6 Cross-Certified Subordinate CA Certificate Certificate Policies](#71226-cross-certified-subordinate-ca-certificate-certificate-policies) - クロス認証下位CA証明書のCP - [7.1.2.3 Technically Constrained Non-TLS Subordinate CA Certificate Profile](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) - 技術的に制約された非TLS下位CA証明書プロファイル - [7.1.2.3.1 Technically Constrained Non-TLS Subordinate CA Extensions](#71231-technically-constrained-non-tls-subordinate-ca-extensions) - 技術的に制約された非TLS下位CA拡張 - [7.1.2.3.2 Technically Constrained Non-TLS Subordinate CA Certificate Policies](#71232-technically-constrained-non-tls-subordinate-ca-certificate-policies) - 技術的に制約された非TLS下位CAのCP - [7.1.2.3.3 Technically Constrained Non-TLS Subordinate CA Extended Key Usage](#71233-technically-constrained-non-tls-subordinate-ca-extended-key-usage) - 技術的に制約された非TLS下位CA拡張鍵使用法 - [7.1.2.4 Technically Constrained Precertificate Signing CA Certificate Profile](#7124-technically-constrained-precertificate-signing-ca-certificate-profile) - 技術的に制約された事前証明書サイニングCA証明書プロファイル - [7.1.2.4.1 Technically Constrained Precertificate Signing CA Extensions](#71241-technically-constrained-precertificate-signing-ca-extensions) - 技術的に制約された事前証明書サイニングCA拡張 - [7.1.2.4.2 Technically Constrained Precertificate Signing CA Extended Key Usage](#71242-technically-constrained-precertificate-signing-ca-extended-key-usage) - 技術的に制約された事前証明書サイニングCA拡張鍵使用法 - [7.1.2.5 Technically Constrained TLS Subordinate CA Certificate Profile](#7125-technically-constrained-tls-subordinate-ca-certificate-profile) - 技術的に制約されたTLS下位CA証明書プロファイル - [7.1.2.5.1 Technically Constrained TLS Subordinate CA Extensions](#71251-technically-constrained-tls-subordinate-ca-extensions) - 技術的に制約されたTLS下位CA拡張 - [7.1.2.5.2 Technically Constrained TLS Subordinate CA Name Constraints](#71252-technically-constrained-tls-subordinate-ca-name-constraints) - 技術的に制約されたTLS下位CA名前制約 - [7.1.2.6 TLS Subordinate CA Certificate Profile](#7126-tls-subordinate-ca-certificate-profile) - TLS下位CA証明書プロファイル - [7.1.2.6.1 TLS Subordinate CA Extensions](#71261-tls-subordinate-ca-extensions) - TLS下位CA拡張 - [7.1.2.7 Subscriber (Server) Certificate Profile](#7127-subscriber-server-certificate-profile) - 利用者（サーバー）証明書プロファイル - [7.1.2.7.1 Subscriber Certificate Types](#71271-subscriber-certificate-types) - 利用者証明書のタイプ - [7.1.2.7.2 Domain Validated](#71272-domain-validated) - ドメイン認証（DV） - [7.1.2.7.3 Individual Validated](#71273-individual-validated) - 個人認証（IV） - [7.1.2.7.4 Organization Validated](#71274-organization-validated) - 組織認証（OV） - [7.1.2.7.5 Extended Validation](#71275-extended-validation) - 拡張認証（EV） - [7.1.2.7.6 Subscriber Certificate Extensions](#71276-subscriber-certificate-extensions) - 利用者証明書の拡張 - [7.1.2.7.7 Subscriber Certificate Authority Information Access](#71277-subscriber-certificate-authority-information-access) - 利用者証明書の権限情報アクセス - [7.1.2.7.8 Subscriber Certificate Basic Constraints](#71278-subscriber-certificate-basic-constraints) - 利用者証明書の基本制約 - [7.1.2.7.9 Subscriber Certificate Certificate Policies](#71279-subscriber-certificate-certificate-policies) - 利用者証明書の証明書ポリシー - [7.1.2.7.10 Subscriber Certificate Extended Key Usage](#712710-subscriber-certificate-extended-key-usage) - 利用者証明書の拡張鍵使用法 - [7.1.2.7.11 Subscriber Certificate Key Usage](#712711-subscriber-certificate-key-usage) - 利用者証明書の鍵使用法 - [7.1.2.7.12 Subscriber Certificate Subject Alternative Name](#712712-subscriber-certificate-subject-alternative-name) - 利用者証明書の主体者識別名代替名 - [7.1.2.8 OCSP Responder Certificate Profile](#7128-ocsp-responder-certificate-profile) - OCSPレスポンダー証明書プロファイル - [7.1.2.8.1 OCSP Responder Validity](#71281-ocsp-responder-validity) - OCSPレスポンダーの有効期限 - [7.1.2.8.2 OCSP Responder Extensions](#71282-ocsp-responder-extensions) - OCSP レスポンダーの拡張 - [7.1.2.8.3 OCSP Responder Authority Information Access](#71283-ocsp-responder-authority-information-access) - OCSPレスポンダーの機関情報アクセス - [7.1.2.8.4 OCSP Responder Basic Constraints](#71284-ocsp-responder-basic-constraints) - OCSPレスポンダー基本制約 - [7.1.2.8.5 OCSP Responder Extended Key Usage](#71285-ocsp-responder-extended-key-usage) - OCSPレスポンダー拡張鍵使用法 - [7.1.2.8.6 OCSP Responder id-pkix-ocsp-nocheck](#71286-ocsp-responder-id-pkix-ocsp-nocheck) - OCSPレスポンダー id-pkix-ocsp-nocheck - [7.1.2.8.7 OCSP Responder Key Usage](#71287-ocsp-responder-key-usage) - OCSPレスポンダー鍵の使用法 - [7.1.2.8.8 OCSP Responder Certificate Policies](#71288-ocsp-responder-certificate-policies) - OCSPレスポンダー証明書ポリシー - [7.1.2.9 Precertificate Profile](#7129-precertificate-profile) - 事前証明書プロファイル - [7.1.2.9.1 Precertificate Profile Extensions - Directly Issued](#71291-precertificate-profile-extensions---directly-issued) - 事前証明書プロファイル拡張 - 直接発行 - [7.1.2.9.2 Precertificate Profile Extensions - Precertificate CA Issued](#71292-precertificate-profile-extensions---precertificate-ca-issued) - 事前証明書プロファイル拡張 - CA発行の事前証明書 - [7.1.2.9.3 Precertificate Poison](#71293-precertificate-poison) - 事前証明書ポイズン - [7.1.2.9.4 Precertificate Authority Key Identifier](#71294-precertificate-authority-key-identifier) - 事前証明書局鍵識別子 - [7.1.2.10 Common CA Fields](#71210-common-ca-fields) - 共通CAフィールド - [7.1.2.10.1 CA Certificate Validity](#712101-ca-certificate-validity) - CA証明書の有効期限 - [7.1.2.10.2 CA Certificate Naming](#712102-ca-certificate-naming) - CA証明書の識別名 - [7.1.2.10.3 CA Certificate Authority Information Access](#712103-ca-certificate-authority-information-access) - CA証明書の機関情報アクセス - [7.1.2.10.4 CA Certificate Basic Constraints](#712104-ca-certificate-basic-constraints) - CA証明書の基本制約 - [7.1.2.10.5 CA Certificate Certificate Policies](#712105-ca-certificate-certificate-policies) - CA証明書の証明書ポリシー - [7.1.2.10.6 CA Certificate Extended Key Usage](#712106-ca-certificate-extended-key-usage) - CA証明書の拡張鍵使用法 - [7.1.2.10.7 CA Certificate Key Usage](#712107-ca-certificate-key-usage) - CA証明書鍵の使用法 - [7.1.2.10.8 CA Certificate Name Constraints](#712108-ca-certificate-name-constraints) - CA証明書の名前制約 - [7.1.2.11 Common Certificate Fields](#71211-common-certificate-fields) - 共通証明書フィールド - [7.1.2.11.1 Authority Key Identifier](#712111-authority-key-identifier) - 認証局鍵識別子 - [7.1.2.11.2 CRL Distribution Points](#712112-crl-distribution-points) - CRL配布ポイント - [7.1.2.11.3 Signed Certificate Timestamp List](#712113-signed-certificate-timestamp-list) - 署名された証明書のタイムスタンプリスト - [7.1.2.11.4 Subject Key Identifier](#712114-subject-key-identifier) - 主体者識別名鍵識別子 - [7.1.2.11.5 Other Extensions](#712115-other-extensions) - その他の拡張 - [7.1.3 Algorithm object identifiers](#713-algorithm-object-identifiers) - アルゴリズムオブジェクト識別子 - [7.1.3.1 SubjectPublicKeyInfo](#7131-subjectpublickeyinfo) - 主体者公開鍵情報 - [7.1.3.1.1 RSA](#71311-rsa) - RSA - [7.1.3.1.2 ECDSA](#71312-ecdsa) - ECDSA - [7.1.3.2 Signature AlgorithmIdentifier](#7132-signature-algorithmidentifier) - 署名アルゴリズム識別子 - [7.1.3.2.1 RSA](#71321-rsa) - RSA - [7.1.3.2.2 ECDSA](#71322-ecdsa) - ECDSA - [7.1.4 Name Forms](#714-name-forms) - 名前形式 - [7.1.4.1 Name Encoding](#7141-name-encoding) - 名前のエンコード - [7.1.4.2 Subject Attribute Encoding](#7142-subject-attribute-encoding) - 主体者識別名属性のエンコード - [7.1.4.3 Subscriber Certificate Common Name Attribute](#7143-subscriber-certificate-common-name-attribute) - 利用者証明書のコモンネーム属性 - [7.1.4.4 Other Subject Attributes](#7144-other-subject-attributes) - その他の主体者識別名属性 - [7.1.5 Name constraints](#715-name-constraints) - 名前制約 - [7.1.6 Certificate policy object identifier](#716-certificate-policy-object-identifier) - 証明書ポリシーオブジェクト識別子 - [7.1.6.1 Reserved Certificate Policy Identifiers](#7161-reserved-certificate-policy-identifiers) - 予約済み証明書ポリシー識別子 - [7.1.7 Usage of Policy Constraints extension](#717-usage-of-policy-constraints-extension) - ポリシー制約拡張の使用 - [7.1.8 Policy qualifiers syntax and semantics](#718-policy-qualifiers-syntax-and-semantics) - ポリシー修飾子の構文および意味 - [7.1.9 Processing semantics for the critical Certificate Policies extension](#719-processing-semantics-for-the-critical-certificate-policies-extension) - 重要な証明書ポリシー拡張の意味 - [7.2 CRL profile](#72-crl-profile) - CRLプロファイル - [7.2.1 Version number(s)](#721-version-numbers) - バージョン番号 - [7.2.2 CRL and CRL entry extensions](#722-crl-and-crl-entry-extensions) - CRLとCRLエントリー拡張 - [7.2.2.1 CRL Issuing Distribution Point](#7221-crl-issuing-distribution-point) - CRL発行配布ポイント - [7.3 OCSP profile](#73-ocsp-profile) - OCSPプロファイル - [7.3.1 Version number(s)](#731-version-numbers) - バージョン番号 - [7.3.2 OCSP extensions](#732-ocsp-extensions) - OCSP拡張 - [8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS](#8-compliance-audit-and-other-assessments) - 準拠性監査とその他の監査基準 - [8.1 Frequency or circumstances of assessment](#81-frequency-or-circumstances-of-assessment) - 評価の頻度と要件 - [8.2 Identity/qualifications of assessor](#82-identityqualifications-of-assessor) - 監査人の身元/資格 - [8.3 Assessor's relationship to assessed entity](#83-assessors-relationship-to-assessed-entity) - 監査人と被監査部門の関係 - [8.4 Topics covered by assessment](#84-topics-covered-by-assessment) - 監査で扱われる事項 - [8.5 Actions taken as a result of deficiency](#85-actions-taken-as-a-result-of-deficiency) - 不備に対する対応 - [8.6 Communication of results](#86-communication-of-results) - 監査結果の公開 - [8.7 Self-Audits](#87-self-audits) - 自己監査 - [8.8 Review of delegated parties](#88-review-of-delegated-parties) - 委託先のレビュー - [9. OTHER BUSINESS AND LEGAL MATTERS](#9-other-business-and-legal-matters) - その他の業務上および法的事項 - [9.1 Fees](#91-fees) - 料金 - [9.1.1 Certificate issuance or renewal fees](#911-certificate-issuance-or-renewal-fees) - 証明書の発行/更新手数料 - [9.1.2 Certificate access fees](#912-certificate-access-fees) - 証明書アクセス料金 - [9.1.3 Revocation or status information access fees](#913-revocation-or-status-information-access-fees) - 失効またはステータス情報アクセス料金 - [9.1.4 Fees for other services](#914-fees-for-other-services) - その他のサービス料金 - [9.1.5 Refund policy](#915-refund-policy) - 返金ポリシー - [9.2 Financial responsibility](#92-financial-responsibility) - 財務的責任 - [9.2.1 Insurance coverage](#921-insurance-coverage) - 保険適用範囲 - [9.2.2 Other assets](#922-other-assets) - その他の資産 - [9.2.3 Insurance or warranty coverage for end-entities](#923-insurance-or-warranty-coverage-for-end-entities) - エンドエンティティに対する保険または保証範囲 - [9.3 Confidentiality of business information](#93-confidentiality-of-business-information) - 企業情報の機密保持 - [9.3.1 Scope of confidential information](#931-scope-of-confidential-information) - 機密情報の範囲 - [9.3.2 Information not within the scope of confidential information](#932-information-not-within-the-scope-of-confidential-information) - 機密情報の範囲外の情報 - [9.3.3 Responsibility to protect confidential information](#933-responsibility-to-protect-confidential-information) - 機密情報の保護責任 - [9.4 Privacy of personal information](#94-privacy-of-personal-information) - 個人情報保護方針 - [9.4.1 Privacy plan](#941-privacy-plan) - 個人情報保護プラン - [9.4.2 Information treated as private](#942-information-treated-as-private) - 個人情報として扱われる情報 - [9.4.3 Information not deemed private](#943-information-not-deemed-private) - 個人情報と見なされない情報 - [9.4.4 Responsibility to protect private information](#944-responsibility-to-protect-private-information) - 個人情報の保護責任 - [9.4.5 Notice and consent to use private information](#945-notice-and-consent-to-use-private-information) - 個人情報利用に関する通知と同意 - [9.4.6 Disclosure pursuant to judicial or administrative process](#946-disclosure-pursuant-to-judicial-or-administrative-process) - 司法または行政手続に沿った情報開示 - [9.4.7 Other information disclosure circumstances](#947-other-information-disclosure-circumstances) - その他の情報開示要件 - [9.5 Intellectual property rights](#95-intellectual-property-rights) - 知的財産権 - [9.6 Representations and warranties](#96-representations-and-warranties) - 表明および保証 - [9.6.1 CA representations and warranties](#961-ca-representations-and-warranties) - CAの表明および保証 - [9.6.2 RA representations and warranties](#962-ra-representations-and-warranties) - RAの表明および保証 - [9.6.3 Subscriber representations and warranties](#963-subscriber-representations-and-warranties) - 利用者の表明および保証 - [9.6.4 Relying party representations and warranties](#964-relying-party-representations-and-warranties) - 検証者の表明および保証 - [9.6.5 Representations and warranties of other participants](#965-representations-and-warranties-of-other-participants) - その他関係者の表明および保証 - [9.7 Disclaimers of warranties](#97-disclaimers-of-warranties) - 保証の免責 - [9.8 Limitations of liability](#98-limitations-of-liability) - 責任の制限 - [9.9 Indemnities](#99-indemnities) - 補償 - [9.10 Term and termination](#910-term-and-termination) - CP/CPSの効力開始と終了 - [9.10.1 Term](#9101-term) - CP/CPSの効力開始 - [9.10.2 Termination](#9102-termination) - CP/CPSの効力終了 - [9.10.3 Effect of termination and survival](#9103-effect-of-termination-and-survival) - CP/CPSの効力継続 - [9.11 Individual notices and communications with participants](#911-individual-notices-and-communications-with-participants) - 関係者への個別通知および連絡 - [9.12 Amendments](#912-amendments) - 改訂 - [9.12.1 Procedure for amendment](#9121-procedure-for-amendment) - 改訂手続 - [9.12.2 Notification mechanism and period](#9122-notification-mechanism-and-period) - 通知方法および期間 - [9.12.3 Circumstances under which OID must be changed](#9123-circumstances-under-which-oid-must-be-changed) - OIDが変更されなければならない要件 - [9.13 Dispute resolution provisions](#913-dispute-resolution-provisions) - 紛争解決手続 - [9.14 Governing law](#914-governing-law) - 準拠法 - [9.15 Compliance with applicable law](#915-compliance-with-applicable-law) - 適用法の遵守 - [9.16 Miscellaneous provisions](#916-miscellaneous-provisions) - 雑則 - [9.16.1 Entire agreement](#9161-entire-agreement) - 完全合意条項 - [9.16.2 Assignment](#9162-assignment) - 権利譲渡条項 - [9.16.3 Severability](#9163-severability) - 分離条項 - [9.16.4 Enforcement (attorneys' fees and waiver of rights)](#9164-enforcement-attorneys-fees-and-waiver-of-rights) - 強制執行条項 - [9.16.5 Force Majeure](#9165-force-majeure) - 不可抗力条項 - [9.17 Other provisions](#917-other-provisions) - その他条項 - [APPENDIX A – CAA Contact Tag](#appendix-a--caa-contact-tag) - 付録 A – CAA連絡先タグ - [A.1. CAA Methods](#a1-caa-methods) - CAAメソッド - [A.1.1. CAA contactemail Property](#a11-caa-contactemail-property) - contactemail プロパティ - [A.1.2. CAA contactphone Property](#a12-caa-contactphone-property) - CAA contactphone プロパティ - [A.2. DNS TXT Methods](#a2-dns-txt-methods) - DNS TXT メソッド - [A.2.1. DNS TXT Record Email Contact](#a21-dns-txt-record-email-contact) - DNS TXT Record Email連絡先 - [A.2.2. DNS TXT Record Phone Contact](#a22-dns-txt-record-phone-contact) - DNS TXT Record 電話連絡先 - [APPENDIX B – Certificate profile](#appendix-b--certificate-profile) - 付録 B – 証明書プロファイル - [Table : "Security Communication RootCA2" and Subordinate CAs](#table--security-communication-rootca2-and-subordinate-cas) - [Table : "Security Communication RootCA3" and Subordinate CAs](#table--security-communication-rootca3-and-subordinate-cas) - [Table : "Security Communication ECC RootCA1" and Subordinate CAs](#table--security-communication-ecc-rootca1-and-subordinate-cas) - [Table : "SECOM RSA Root CA 2023" and Subordinate CAs](#table--secom-rsa-root-ca-2023-and-subordinate-cas) - [Table : "SECOM Document Signing RSA Root CA 2023" and Subordinate CAs](#table--secom-document-signing-rsa-root-ca-2023-and-subordinate-cas) - - [Table : "SECOM TLS RSA Root CA 2024" and Subordinate CA](#table--secom-tls-rsa-root-ca-2024-and-subordinate-ca) - [Table : "SECOM TLS ECC Root CA 2024" and Subordinate CA](#table--secom-tls-ecc-root-ca-2024-and-subordinate-ca) - [Table : "SECOM SMIME RSA Root CA 2024" and Subordinate CA](#table--secom-smime-rsa-root-ca-2024-and-subordinate-ca) - [Table : Subscriber Certificates (Client Authentication Certificate and Document Signing Certificates)](#table--subscriber-certificates-client-authentication-certificate-and-document-signing-certificates) - [Table : Subscriber Certificates (Code Signing Certificates, Not be issued after 2024-05-01)](#table--subscriber-certificates-code-signing-certificates-not-be-issued-after-2024-05-01) - [Table: Subscriber Certificates (AATL Document Signing Certificates)](#table-subscriber-certificates-aatl-document-signing-certificates) - [Table: Subscriber Certificates (S/MIME Certificates)](#table-subscriber-certificates-smime-certificates) - [Table: Security Communication RootCA2 TSA, TA Certificates (Issued before 2018-09-26)](#table-security-communication-rootca2-tsa-ta-certificates-issued-before-2018-09-26) - [Table: Security Communication RootCA3 TSA, TA Certificates (Issued before 2018-09-26)](#table-security-communication-rootca3-tsa-ta-certificates-issued-before-2018-09-26) - [Table: Security Communication RootCA3 TimeStamping Subordinate CA Certificates (Issued after 2018-06-07)](#table-security-communication-rootca3-timestamping-subordinate-ca-certificates-issued-after-2018-06-07) - [Table: SECOM TimeStamping CA2 TSA, TA Certificates](#table-secom-timestamping-ca2-tsa-ta-certificates) - [Table: SECOM TimeStamping CA3 TSA, TA Certificates](#table-secom-timestamping-ca3-tsa-ta-certificates) - [Table: SECOM TimeStamping CA4 TSA Certificates (Not issued after 2025-04-15)](#table-secom-timestamping-ca4-tsa-certificates-not-issued-after-2025-04-15) - [Table: SECOM TimeStamping Service TSA Certificates](#table-secom-timestamping-service-tsa-certificates) # 1. INTRODUCTION 1 概説 ## 1.1 Overview 1.1 概要 本証明書ポリシー/認証運用規程（以下、「CP/CPS」）は、セコムトラストシステムズ株式会社（以下、「セコムトラストシステムズ」）が運用する証明書の使用目的、適用範囲およびユーザー手続きを示し、証明書に関するポリシーを規定する。 セコムトラストシステムズは、CAとしての認証サービスを提供し、CA私有鍵の管理および証明書の発行/失効を含むサービス（以下、「サービス」）を提供する。 本CP/CPSは、CAに関する技術的または運用上の進展や改善を反映するために必要に応じて改訂される。 本CP/CPSは、IETFが提唱するCA実践フレームワークであるRFC3647「Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework」に準拠している。 本CP/CPSは [CCADB Policy](https://www.ccadb.org/policy) に準拠しており、英語版を正式版とし、英語版CP/CPSとバージョン番号を一致させて公開する。本CP/CPSは、英語版のSection名称の下に日本語のSection名称を記載する。 ### 1.1.1 Standards, Criteria and Regulations 1.1.1 基準、評価基準および規則 認証局（CA）は、CA/ブラウザフォーラムおよびアプリケーションソフトウェアサプライヤーによって定められた基準、評価基準、規則の最新バージョンに準拠する。 CAが従うべき監査スキームについては、[Section 8.4](#84-topics-covered-by-assessment)を参照。 表: 基準、評価基準および規則リスト | 下位CAが発行する証明書の種類 | 準拠するべき基準、評価基準および規則 | | ---------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TLSサーバー証明書 | [Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates](https://cabforum.org/baseline-requirements-documents/) (以下、"Baseline Requirements")
[Guidelines for the Issuance and Management of Extended Validation Certificates](https://cabforum.org/extended-validation/) (TLS EV証明書のみ対象。以下、"EV Guidelines" )
[Apple Root Certificate Program](https://www.apple.com/certificateauthority/ca_program.html)
[Chrome Root Program Policy](https://www.chromium.org/Home/chromium-security/root-ca-policy/)
[Microsoft Trusted Root Program](https://aka.ms/RootCert)
[Mozilla Root Store Policy](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/) | | TLSクライアント認証証明書
(以下、"クライアント認証証明書") | [Apple Root Certificate Program](https://www.apple.com/certificateauthority/ca_program.html)
[Microsoft Trusted Root Program](https://aka.ms/RootCert) | | S/MIME証明書 | [Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates](https://cabforum.org/smime-br/) (以下、"S/MIME Baseline Requirements")
[Apple Root Certificate Program](https://www.apple.com/certificateauthority/ca_program.html)
[Microsoft Trusted Root Program](https://aka.ms/RootCert)
[Mozilla Root Store Policy](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/) | | コードサイニング証明書, コードサイニング証明書向けタイムスタンプ証明書 | [Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates](https://cabforum.org/working-groups/code-signing/requirements/) (以下、"Baseline Requirements for Code Signing Certificates")
[Microsoft Trusted Root Program](https://aka.ms/RootCert) | | AATLドキュメントサイニング証明書, AATLタイムスタンプ証明書 | [Adobe Approved Trust List Technical Requirements](https://helpx.adobe.com/acrobat/kb/approved-trust-list2.html) (以下、"AATL Technical Requirements") | | Microsoftドキュメントサイニング証明書 | [Microsoft Trusted Root Program](https://aka.ms/RootCert) | \* AATLドキュメントサイニング証明書とMicrosoftドキュメントサイニング証明書は、総称して「ドキュメントサイニング証明書」という。 \* コードサイニング証明書のタイムスタンプ証明書とAATLタイムスタンプ証明書は、総称して「タイムスタンプ証明書」という。 本CAは、認証業務の一部をBaseline Requirementsに準拠した外部の事業者に委託する場合があり（以下「外部委託先」という）、二社間の契約については契約書に定める。 CP/CPSとBaseline Requirementsの間に相違がある場合、Baseline RequirementsがCP/CPSに優先して適用される。 ## 1.2 Document name and identification 1.2 文書名と識別 本CP/CPSの正式名称は「SECOM パブリックトラスト証明書ポリシー/認証運用規程」とする。 本サービスの提供者および運営主体であるセコムトラストシステムズは、ISO が割り当てたオブジェクト識別子（以下、「OID」）を使用する。 --- 表: OID (セコムトラストシステムズ株式会社) | 組織名 | OID | | -------------------------------- | -------------- | | セコムトラストシステムズ株式会社 | 1.2.392.200091 | --- Root CA から下位 CA 証明書を発行するときに使用される OID 表: OID (Root CA CP) | CP | OID | | -------------------------------------------------------- | ------------------------- | | Security Communication RootCA2 下位 CA CP | 1.2.392.200091.100.901.4 | | Security Communication RootCA2 タイムスタンプサービス CP | 1.2.392.200091.100.901.5 | | Security Communication RootCA3 下位 CA CP | 1.2.392.200091.100.901.6 | | Security Communication RootCA3 タイムスタンプサービス CP | 1.2.392.200091.100.901.7 | | SECOM RSA Root CA 2023 下位 CA CP | 1.2.392.200091.100.901.9 | | SECOM Document Signing RSA Root CA 2023 下位 CA CP | 1.2.392.200091.100.901.10 | | SECOM TLS RSA Root CA 2024 下位 CA CP | 1.2.392.200091.100.901.11 | | SECOM SMIME RSA Root CA 2024 下位 CA CP | 1.2.392.200091.100.901.12 | | Security Communication ECC RootCA1 下位 CA CP | 1.2.392.200091.100.902.1 | | SECOM TLS ECC Root CA 2024 下位 CA CP | 1.2.392.200091.100.902.3 | --- 下位 CA から EE 証明書を発行するときに使用する OID 表: OID（下位 CA CP） | CP | OID | | ------------------------------------------------------------------------------------------- | ------------------------- | | クライアント用証明書ポリシー(SHA1)
(クライアント認証証明書) | 1.2.392.200091.100.381.1 | | データ署名用証明書ポリシー (SHA1)
(ドキュメントサイニング証明書) | 1.2.392.200091.100.381.2 | | クライアント用証明書ポリシー
(クライアント認証証明書) | 1.2.392.200091.100.381.4 | | データ署名用証明書ポリシー
(ドキュメントサイニング証明書) | 1.2.392.200091.100.381.5 | | コードサイニング用証明書ポリシー (SHA256) | 1.2.392.200091.100.381.8 | | AATLドキュメントサイニング証明書ポリシー | 1.2.392.200091.100.382.1 | | S/MIME証明書ポリシー | 1.2.392.200091.100.383.1 | | SECOM Passport for Web EV CA CP | 1.2.392.200091.100.721.1 | | SECOM Passport for Web SR CA CP | 1.2.392.200091.100.751.1 | | SECOM TLS OV CP | 1.2.392.200091.100.752.1 | | SECOM TLS DV CP | 1.2.392.200091.100.752.2 | | SECOM TimeStamping CA2 | 1.2.392.200091.100.931.1 | | SECOM TimeStamping CA3 | 1.2.392.200091.100.931.3 | | SECOM TimeStamping CA4 | 1.2.392.200091.100.931.4 | | SECOM TimeStamping Service | 1.2.392.200091.100.931.5 | | SECOM Trust Systems Subordinate Advanced CA
(Security Communication RootCA3から発行) | 1.2.392.200091.100.999.11 | | SECOM Trust Systems Subordinate Advanced CA
(Security Communication ECC RootCAから発行) | 1.2.392.200091.100.999.13 | | SC Domain Validation CA1 | 1.2.392.200091.110.213.1 | | SC Domain Validation CA2 | 1.2.392.200091.110.213.2 | | SC Organization Validation CA2
(Security Communication Root CA2から発行) | 1.2.392.200091.110.214.2 | | SC Organization Validation CA3
(Security Communication Root CA2から発行) | 1.2.392.200091.110.214.3 | | SC Organization Validation CA4
(Security Communication ECC RootCA1から発行) | 1.2.392.200091.110.214.4 | --- ### 1.2.1 Revisions 1.2.1 改訂 | **Ver.** | **日付** | **内容** | | -------- | ---------- | -------- | | 1.00 | 2025-05-26 | 初版 | ## 1.3 PKI Participants 1.3 PKI関係者 ### 1.3.1 Certification Authorities 1.3.1 認証局（CA） CAは、証明書の作成、発行、失効および管理を担当する組織である。CAはCRL (Certificate Revocation List)を公開し、OCSPレスポンダーを使用して証明書の状態に関する情報を保存および提供する。 CAは、[Section 1.6](#16-definitions-and-acronyms)で定義されている用語である。 ### 1.3.2 Registration Authorities 1.3.2 登録局（RA） [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control)および[Section 3.2.2.5](#3225-authentication-for-an-ip-address)を除いて、CAは[Section 3.2](#32-initial-identity-validation)の要件のすべてまたは一部の実行を外部委託先に委任することができる。ただし、プロセス全体が[Section 3.2](#32-initial-identity-validation)の要件をすべて満たしている場合に限る。 CAが外部委託先に委任機能を実行する権限を与える前に、CAは契約上、外部委託先に以下のいずれかを要求しなければならない。 1. 委託した職務に該当する場合、[Section 5.3.1](#531-qualifications-experience-and-clearance-requirements),の資格要件を満たす。 2. [Section 5.5.2](#552-retention-period-for-archive)に従い、ドキュメントを保持する。 3. Baseline Requirements以外にも、委託された職務に適用される条件を遵守する。 4. 以下のいずれかに準拠する。a). CAのCP/CPS b). CAがBaseline Requirementsに準拠していることを認定した委託先の運用規定 CAはEnterprise RAを指定して、そのEnterprise RAの組織からの証明書要求を検証することができる。 Enterprise RAが承認した証明書要求を受け付けるには、以下のいずれかの要件が満たされていなければならない。 1. CAは要求されたFQDNがEnterprise RAの検証済みドメインネームスペース内にあることを確認する。 2. 証明書要求にFQDN以外の種類の主体者識別名が含まれている場合、CAはその名前が委任された企業のもの、または委任された企業の関連会社のもの、または委任された企業が指定された主体者識別名の代理人であることを確認する。例えば、CAは「XYZ Co.」という主体者識別名を含む証明書をEnterprise RA「ABC Co.」の権限で発行してはならない。ただし、両社が関連している（[Section 3.2](#32-initial-identity-validation)を参照）か、「ABC Co.」が「XYZ Co.」の代理人である場合を除く。この要件は、要求された主体者識別名にあるFQDNがABC Co.の登録されたドメイン名のネームスペース内にあるかどうかに関係なく適用される。 CAはこれらの制限を契約上の要件としてEnterprise RAに課し、Enterprise RAによる遵守を監視する。 **[ドキュメントサイニング証明書およびクライアント認証証明書]** LRAは、RAに代わって証明書の利用者の存在とその身元の確認、証明書の発行と失効のための登録などを行う組織である。事前にRAによってレビューされ、確認された特別な組織や団体がこの役割を果たすことができる。LRAは、RAと同様に、CP/CPSに定められた事項を遵守しなければならない。なお、LRAは、クライアント用証明書ポリシーまたはデータ署名用証明書ポリシーが適用される場合にのみ業務を行うことができる。 #### 1.3.2.1 Enterprise registration authorities (S/MIME Certificates) 1.3.2.1 Enterprise RA (S/MIME 証明書) CAは、Enterprise RAに対して、Enterprise RA自身の組織内の主体者識別名に対する証明書リクエストを検証することを委任することができる。CAは、以下の要件が満たされない限り、Enterprise RAによって承認された証明書リクエストを受け付けてはならない。 証明書リクエストがMailbox-validatedプロファイルの場合、CAは、Enterprise RAが要求されたメールドメインに対する承認または管理権限を持っていることを[Section 3.2.2.1.1](#32211-validating-authority-over-mailbox-via-domain-smime-certificates)または[Section 3.2.2.1.3](#32213-validating-applicant-as-operator-of-associated-mail-servers-smime-certificates)に従って確認しなければならない。 CAは、これらの制限をEnterprise RAに対する契約上の要件として課し、[Section 8.8](#88-review-of-delegated-parties)に従ってEnterprise RAの遵守を監視しなければならない。 Enterprise RAは、委任された組織の承認または管理下にないユーザーのために、Mailbox-validatedプロファイルを使用して証明書リクエストを提出することもできる。この場合、CAは、要求されたメールボックスアドレスに対するメールボックス保有者の管理権限を[Section 3.2.2.1.2](#32212-validating-control-over-mailbox-via-email-smime-certificates)に従って確認しなければならない。 ### 1.3.3 Subscribers 1.3.3 利用者 利用者とは、CA が発行した証明書を受け取り、利用者契約または利用規約に準拠する自然人または法人を指す。 利用者は、CA が発行する証明書の対象となる鍵ペアを自らの権利で生成する。利用者は、CA に証明書の申請を提出し、発行された証明書を受理した時点で利用者としての資格を得る。利用者は、使用目的に照らして本条項を評価し、これに同意する必要がある。 ### 1.3.4 Relying Parties 1.3.4 検証者 検証者とは、有効な証明書を依拠する自然人または法人を指す。アプリケーションソフトウェアサプライヤーによって配布されるソフトウェアが単に証明書に関連する情報を表示するだけの場合、そのサプライヤーは検証者とは見なされない。 検証者は、CAが発行する証明書の有効性を認証する存在である。検証者は、自らの利用目的に照らして、本条項の内容を確認し同意した上で、認証および信認を行うものとみなされる。 「検証者」および「アプリケーションソフトウェアサプライヤー」は、[Section 1.6.1](#161-definitions)で定義されている。アプリケーションソフトウェアサプライヤーであるCA/ブラウザフォーラムの現在のメンバーは、次の URL にリストされている: 。 ### 1.3.5 Other Participants 1.3.5 その他関係者 その他関係者とは、監査人やセコムトラストシステムズとの間でサービス契約等が存在する企業や組織、そのシステムインテグレーションを行う事業者などが含まれる。 ## 1.4 Certificate Usage 1.4 証明書の用途 ### 1.4.1 Appropriate Certificate Uses 1.4.1 適切な証明書の用途 CAは、下位CAの最上位として機能する認証局であり、利用者証明書として下位CA証明書を発行する。証明書を信頼して使用する検証者は、CA公開鍵証明書を使用して、そのような証明書の信頼性を認証できる。 TLS下位CAによって発行される証明書は、TLSプロトコルを介して Web ベースのデータ通信経路を確立し、実行可能コードの信頼性を検証することを目的としている。 EV証明書の主な目的は次のとおりである。 1. Web サイトを管理する法人を特定する。 インターネットブラウザのユーザーに対して、ユーザーがアクセスしている Web サイトが、EV証明書で名前、事業所の住所、設立または登録の管轄、登録番号、またはその他の明確な情報によって識別される特定の法人によって管理されているという合理的な保証を提供する。 2. Web サイトとの暗号化通信を有効にする。 インターネットブラウザのユーザーと Web サイトの間でインターネットを介した情報の暗号化通信を可能にするために、暗号化キーの交換を容易にする。 EV証明書の 2 番目の目的は、Web サイトの運営や実行可能コードの配布を主張する企業の正当性を確立し、フィッシング、マルウェア、その他のオンラインID詐欺に関連する問題に対処するための手段を提供することである。EV証明書は、企業に関する信頼性の高い第三者による検証済みID情報と住所情報を提供することで、次のことに役立つ。 1. 証明書を使用したフィッシングやその他のオンラインID詐欺攻撃をより困難にする。 2. フィッシング攻撃やオンラインID詐欺の標的となる可能性のある企業に、ユーザーに対して自社の身元をより正確に特定できるツールを提供することで、企業を支援する。 3. 適切な場合には対象者に連絡し、調査し、法的措置を講じるなど、フィッシングやその他のオンラインID詐欺の捜査において法執行機関を支援する。 ### 1.4.2 Prohibited Certificate Uses 1.4.2 禁止される証明書の用途 TLS下位CAが発行する証明書は、通信ルーティングにおけるサーバー認証およびデータ暗号化以外の目的には使用されない。CAは、[Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) に従って検証されたドメイン所有者から、ドメインの使用権限があることが確認されない限り、証明書の発行を許可しない。 EV証明書は、証明書に指定されている主体者の身元のみに焦点を当てており、主体者の動作には焦点を当てていない。したがって、EV 証明書は、以下のことを保証したり、表明または保証したりすることを目的としてはいない。 1. EV証明書に名前が記載されている対象者が積極的にビジネスに従事している。 2. EV証明書に指定されている対象者が適用法を遵守している。 3. EV証明書に名前が記載されている対象者が、ビジネス取引において信頼できる、誠実である、または評判が良い。 4. EV証明書に指定されている主体者と取引するのが「安全」である。 ## 1.5 Policy administration 1.5 ポリシー管理 ### 1.5.1 Organization Administering the Document 1.5.1 文書を管理する組織 本CP/CPSは、セコムトラストシステムズによって維持・管理されている。 ### 1.5.2 Contact Person 1.5.2 連絡先 本CP/CPSに関する問い合わせ先は次のとおりである。 | 問い合わせ窓口 | セコムトラストシステムズ株式会社 CAサポートセンター | | -------------- | --------------------------------------------------- | | 住所 | 181-8528 東京都三鷹市下連雀8-10-16 | | 問い合わせ内容 | 本CPに関する問い合わせ / 証明書に関する問題報告（Certificate Problem Report）を除く | | -------------- | ----------------------------------------------------------------------------------- | | Email | ca-support [at] secom [dot] co [dot] jp | | 受付対応時間 | 9:00～18:00（土日・祝日および年末年始を除く） | 利用者、検証者、アプリケーションソフトウェアサプライヤー、その他の第三者は、私有鍵危殆化の疑い、証明書の誤用、あるいはその他の種類の詐欺、危殆化、誤用、不適切 な行為、または証明書に関連するその他の事項について、以下の連絡先に報告することができる。本CAでは、失効する必要があると判断した場合、証明書を失効する。 | 問い合わせ内容 | 証明書に関する問題報告（Certificate Problem Report） | | -------------- | ------------------------------------------------------- | | URL | | | 受付対応時間 | 24時間365日（24x7） | ### 1.5.3 Person Determining CPS suitability for the policy 1.5.3 ポリシー適合性決定者 本CP/CPSの内容については、認証サービス改善委員会（以下「本委員会」という）が適合性を決定する。本CP/CPSは、最低でも年次でレビューし、改訂される。 ### 1.5.4 CPS approval procedures 1.5.4 CPS承認手続 本CP/CPSは、セコム認証サービス改善委員会の承認のもとで作成および改訂され、リポジトリーに公開される。 本CP/CPSは、CAに対するこの委員会の承認をもって発効する。 ## 1.6 Definitions and Acronyms 1.6 定義と頭字語 ### 1.6.1 Definitions 1.6.1 定義 **AATL (Adobe Approved Trust List)**: 署名された文書を Adob​​e® Acrobat® または Acrobat® Reader® ソフトウェアで開くたびに信頼されるデジタル署名を作成できるプログラム。 **ADN (Authorization Domain Name)**: 特定の FQDN の証明書発行の認証を取得するために使用されるドメイン名。 **Affiliate (関連会社)**: 別の団体を支配する、別の団体により支配される、または別の団体と共通の支配下にある法人、パートナーシップ、合弁企業、またはその他の団体、あるいは政府組織の直接の支配下で運営されている機関、部門、行政区分、または団体。 **Applicant (申請者)**: 証明書を申請する（または更新を求める）自然人または法人。証明書が発行されると、申請者は利用者と呼ばれる。デバイスに発行される証明書の場合、デバイスが実際の証明書要求を送信している場合でも、申請者は証明書に指定されたデバイスを制御または操作するエンティティである。 **Applicant Representative (申請権限者)**: 申請者、申請者によって雇用されている、または申請者から委任された代理人である個人または保証人として、 i. 申請者に代わって証明書要求に署名して提出する、または承認する者、 ii. 申請者を代表して利用者契約に署名して提出する者、または iii. 申請者がCAの関連会社またはCAである場合に、申請者に代わって証明書利用規約に同意する者を意味する。 **Application Software Supplier (アプリケーションソフトウェアサプライヤー)**: 証明書を表示または使用し、ルート証明書を組み込むインターネットブラウザソフトウェアまたはその他の検証者アプリケーションソフトウェアのサプライヤー。 **Archive (アーカイブ)**: 法律上またはその他の理由により履歴を保存する目的で取得された情報。 **Attestation Letter (意見書)**: 会計士、弁護士、政府職員、または慣例上信頼のおける第三者機関により文書化された、サブジェクト情報が正しいものであることを証明する証書。 **Audit Log (監査ログ)**: CAシステムへのアクセスや不正な操作を検査するために記録される、CA システムに関連する行動、アクセス、その他の履歴。 **Audit Period (監査期間)**: 期間監査では、監査人が監査業務の対象とする初日（開始）から業務の最終日（終了）までの期間になる。（これは、監査人がCAの現場にいる期間とは異なる）監査期間の対象範囲のルールと最大期間は、[Section 8.1](#81-frequency-or-circumstances-of-assessment) で定義されている。 **Audit Report (監査レポート)**: 組織のプロセスと管理が Baseline Requirements の必須規定に準拠しているかどうかについての公認監査人の意見を記載した、公認監査人からのレポート。 **Authorization Domain Name (認証ドメイン名)**: 証明書に含まれる特定のFQDNの証明書発行の承認を取得するために使用されるFQDN。CAは、DNS CNAMEルックアップから返されたFQDNを、ドメイン検証のためのFQDNとして使用できる。FQDNにワイルドカードドメイン名が含まれている場合、証明書に含めるには、CAはワイルドカードドメイン名の左端の部分から「*」を削除して、対応するFQDNを生成する必要がある。CAは、ベースドメイン名に遭遇するまで、FQDNの0個以上のドメインラベルを左から右にプルーニングし、ドメイン検証の目的でプルーニングによって生成された値（ベースドメイン名自体を含む）のいずれかを使用できる。 **Authorized Ports (認証ポート)**: 次のポートのいずれか：80(http)、443(https)、115(sftp)、25(smtp)、22(ssh) **Base Domain Name (基本ドメイン名)**: 申請されたFQDNのうち、レジストリ制御またはパブリックサフィックスの左側にある最初のドメイン名ノードと、レジストリ制御またはパブリックサフィックス (例: 「example.co.jp」または「example.com」) の部分。右端のドメイン名ノードが、レジストリ契約に ICANN 仕様 13 が含まれる gTLD である FQDN の場合、gTLD 自体をベースドメイン名として使用できる。 **Baseline Requirements**: CA/ブラウザフォーラム (cabforum.org で入手可能) によって発行された、証明書の発行/管理に関する一連の基本的な要件を統合したドキュメント。 **Business Entity (事業体)**: ここで定義される民間組織、政府組織、または非営利団体ではない団体。例としては、合名会社、非法人団体、個人事業主などが含まれるが、これらに限定されない。 **CAA**: RFC 8659 ()から引用:「認証局認可 (CAA) DNSリソースレコードを使用すると、DNSドメイン名の所有者は、そのドメイン名の証明書を発行する認可を受けた 1 つ以上の認証局(CA)を指定できる。CAAリソースレコードを使用すると、パブリックCAは追加の制御を実装して、意図しない証明書の誤発行のリスクを軽減できる。」 **CA/Browser Forum (CA/ブラウザフォーラム)**: CAとインターネットブラウザベンダーによって組織され、証明書発行要件の定義と標準化に取り組んでいるNPO。 **CA Key Pair (CA鍵ペア)**: 公開鍵が 1 つ以上のルートCA証明書/下位CA証明書のサブジェクト公開鍵情報として表示される鍵ペア。 **Certificate (証明書)**: デジタル署名を使用して公開鍵とIDを結び付ける電子文書。 **Certificate Approver (証明書承認者)**: 申請者本人、申請者に雇用されている者、または申請者を代理する明示的な権限を有する代理人である自然人。 i. 証明書要求者として行動し、他の従業員または第三者が証明書要求者として行動することを許可する。 ii. 他の証明書要求者によって提出されたEV証明書要求を承認する。 **Certificate Data (証明書データ)**: CAが所有または管理している、またはCAがアクセスできる証明書要求およびそれに関連するデータ（申請者から取得したかどうかに関係なく）。 **Certificate Management Process (証明書管理プロセス)**: CAが証明書データを検証し、証明書を発行し、リポジトリーを維持し、証明書を失効するために使用する、キー、ソフトウェアおよびハードウェアの使用に関連するプロセス、運用および手順。 **Certificate Policy (CP) (証明書ポリシー)**: 共通のセキュリティ要件を持つ特定のコミュニティや PKI 実装への名前付き証明書の適用可能性を示す一連のルール。 **Certificate Problem Report (証明書問題レポート)**: 鍵危殆化の疑い、証明書の不正使用、または証明書に関連するその他の種類の詐欺、危殆化、不正使用、あるいは不適切な行為についての報告。 **Certificate Profile (証明書プロファイル)**: [Section 7](#7-certificate-crl-and-ocsp-profiles)に従って、証明書の内容と証明書の拡張の要件を定義する一連のドキュメントまたはファイル。例えばCAのCPSのSection、またはCAソフトウェアで使用される証明書テンプレートファイル。 **Certificate Requester (証明書要求者)**: 申請者、申請者に雇用されている者、申請者を代表する明示的な権限を持つ認定代理人、または申請者に代わってEV証明書リクエストを完了して提出する第三者(ISP やホスティング会社など) のいずれかである自然人。 **Certificate Revocation List (CRL) (証明書失効リスト)**: 証明書を発行したCAによって作成され、デジタル署名された、定期的に更新される、タイムスタンプ付きの失効した証明書のリスト。 **Certificate Signing Request (CSR) (証明書署名要求)**: CSR は Certificate Signing Request (証明書署名要求) の略で、デジタル証明書の発行のベースとなるデータファイルである。CSRには証明書の署名を要求するエンティティの公開鍵が含まれており、証明書の発行時に発行者のデジタル署名が添付される。 **Certificate Transparency (CT) (証明書の透明性)**: RFC 6962 で規定されている証明書の透明性は、発行された証明書の記録をログサーバーに登録して公開することで、その記録を監視/監査するためのオープンフレームワークである。 **Certification Authority (CA) (認証局)**: 証明書の作成、発行、失効および管理を担当する組織。この用語は、ルートCAと下位CAの両方に適用される。 **Certification Practice Statement (認証運用規程)**: 証明書が作成、発行、管理および使用されるガバナンスフレームワークを形成する複数のドキュメントの 1つ。 **Certification Services Improvement Committee (認証サービス改善委員会)**: 本CP/CPSの管理および変更レビューを含む、サービスの運用ポリシーに関する意思決定機関。 **Code (コード)** : コードサイニング証明書に対応する私有鍵を使用してデジタル署名されているか、または署名できる連続したビットセット。 **Code Signature (コードサイニング)**: 署名されたコードに論理的に関連付けられた署名。 **Code Signing Certificate (コードサイニング証明書)**: コードサイニングEKUを含むCAによって発行されたデジタル証明書。 **Confirmation Request (確認要求)**: 問題となっている特定の事実の検証または確認を要求する適切な別経路の通信手段。 **Confirming Person (確認者)**: 問題となっている特定の事実を確認する申請者の組織内のポジション。 **Contract Signer (契約署名者)**: 申請者、申請者に雇用されている者、または申請者を代表する明示的な権限を持ち、申請者に代わって利用者契約に署名する権限を持つ代理人である自然人。 **Control (支配)**:「支配」（およびその相関的な意味である「支配される」および「共通の支配下にある」）とは、直接的または間接的に、（1）当該事業体の経営、人事、財務、または計画を指揮する、（2）取締役の過半数の選出を支配する、または（3）当該事業体の設立管轄または登録の管轄の法律に基づいて「支配」に必要な議決権株式の割合（ただし、いかなる場合も10％未満ではない）に投票する権限を有することを意味する。 **Country (国)**: 国際連合の加盟国、または少なくとも 2 つの国際連合加盟国によって主権国家として認められている地理的地域。 **Cross-Certified Subordinate CA Certificate (クロス認証下位CA証明書)**: 2 つのCA間の信頼関係を確立するために使用される証明書。 **CSPRNG**: 暗号化システムで使用することを目的とした乱数生成器。 **Delegated Third Party (外部委託先)**: CAではないが、CAによって承認され、その活動が適切なCA監査の範囲外であり、ここに記載されている 1 つ以上のCA要件を実行または満たすことによって証明書管理プロセスを支援する自然人または法人。 **Digital Certification Infrastructure (電子認証基盤)**: セコムトラストシステムズのCAおよびプライベートCA利用者のCAを運用するためのプラットフォーム。 **DNS CAA Email Contact (DNS CAA Email連絡先)**: [Appendix A.1.1](#a11-caa-contactemail-property)で定義されたEmailアドレス。 **DNS CAA Phone Contact (DNS CAA電話連絡先)**: [Appendix A.1.2](#a12-caa-contactphone-property)で定義された電話番号。 **DNS TXT Record Email Contact (DNS TXT Record Email連絡先)**: [Appendix A.2.1](#a21-dns-txt-record-email-contact)で定義されたEmailアドレス。 **DNS TXT Record Phone Contact (DNS TXT Record 電話連絡先)**: [Appendix A.2.2](#a22-dns-txt-record-phone-contact)で定義された電話番号。 **Domain Contact (ドメイン連絡担当者)**: ベースドメイン名のWHOISレコードまたはDNS SOAレコードに記載されている、もしくはドメイン名レジストラとの直接の連絡を通じて取得されたドメイン名登録者、技術担当者、あるいは管理担当者 (または ccTLD における同等の担当者)。 **Domain Label (ドメインラベル)**: RFC 8499 ()から引用:「ドメイン名の一部を構成する0個以上のオクテットの順序付きリスト。グラフ理論を使用して、ラベルはすべての可能なドメイン名のグラフの一部で1つのノードを識別する。」 **Domain Name (ドメイン名)**: ドメインネームシステムのノードに割り当てられた1つ以上のドメインラベルの順序付きリスト。 **Domain Namespace (ドメイン名前空間)**: ドメインネームシステム内の単一ノードに従属するすべての可能なドメイン名のセット。 **Domain Name Registrant (ドメイン名登録者)**: ドメイン名の「所有者」と呼ばれることもあるが、より正確には、WHOISまたはドメイン名レジストラによって「登録者」としてリストされている自然人または法人など、ドメイン名の使用方法を制御する権利を持つとしてドメイン名レジストラに登録された個人または団体を指す。 **Domain Name Registrar (ドメイン名登録機関)**: 以下の主催または契約に基づいてドメイン名を登録する個人または団体: i. the Internet Corporation for Assigned Names and Numbers (ICANN) ii. 全国的なドメイン名機関/レジストリ iii. ネットワーク情報センター（その関連会社、契約者、代理人、後継者、譲受人を含む） **Enterprise RA (エンタープライズRA)**: 組織への証明書の発行を認定するCAの関連会社ではない当該組織の従業員または代理人。 **Escrow (エスクロー)**: エスクローとは、資産を独立した第三者の管理下に置く（委託する）ことを意味する。 **EV Authority (EVオーソリティ)**: 証明書承認者以外のソース。これを通じて、EV証明書要求の日付時点で、証明書承認者が申請者によってEV Guidelinesに記載されている要求アクションを実行することを明示的に承認されていることが確認される。 **EV Certificate (EV証明書)**: EV Guidelinesで指定された主体者情報を含み、EV Guidelinesに従って検証された証明書。 **EV Certificate Beneficiaries (EV証明書受益者)**: CAおよびそのルートCAが特定のEV証明書の保証を行う対象者。 **EV Certificate Renewal (EV証明書更新)**: 有効期限が切れておらず、失効されていない有効なEV証明書を持つ申請者が、元の証明書を発行したCAに対して、申請者の既存のEV証明書の有効期限が切れる前に、同じ組織名とドメイン名に対して、現在のEV証明書の有効期限を超えた新しい「有効期限」を持つ、新しく発行されたEV証明書を申請するプロセス。 **EV Certificate Reissuance (EV証明書再発行)**: 有効期限が切れておらず、失効されていない有効なEV証明書を持つ申請者が、元の証明書を発行したCAに対して、申請者の既存のEV証明書の有効期限が切れる前に、同じ組織名とドメイン名に対して、現在のEV証明書の有効期限と一致する新しいEV証明書の発行を申請するプロセス。 **EV Certificate Request (EV証明書リクエスト)**: 申請者からCAへのリクエストであり、CAが申請者にEV証明書を発行することを要求するもので、このリクエストは申請者によって有効に承認され、申請者の代表者によって署名されている。 **EV Certificate Warranties (EV証明書保証)**: EV証明書を発行するCAと連携して、CAとそのルートCAは、EV証明書の有効期間中、EV証明書の発行およびEV証明書に含まれる情報の正確性の検証において、CAがこれらのガイドラインおよびCAのEVポリシーの要件に従っていることを約束する。 **EV OID**: 次の証明書の `certificatePolicies`フィールドに含まれる、「オブジェクト識別子」形式の識別番号。 i. どのCAポリシーステートメントがその証明書に関係するかを示す ii. CA/ブラウザフォーラムのEVポリシー識別子、または 1 つ以上のアプリケーションソフトウェアサプライヤーとの事前合意により、証明書がEV証明書であることを示すポリシー識別子のいずれかである。 **EV Policies (EVポリシー)**: CAとそのルートCAによって開発、実装および強制される、CPSやCPなどの監査可能なEV証明書の実施、ポリシーおよび手順。 **EV Processes (EVプロセス)**: CAがこのガイドラインに従って証明書データを検証し、EV証明書を発行し、リポジトリーを維持し、EV証明書を失効するために使用するキー、ソフトウェア、プロセスおよび手順。 **Extended Validation Certificate (EV証明書)**: EV証明書を参照。 **Expiry Date (有効期限)**: 証明書の有効期間の最終日を定義する証明書内の有効期間の終了日付。 **FIPS140**: 米国NIST（国立標準技術研究所）が開発した暗号モジュールのセキュリティ認証規格。 **HSM (Hardware Security Module) (ハードウェア セキュリティ モジュール)**: 暗号化とデジタル署名に使用される私有鍵を保管するための保護金庫として機能するハードウェア。HSMは暗号化とデジタル署名を計算し、私有鍵とランダムな数字を生成する。 **Fully-Qualified Domain Name (FQDN)**: インターネットドメインネームシステム内のすべての上位ノードのドメインラベルを含むドメイン名。 **Government Agency (政府機関)**: 民間組織の場合、設立管轄区域内の政府機関であり、その権限に基づいて民間組織の法的存在が確立される (例: 設立証明書を発行した政府組織)。事業体の場合、事業体を登録する運営管轄区域内の政府機関。政府機関の場合、政府機関の法的存在を確立する法律、規則、または命令を制定する機関。 **Government Entity (政府組織)**: 国、またはその国内の行政区分 (州、県、市、郡など) の政府が運営する法人、機関、部署、省、支部、または同様の政府機関。 **High Risk Certificate Request (ハイリスク証明書のリクエスト)**: CAが管理する内部基準とデータベースを参照して追加の精査を行うようCAがフラグを立てるリクエスト。これには、フィッシングやその他の不正使用のリスクが高い名前、以前に拒否された証明書リクエストや失効された証明書に含まれる名前、Miller Smiles phishing list または Google Safe Browsing list に記載されている名前またはCAが独自のリスク軽減基準を使用して識別した名前が含まれる場合がある。 **Incorporating Agency (設立機関)**: 民間組織の説明では、法人設立管轄区域内の政府機関であり、その権限に基づいて法人の法的存在が登録される (例: 設立証明書または法人設立証明書を発行する政府機関)。政府組織の説明では、政府機関の法的存在を確立する法律、規則、または命令を制定する機関である。 **Independent Confirmation From Applicant (申請者から独立した確認)**: EV Guidelinesの規定に従ってCAが受け取った、または申請者に対して拘束力を持つ特定の事実の確認。 **Internal Name (内部名)**: 証明書のコモンネームまたはSubject Alternative Nameフィールド内に記載されている文字列(IPアドレスではない)で、IANAのルートゾーンデータベースに登録されたトップレベルドメインで終了していないために、証明書発行時点においてパブリックDNS内でグローバルに一意として認証できないもの。 **Individual (個人)**: 自然人。 **INAN (Internet Assigned Numbers Authority) (インターネット割り当て番号機関)**: IPアドレスやポート番号など、インターネットに関連する情報を世界的に管理する組織。 **International Organization (国際組織)**: 少なくとも 2 つの主権国家政府によって、またはそれらの政府に代わって署名された憲章、条約、協定、または類似の文書などの構成文書によって設立された組織。 **Issuing Authority (IA) (発行局)**: CAの職務のうち、証明書の発行/更新/失効、CA私有鍵の生成と保護、リポジトリーの保守と管理を主に扱う組織。 **IP Address (IPアドレス)**: 通信にインターネットプロトコルを使用するデバイスに割り当てられた32ビットまたは128ビットの番号。 **IP Address Contact (IPアドレス連絡先)**: 1 つ以上のIPアドレスの使用方法を制御する権利を持つとしてIPアドレス登録機関に登録された個人または団体。 **IP Address Registration Authority (IPアドレス登録局)**: Internet Assigned Numbers Authority (IANA) または地域インターネットレジストリー (RIPE、APNIC、ARIN、AfriNIC、LACNIC)。 **Issuing CA (発行CA)**: 特定の証明書に関連して、証明書を発行したCA。これはルートCAまたは下位CAのいずれかになる。 **Key Compromise (鍵危殆化)**: 私有鍵が権限のない人物に開示された場合、または権限のない人物が私有鍵にアクセスした場合、私有鍵は危殆化されたとみなされる。 **Key Generation Script (鍵生成スクリプト)**: CA鍵ペアの生成手順が記述された計画書。 **Key Pair (鍵ペア)**: 私有鍵とそれに関連付けられた公開鍵。 **LDH Label (LDHラベル)**: RFC 5890 ()から引用: 「ASCII 文字、数字、ハイフンで構成される文字列。さらに、ハイフンは文字列の先頭または末尾に出現できないという制限がある。すべての DNS ラベルと同様に、合計の長さは 63 オクテットを超えてはならない。」 **Legal Entity (法人)**: 国の法制度において法的地位を持つ協会、法人、パートナーシップ、個人事業体、信託、政府組織、またはその他の団体。 **Legal Existence (法的存在)**: 民間組織、政府組織、または事業体は、有効に設立され、終了、解散、または放棄されていない場合、法的な存在となる。 **Legal Practitioner (法務担当者)**: EV Guidelinesに記載されている弁護士またはラテン公証人のいずれかであり、申請者の事実上の主張について意見を述べる資格を有する者。 **Linting (リンティング)**: 事前証明書 [RFC 6962]、証明書、証明書失効リスト、OCSP 応答などのデジタル署名されたデータ、または `tbsCertificate` ( [RFC 5280, Section 4.1.1.1](https://tools.ietf.org/doc/html/rfc5280##section-4.1.1.1)で説明された) などの署名対象データ オブジェクトの内容が、Baseline Requirements で定義されたプロファイルおよび要件に準拠しているかどうかをチェックするプロセス。 **Major Version Number (メジャーバージョン番号)**: 利用者および検証者による証明書および CRL の使用に明らかな影響を及ぼすと考えられる修正の規模が大きいCP/CPSの改訂に付与される番号（例：バージョン1.02の下線付き数字[1]）。 **Minor Version Number (マイナーバージョン番号)**: 利用者および検証者による証明書および CRL の使用にまったく影響を与えないか、または影響が小さいと考えられるCP/CPSの改訂に付与される番号（例：バージョン1.02の下線付き数字[02]）。 **Multi-Perspective Issuance Corroboration (マルチパースペクティブ発行検証)**: プライマリーネットワークパースペクティブによるドメイン検証およびCAAチェック中に行われた決定が、証明書の発行前に他のネットワークパースペクティブによって裏付けされるプロセス。 **Network Perspective (ネットワークパースペクティブ)**: マルチパースペクティブ発行検証に関連。ドメイン制御検証方法やCAAチェックに関連付けられた送信インターネットトラフィックを送信するためのシステム (クラウドホストサーバーインスタンスなど) またはネットワークコンポーネントのコレクション (VPNおよび対応する基盤など)。ネットワークパースペクティブの場所は、カプセル化されていない送信インターネットトラフィックが通常、そのパースペクティブへのインターネット接続を提供するネットワーク基盤に最初に渡されるポイントによって決定する。 **Network Time Protocol (NTP) (ネットワークタイムプロトコル)**: ネットワーク経由でコンピュータの内部クロックを正しく調整するためのプロトコル。 **Non-Reserved LDH Label (予約されていないLDHラベル)**: RFC 5890 () からの引用: 「3 番目と 4 番目の位置に '--' が含まれない有効なLDHラベルのセット。」 **Object Identifier (オブジェクト識別子)**: 国際標準化機構(ISO)の標準に従って登録された、特定のオブジェクトまたはオブジェクトクラスに対応する一意の英数字または数字の識別子。 **OCSP Responder (OCSPレスポンダー)**: CAの権限の下で運用され、証明書ステータス要求を処理するためにリポジトリーに接続されたオンラインサーバー。オンライン証明書ステータスプロトコルも参照のこと。 **Onion Domain Name (オニオンドメイン名)**: RFC7686「.onion」特殊用途ドメイン名で終わるFQDN。たとえば、`2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion`はオニオンドメイン名だが、`torproject.org`はオニオンドメイン名ではない。 **Online Certificate Status Protocol (オンライン証明書ステータスプロトコル)**: 検証者アプリケーションソフトウェアが識別された証明書のステータスを判断できるようにするオンライン証明書チェックプロトコル。OCSPレスポンダーも参照のこと。 **Parent Company (親会社)**: 子会社を支配する会社。 **Pending Prohibition​ (禁止保留中)​**: このラベルで説明されている動作の使用は、推奨されないことが予定されており、将来的には MUST NOT と指定される可能性が高いため推奨できない。 **Place of Business (事業所)**: 申請者の事業が行われている施設（工場、小売店、倉庫など）の所在地。 **Principal Individual (代表個人)**: 雇用上の肩書により識別される、民間組織、政府組織、または事業体の所有者、パートナー、管理メンバー、取締役または役員のいずれかである個人、または、EV 証明書の要求、発行および使用に関連する業務を行うために当該事業体または組織によって承認された従業員、請負業者、または代理人。 **Precertificate (事前証明書)**: 事前証明書は、RFC 6962 で定義されているように、証明書の透明性ログに送信できる署名済みデータ構造である。事前証明書は、CAが証明書の発行を決定した後、証明書が実際に署名される前に作成される。CAは、CTログに送信する目的で、証明書に対応する事前証明書を作成して署名することができる。CAは、返された署名済み証明書タイムスタンプを使用して、証明書の拡張フィールドを変更し、[Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) で定義され、関連するプロファイルで許可されているように、署名済み証明書タイムスタンプ リストを追加してから、証明書に署名することができる。 **Primary Network Perspective (プライマリーネットワークパースペクティブ)**: CAが 1) 要求されたドメインまたは IP アドレスに対して証明書を発行するCAの権限および 2) 要求されたドメインまたは IP アドレスに対する申請者の権限/ドメイン承認または制御を決定するために使用するネットワークパースペクティブ。 **Private Organization (民間団体)**: 設立管轄区域内の設立機関またはその同等機関への申請（またはその行為）によって存在が確立された非政府法人（所有権が非公開か公開かに関わらず）。 **Private Key (私有鍵)**: 鍵ペアの所有者によって秘密に保持され、デジタル署名を作成したり、対応する公開鍵で暗号化された電子記録やファイルを復号化するために使用される鍵ペアの鍵。 **Public Key (公開鍵)**: 対応する私有鍵の所有者によって公開される可能性のある鍵ペアの鍵であり、検証者が所有者の対応する私有鍵で作成されたデジタル署名を検証したり、メッセージを暗号化して所有者の対応する私有鍵でのみ復号化できるようにするために使用される。 **Public Key Infrastructure (公開鍵基盤)**: 公開鍵暗号化技術に基づいた信頼できる証明書および鍵の作成、発行、管理および使用を促進するために使用される一連のハードウェア、ソフトウェア、人、手順、ルール、ポリシーおよび義務。 **Publicly-Trusted Certificate (パブリックトラスト証明書)**: 対応するルート証明書が、広く利用可能なアプリケーションソフトウェアで信頼アンカーとして配布されているという事実によって信頼される証明書。 **P-Label (P-ラベル)**: 5 番目以降の位置からの Punycode アルゴリズム (RFC 3492、Section 6.3 で定義) の有効な出力を含む XN ラベル。 **Qualified Auditor (公認監査人)**: [Section 8.2](#82-identityqualifications-of-assessor)の要件を満たす自然人または法人。 **Qualified Government Information Source (認定政府情報源)**: [Section 3.2.2.2.10.6](#3222106-qualified-government-information-source) の要件を満たす政府組織によって管理されるデータベース (SEC 提出書類など)。 **Qualified Independent Information Source (認定独立情報源**: 定期的に更新され、最新の公開データベースであり、参照される情報を正確に提供することを目的として設計されており、そのような情報の信頼できる情報源として一般に認識されている。 **Random Value (ランダム値)**: 少なくとも 112 ビットのエントロピーを示す、CAによって申請者に指定された値。 **Registered Domain Name (登録ドメイン名)**: ドメイン名レジストラに登録されたドメイン名。 **Registration Authority (RA) (登録局)**: 証明書の主体者識別名の識別および認証を担当する法人組織。ただし、CAではないため、証明書の署名や発行は行わない。RAは、証明書申請プロセスまたは失効プロセス、あるいはその両方を支援する場合がある。「RA」が役割や機能を指すために用いられる場合は、必ずしも別の組織体を示唆するものではなく、CAの一部である可能性がある。 **Reliable Data Source (信頼データ情報源)**: 主体者識別名識別情報を検証するために用いられる識別文書またはデータ情報源で、民間企業や政府機関の間で信頼できるものとして一般的に認識されており、申請者による証明書取得以外の目的で第三者によって作成されたもの。 **Reliable Method of Communication (信頼連絡手段)**: 申請権限者以外の情報源を使用して確認された、郵便/宅配便の配送先住所、電話番号、Emailアドレスなどの連絡方法。 **Relying Party (検証者)**: 有効な証明書に依拠する自然人または法人。アプリケーションソフトウェアサプライヤーによって配布されるソフトウェアが単に証明書に関連する情報を表示するだけの場合、そのサプライヤーは検証者とは見なされない。 **Repository (リポジトリー)**: 公開されている PKI ガバナンス ドキュメント (証明書ポリシーや認証実施規定など) と証明書ステータス情報 (CRL または OCSP 応答の形式) を含むオンライン データベース。 **Request Token (申請トークン**: CAによって指定された手法で得られた値で、管理の証明を証明書要求にバインドする。CAは、CPS（またはCPSによって明確に参照されているドキュメント）内で、受け入れるトークンの形式と方法を定義する必要がある(SHOULD)。 申請トークンには、証明書要求で使用された鍵を組み込むこととする(SHALL)。 申請トークンには、それがいつ作成されたかを示すタイムスタンプを含めることができる(MAY)。 申請トークンには、その一意性を確保するその他の情報を含めることができる(MAY)。 タイムスタンプを含む申請トークンは、その作成時から30日間だけ有効となる(SHALL)。 タイムスタンプを含む申請トークンは、そのタイムスタンプが未来の日時を指す場合、無効として扱われる(SHALL)。 タイムスタンプを含まない申請トークンは、1回のみ使用できる。CAは、使用済みのトークンを後続の検証に再使用しないこととする(SHALL NOT)。 バインドでは、証明書要求への署名に使用されるものと同程度の強度を持つデジタル署名アルゴリズムまたは暗号化ハッシュアルゴリズムを使用することとする(SHALL)。 Note (注): リクエストトークンの例には以下が含まれるが、これらに限定されない。 i. 公開鍵のハッシュ ii. Subject Public Key Info [X.509]のハッシュ iii. PKCS＃10 CSRのハッシュ リクエストトークンは、タイムスタンプまたはその他のデータと連結することもできます。CAが常にPKCS＃10 CSRのハッシュをリクエストトークンとして使用することを望み、タイムスタンプを組み込みたくなく、証明書キーの再利用を許可したい場合、申請者はOpenSSLを使用したCSRの作成でチャレンジパスワードを使用して、後続のリクエスト間でサブジェクトとキーが同一であっても一意性を確保できる。 Note (注): この単純なシェルコマンドは、タイムスタンプとCSRのハッシュを持つ要求トークンを生成する。 ``echo `date -u +%Y%m%d%H%M` `sha256sum )からの引用: 「notBefore から notAfter までの期間 (包括的)」 **WebTrust for CAs**: CAの信頼性、電子商取引のセキュリティおよびその他の関連事項に関して CPA Canada が維持する内部統制の基準とそれに基づく認証フレームワーク。 **WHOIS**: RFC 391に定義されたプロトコル経由のドメイン名登録業者やレジストリオペレーター、RFC 7482に定義されたレジストリデータアクセスプロトコル、または HTTPSウェブサイトから直接回収された情報。 **Wildcard Certificate (ワイルドカード証明書)**: 証明書に含まれるサブジェクト代替名のいずれかの左端に少なくとも1つのワイルドカードドメイン名を含む証明書。 **Wildcard Domain Name (ワイルドカードドメイン名)**: "\*." で始まる文字列（U + 002Aアスタリスク、U + 002E FULL STOP）の直後に、FQDNが続く。 **XN-Label (XN-ラベル)**: RFC 5890 ()からの引用: 「接頭辞`"xn--"`（大文字と小文字は区別されない）で始まるラベルのクラスだが、それ以外はLDHラベルの規則に準拠している。」 **X.500**: 分散ディレクトリサービスに関する一連のコンピュータネットワーク標準。 **X.509**: X.509 ITU-T 証明書および CRL 形式。X.509 v3 (バージョン 3) では、任意の情報を保持するための拡張領域が追加された。 ### 1.6.2 Acronyms 1.6.2 頭字語 | **頭字語** | **正式名称** | | ---------- | ---------------------------------------------------------------------------------------- | | AICPA | American Institute of Certified Public Accountants (米国公認会計士協会) | | ADN | Authorization Domain Name（認可ドメイン名） | | CA | Certification Authority （認証局） | | CAA | Certification Authority Authorization（認証局認可） | | ccTLD | Country Code Top-Level Domain（国別コードトップレベルドメイン） | | CICA | Canadian Institute of Chartered Accountants（カナダ公認会計士協会） | | CP | Certificate Policy（証明書ポリシー） | | CPS | Certification Practice Statement（認証運用規程） | | CRL | Certificate Revocation List（証明書失効リスト） | | DBA | Doing Business As（事業名） | | DNS | Domain Name System（ドメインネームシステム） | | FIPS | (US Government) Federal Information Processing Standard（米国政府連邦情報処理標準） | | FQDN | Fully-Qualified Domain Name（完全修飾ドメイン名） | | IM | Instant Messaging（インスタントメッセージング） | | IANA | Internet Assigned Numbers Authority（インターネット番号割り当て機関） | | ICANN | Internet Corporation for Assigned Names and Numbers | | ISO | International Organization for Standardization（国際標準化機構） | | NIST | (US Government) National Institute of Standards and Technology（米国国立標準技術研究所） | | OCSP | Online Certificate Status Protocol（オンライン証明書ステータスプロトコル） | | OID | Object Identifier（オブジェクト識別子） | | PKI | Public Key Infrastructure （公開鍵基盤） | | RA | Registration Authority（登録局） | | S/MIME | Secure MIME (Multipurpose Internet Mail Extensions) | | SSL | Secure Sockets Layer (セキュア・ソケット・レイヤー) | | TLS | Transport Layer Security（トランスポート・レイヤー・セキュリティ） | | VoIP | Voice Over Internet Protocol （ボイスオーバー・インターネット・プロトコル） | ### 1.6.3 References 1.6.3 参照 [Section 1.1](#11-overview) を参照。 ### 1.6.4 Conventions 1.6.4 慣例 Baseline Requirements に記載されるキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」はRFC 2119に従って解釈される。 本CP/CPSでは、日付などの有効な要件をリストする際に時間とタイムゾーンを省略している。明示的に指定されている場合を除き、日付に関連付けられた時刻は00:00:00 UTCになる。 # 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES 2 公開およびリポジトリーに関する責任 CAは、最新バージョンの Baseline Requirements をCAがどのように実装するかを詳細に説明したCP/CPSを作成、実施、施行し、少なくとも 366 日に 1 回更新する(SHALL)。 ## 2.1 Repositories 2.1 リポジトリー CAは、CP/CPSに従って、下位証明書および利用者証明書の失効情報を公開する (SHALL)。 ## 2.2 Publication of information 2.2 情報公開 CAは、24時間365日利用可能な適切かつ容易にアクセスできるオンライン手段を通じて、CP/CPSを公開する (SHALL)。 CP/CPSはRFC 3647に従って構成され、RFC 3647で要求されるすべての資料が含まれていなければならない (MUST)。 CAは、Baseline Requirements を正式に適用し、最新の公開バージョンに準拠することを表明する (SHALL)。CAは、Baseline Requirements をCP/CPSに直接組み込むか、次のような条項を使用して参照によって組み込むことで、この要件を満たすことができる (MAY) (Baseline Requirements の公式バージョンへのリンクを含めなければならない (MUST))。 セコムトラストシステムズは、 で公開されている「Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates」の最新バージョンに準拠している。本CP/CPSと Baseline Requirements の間に矛盾がある場合は、Baseline Requirements が本CP/CPSよりも優先される。 CAは、アプリケーションソフトウェアサプライヤーが各パブリックルート証明書までつながる利用者証明書を使用してソフトウェアをテストできるようにテストウェブページをホストする(SHALL)。 少なくとも、CAは、以下のように利用者証明書を使用して個別の Web ページをホストする (SHALL)。 　i. 有効、 　ii. 失効、 　iii. 期限切れ。 ## 2.3 Time or frequency of publication 2.3 公開時期または頻度 CAは、 [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) の最新バージョンをCAがどのように実装しているかを詳細に記述したCP/CPSを作成、実施、施行し、毎年更新する (SHALL)。CAは、CP/CPSに他の変更が加えられていない場合でも、バージョン番号を増やし、日付付きの変更ログエントリーを追加することで、 [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) への準拠を示す (SHALL)。 ## 2.4 Access controls on repositories 2.4 リポジトリーのアクセス管理 CAはリポジトリーを読み取り専用の形で公開する (SHALL)。 # 3. IDENTIFICATION AND AUTHENTICATION 3 識別と認証 ## 3.1 Naming 3.1 識別名 ### 3.1.1 Types of names 3.1.1 識別名タイプ CAが発行する証明書は、X.509標準、RFC 5280標準および Baseline Requirements の要件を満たし、証明書所有者に割り当てられた識別名は X.500識別名形式に従って設定される。CAが発行する証明書には、次の情報が含まれる。 1. countryName は、日本を表す 2 文字の ISO 3166-1 国コード略語である「JP」（大文字）になる (SHALL)。 2. organizationName は組織の名前とする (SHALL)。stateOrProvinceName と localityName には組織の地域情報が含まれる。 **[EV TLSサーバー証明書]** EV Guidelinesの付録D-1に従って、次の表記法を使用する (SHALL)。 - A. 日本語のローマ字表記には、ISO 3602 に記載されている訓令式、日本式、修正ヘボン式ローマ字表記が使用できる。 - B. CAは、QIIS、検証済み法律意見書または検証済み会計士確認書のいずれかを使用して、申請者の正式な法律上の名前のローマ字表記、言語翻訳 (英語名など)またはその他の認められたローマ字の代替を検証する場合がある (MAY)。 - C. CAは、金融庁を利用して、ローマ字化、翻訳またはその他の認識されたローマ字代替名を検証することができる (MAY)。使用する場合、CAは、翻訳された英語が監査済みの財務諸表に記録されていることを確認しなければならない (MUST)。 - D. ローマ字化、翻訳またはその他の認識されたローマ字代替名を定款で検証する場合、定款には、定款が真正かつ最新であることを証明する日本における法人印で署名された文書、または検証済み法律意見書または検証済み会計士確認書のいずれかが添付されていなければならない (MUST)。CAは、法人印の真正性を検証しなければならない (MUST)。 3. commonName はメインのドメイン名であり、サブジェクト代替名に存在するドメイン名である (SHALL)。すべてのドメイン名は subjectAltName 拡張子に追加される。 4. subjectAltName 拡張領域の dNSName エントリ値に ASCII 文字列以外の国際文字が含まれている場合は、文字列の puny コード変換バージョンが使用される。 ### 3.1.2 Need for names to be meaningful 3.1.2 識別名の意味付け 証明書に指定される主体者識別名は、適切な範囲で組織または機関と関連している (SHALL)。利用者は、第三者の商標または関連する名前を含む証明書申請をCAに提出してはならない (SHALL NOT)。 **[TLSサーバー証明書]** CAが発行する証明書で使用されるコモンネームは、関連する利用者が証明書をインストールする予定の Web サーバー DNS で使用されるホスト名が割り当てられている場合に意味を持つ (SHALL)。 ### 3.1.3 Anonymity or pseudonymity of subscribers 3.1.3 利用者の匿名性または仮名性 CAが発行する証明書には匿名または仮名を登録することはできない。 ### 3.1.4 Rules for interpreting various name forms 3.1.4 識別名の解釈規則 DNは、[Section 3.1.1](#311-types-of-names) および[Section 3.1.2](#312-need-for-names-to-be-meaningful) で定義されているとおりに解釈される。 さまざまな名前形式の解釈に関する規則は、X.500 シリーズ DN 規則によって規定される。 ### 3.1.5 Uniqueness of names 3.1.5 識別名の一意性 CAは、発行された証明書が、サブジェクトの識別名に含まれる情報によって証明書の所有者を一意に識別できることを保証する。証明書のシリアルナンバーは、CSPRNG によって生成されたランダム数を含むシリアルナンバーとする。CAで割り当てられるシリアルナンバーは一意である。 ### 3.1.6 Recognition, authentication, and role of trademarks 3.1.6 商標の認識、認証および役割 CAは、証明書の申請で示された名前の知的財産権を検証しない。利用者は、第三者の登録商標またはその他の商標関連の名前を提出することはできない。CAは、登録商標または類似のものに関して利用者と第三者の間で生じた紛争の仲裁や解決には関与しない。CAは、紛争を理由に利用者の証明書の申請を拒否したり、発行済みの証明書を失効したりする権利を留保する。 ## 3.2 Initial identity validation 3.2 初回の利用者本人確認 ### 3.2.1 Method to prove possession of private key 3.2.1 私有鍵の所持を証明する方法 利用者は、以下の方法に従って、関連する私有鍵を所有していることを証明する。関連する証明書署名要求（以下、「CSR」）の署名は、そのCSRが公開鍵に対応する私有鍵で署名されていることを証明するために認証される。 ### 3.2.2 Authentication of Organization and Domain Identity 3.2.2 組織とドメインの認証 申請者が`countryName`フィールドのみから成る主体者識別名識別情報を含む証明書を申請する場合、CAは、[Section 3.2.2.3](#3223-verification-of-country) ならびにCAのCPおよびCPSに記載された要件を満たした検証プロセスを使用して、主体者識別名に関連付けられた国を検証する (SHALL)。申請者が`countryName`フィールドとその他の主体者識別名識別情報を含む証明書を申請する場合、CAは、[Section 3.2.2.1](#3221-identity) ならびにCAのCPおよびCPSに記載された要件を満たした検証プロセスを使用して、申請者のアイデンティティと、申請権限者の証明書要求の信頼性を検証する(SHALL)。CAは、本Sectionに基づいて信頼されたドキュメントに改編や偽造がないか検査する (SHALL)。 **[EV TLSサーバー証明書]** EV証明書発行時に使用する検証元は、以下のURLで公開される。 **[S/MIME 証明書]** **2023年8月31日以前に S/MIME証明書を発行する場合**、以下に説明する方法を使用して、証明書に登録されたEmailアドレスに関連付けられたEmailアカウントを管理していること、またはEmailアカウントの所有者から代理で申請することを承認されていることを認証する。このSectionで説明するランダム値は、CAによって生成された 112 ビット以上のランダム数で構成され、生成から 30日間、応答確認の使用に有効である。 1. CAは、メールアドレスに含まれる@以下のドメインのWHOISレジストリサービスに登録されている登録者（Registrant）情報を参照し、申請者がドメインを所有していること（申請者とドメイン所有者が同一組織であること）を確認する。CAがドメインが第三者組織によって所有されていることを確認できた場合、ドメインの所有者は、所有組織が押印した「ドメイン名使用承諾書」を提出し、アカウントの使用を承認する。 2. CAは、WHOISレジストリーサービスに登録されているドメイン連絡先にランダム値をEmailで送信し、そのランダム値を含む確認応答を受信することで、Emailアカウントの所有者がアカウントの使用を承認したことを確認する。 3. ローカル部分は「admin」、「administrator」、「webmaster」、「hostmaster」、または「postmaster」である必要がある。また、Emailアドレスに含まれる @ の下のドメインで作成されたEmailアドレスにランダムな値を送信し、ランダム値を含む確認応答を受信することで、CAはEmailアカウントの所有者がアカウントの使用を承認したことを確認できる。 4. CAは、ファイルの内容にリクエストトークンまたはランダム値が含まれていることを照合することで、メールアカウントの制御を確認する。承認されたポート経由でアクセスすることで、CAは「http (または https): // [メールアドレスに含まれる @ 以下のドメイン] /.well-known/pki-validation」ディレクトリ配下にランダム値が表示され、リクエストに対して正常なHTTPまたはHTTPS応答を受信することを確認する。 5. CAは、Emailアドレスに含まれる @ の下のドメイン (先頭にアンダースコア文字が付いたラベルのプレフィックスを持つものを含む) のいずれかの DNS CNAME、TXT、または CAA レコードにランダムな値またはアプリケーション トークンが含まれていることを照合することで、Emailアカウントの制御を確認する。 #### 3.2.2.1 Identity 3.2.2.1 アイデンティティ 主体者識別名識別情報が組織の名前または住所を含む場合、CAは、組織のアイデンティティや住所を検証し、その住所が申請者の現存する、または稼働している住所であることを確認する (SHALL)。CAは、次のうち1か所以上から提供されたドキュメントや、それとのやり取りを通じて得られた情報を使用して、申請者のアイデンティティと住所を検証する (SHALL)。 1. 申請者の法的な設立、存在、または承認の管轄地域にある行政機関。 2. 定期的に更新され、信頼データ情報源と見なされている第三者のデータベース。 3. CAあるいは、CAの代理人としての役割を担っている第三者による現場訪問。 4. 認証状。 CAは、上記1から4と同じ文書または情報を使用して、申請者のアイデンティティと住所の両方を検証してもよい (MAY)。 代わりに、CAは申請者の住所の（しかし申請者のアイディンティティでは無く）検証に、公共料金請求書、銀行取引明細書、クレジットカード明細書、政府発行の税務書類、その他、CAが信頼できると見なした本人確認書類を使用してもよい (MAY)。 審査の結果、不適合とセコムトラストシステムズが判断した場合、提出された公的書類は返却または破棄する。また、セコムトラストシステムズが申請書を受け取った場合は、セコムトラストシステムズが破棄する。 ##### 3.2.2.1.1 Validating authority over mailbox via domain (S/MIME Certificates) 3.2.2.1.1 ドメイン経由のメールボックス権限検証 (S/MIME 証明書) CAは、証明書で使用されるメールボックスアドレスのドメイン部分に対するエンティティの制御を検証することにより、Enterprise RAなどの申請者がEmailアカウント所有者に代わって行動することを承認されていることを確認できる (MAY)。 CAは、この検証を実行するために [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) で承認された方法のみを使用する (SHALL)。 ドメイン検証の目的上、「申請者」という用語には、申請者の親会社、子会社、または関連会社が含まれる。 ##### 3.2.2.1.2 Validating control over mailbox via email (S/MIME Certificates) 3.2.2.1.2 Emailによるメールボックス管理検証 (S/MIME 証明書) CAは、ランダム値をEmailで送信し、そのランダム値を使用して確認応答を受信することで、証明書に含まれる各メールボックスフィールドに対する申請者の管理を確認することができる (MAY)。 各メールボックスアドレスの管理は、一意のランダム値を使用して確認される (SHALL)。ランダム値は検証対象のEmailアドレスにのみ送信され、他の方法で共有されることは無い (SHALL NOT)。 ランダム値は各Emailで一意である (SHALL)。ランダム値は、作成後、24時間以内であれば確認応答での使用に有効である (SHALL)。CAは、CP/CPSでランダム値の有効期間をより短く指定できる (MAY)。 ランダム値は、CAからメールボックスアドレスに送信されるEmailの各インスタンスごとにリセットされる (SHALL)が、そのメールボックスアドレスに送信されたすべての関連するランダム値は、このSectionで説明されている有効期間内に確認応答で使用するために有効なままになる場合がある (MAY)。さらに、メールボックスアドレスの検証後に認証要素として追加で使用することを意図している場合、ランダム値はユーザーが最初に使用したときにリセットされる (SHALL)。 ##### 3.2.2.1.3 Validating applicant as operator of associated mail server(s) (S/MIME Certificates) 3.2.2.1.3 申請者が関連メールサーバーの運営者であることの検証（S/MIME証明書） CAは、メールボックスアドレスに配信されるメッセージの送信先となる SMTP FQDN の制御を確認することで、証明書に含まれる各メールボックスフィールドに対する申請者の制御を確認することができる (MAY)。SMTP FQDN は、[RFC 5321 Section 5.1](https://datatracker.ietf.org/doc/html/rfc5321#section-5.1) で定義されているアドレス解決アルゴリズムを使用して識別され、特定のメールボックス アドレスに対してどの SMTP FQDN が権限を持つかを決定する (SHALL)。複数の SMTP FQDN が検出された場合、CAは、[RFC 5321 Section 5.1](https://datatracker.ietf.org/doc/html/rfc5321#section-5.1) の選択プロセスに従って SMTP FQDN の制御を検証する (SHALL)。MX レコード RDATA 内のエイリアスは、この検証方法では使用されない (SHALL NOT)。 申請者の SMTP FQDN の制御を確認するために、CAは [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) で現在承認されている方法のみを使用する (SHALL)。 #### 3.2.2.2 DBA/Tradename 3.2.2.2 商号/商標名 主体者識別名のアイデンティティ情報に商号または商標名が含まれる場合、CAは、以下の少なくとも1つを使用して、商号/商標名を使用するための申請者の権利を検証する (SHALL)。 1. 申請者の法的な設立、存在、または承認の管轄地域にある政府機関が提供するドキュメントまたは、このような政府機関とのやり取りで得られた情報。 2. 信頼データ情報源。 3. 当該商号または商標名の管理を担当している政府機関とのやり取りで得られた情報。 4. 文書による裏付けのある意見書。 5. 公共料金請求書、銀行取引明細書、クレジットカード明細書、政府発行の税務書類、その他、CAが信頼できると見なした本人確認書類。 ##### 3.2.2.2.1 Verification of Applicant's Legal Existence and Identity (EV TLS Server Certificates) 3.2.2.2.1 申請者の法的存在と身元の検証（EV TLSサーバー証明書） ###### 3.2.2.2.1.1 Verification Requirements 3.2.2.2.1.1 検証要件 申請者の法的存在とアイデンティティを検証するため、CAは以下を実行しなければならない (MUST)。 1. **民間組織主体者識別名** A. **法的存在**: 申請者が、申請者の設立または登録管轄地の設立機関または登録機関によって、その存在と設立(法人化)の有効性が法的に認められた組織体であるか、また、設立/登録機関の記録上、「不活動」、「無効」、「現行ではない」、またはこれらに相当するラベルがつけられていない組織体であるかを検証する。 B. **組織名**: 申請者の法人設立または登録管轄地の設立機関または登録機関に記録された申請者の正式名称が、EV証明書要求に記載された申請者名と一致するかを検証する。 C. **登録番号**: 申請者の法人設立または登録管轄地の設立機関または登録機関によって申請者に割り当てられた特定の登録番号を取得する。設立機関または登録機関が登録番号を割り当てていない場合、CAは申請者の設立日または登録日を取得する(SHALL)。 D. **登録代理人**: 申請者の登録代理人または登記上の事務所のアイデンティティと住所を取得する(申請者の設立または登録管轄地において該当する場合)。 2. **政府組織主体者識別名** A. **法的存在**: かかる政府組織が運営されている下位政府組織内で、申請者が法的に認められた政府組織として存在するか検証する。 B. **事業体名**: 申請者の正式名称が、EV証明書要求に記載された申請者名と一致するか検証する。 C. **登録番号**: CAは、申請者の法人設立、登録、または結成の日付、あるいは政府組織を創設した法的措置の識別子の取得を試みなければならない(MUST)。この情報が入手できない場合、CAは主体者識別名が政府組織であることを示す適切な文言を入力しなければならない(MUST)。 3. **事業体主体者識別名** A. **法的存在**: 申請者が申請書内に記載した名前の下で事業に従事していることを検証する。 B. **組織名**: 申請者の登録管轄地の登録機関によって認識されている申請者の正式名称が、EV証明書要求に記載された申請者名と一致するかを検証する。 C. **登録番号**: 申請者の登録管轄地の登録機関によって申請者に割り当てられた、特定かつ一意の登録番号の取得を試みる。登録機関が登録番号を割り当てていない場合、CAは申請者の登録日を取得する(SHALL)。 D. **代表個人**: 特定された代表個人のアイデンティティを検証する。 4. **非営利団体主体者識別名 (国際組織)** A. **法的存在**: 申請者が法的に認められた国際組織体であることを検証する。 B. **組織体名**: 申請者の正式名称が、EV証明書要求に記載された申請者名と一致するか検証する。 C. **登録番号**: CAは、申請者の形成の日付、あるいは国際組織体を創設した法的措置の識別子の取得を試みる必要がある (MUST)。この情報が入手できない場合、CAは主体者識別名が国際組織体であることを示す適切な文言を入力しなければならない (MUST)。 具体的には以下の値を登録する。 利用者が次の場合、CAは serialNumber を次のように設定する。 | 利用者 | serialNumber | | ---------------------- | -------------------------- | | 登録法人 | 会社法人番号または法人番号 | | 中央省庁および国家機関 | 法人番号または設立年月日 | | 地方自治体とその機関 | 法人番号または設立年月日 | | 国公立大学・高等学校 | 法人番号または設立年月日 | 法人番号と設立年月日がCAで確認できない場合は、serialNumber に次のテキストを入力する。 | 利用者 | serialNumber | | ---------------------- | ---------------- | | 中央省庁および国家機間 | Government | | 地方自治体とその機関 | Local Government | | 国公立大学・高等学校 | Public School | 利用者が次の場合、CAは businessCategory を次のように設定する。 | 利用者 | businessCategory | | ---------------------- | -------------------- | | 登録法人 | Private Organization | | 中央省庁および国家機関 | Government Entity | | 地方自治体とその機関 | Government Entity | | 国公立大学・高等学校 | Government Entity | ###### 3.2.2.2.1.2 Acceptable Method of Verification 3.2.2.2.1.2 許容される検証方法 1. **民間団体の主体者識別名**:6項に基づいて検証されない限り、[Section 3.2.2.2.1.1](#322211-verification-requirements) (1)に記載されているすべての項目は、申請者の設立または登録の管轄区域内の設立または登録機関に直接確認されるか、直接入手されなければならない (MUST)。そのような検証は、設立または登録機関によって、あるいは設立もしくは登録機関に代わって運営される認定政府情報源を使用することによって、または認定政府情報源、設立あるいは登録機関、もしくは認定独立情報源から直接取得した住所または電話番号を使用して、設立あるいは登録機関に直接連絡するか、郵便、Email、Webアドレス、もしくは電話で連絡することによって行うことができる (MAY)。 2. **政府組織の主体者識別名**: 6項に基づいて検証されない限り、[Section 3.2.2.2.1.1](#322211-verification-requirements)(2) に列挙されているすべての項目は、次のいずれかに直接検証されるか、直接入手されなければならない (MUST)。 i. 当該政府組織が運営する行政区分内の認定政府情報源。 ii. 申請者と同じ行政区分に属する上位の政府組織。 iii. その政治区分内の連邦、州、または地方裁判所の現役裁判官から。 裁判官からのあらゆる連絡は、[Section 3.2.2.2.10.1](#3222101-verified-legal-opinion) に規定されているように弁護士が主張する事実の主張を検証するために使用されるのと同じ方法で検証される (SHALL)。 このような確認は、適切な政府組織に直接連絡して行うか、または適格な独立情報源から取得した住所または電話番号を使用して、郵便、Email、Web アドレス、または電話を介して行うことができる (MAY)。 3. **事業体の主体者識別名**: 6項に基づいて検証されない限り、上記 [Section 3.2.2.2.1.1](#322211-verification-requirements) (3) (A) から (C) にリストされている項目は、申請者の登録管轄区域内の登録機関に直接確認するか、登録機関から直接入手しなければならない (MUST)。このような検証は、認定政府情報源、認定政府税務情報源、または登録機関に直接連絡して直接連絡するか、認定政府情報源、認定政府税務情報源、登録機関、または認定独立情報源から直接取得した住所または電話番号を使用して、郵便、Email、Web アドレス、または電話で行うことができる (MAY)。さらに、CAは、以下のSub Section (4) の要件に従って、事業体に関連付けられた主要な個人を検証しなければならない (MUST)。 4. **代表個人**: ビジネスエンティティに関連付けられた個人は、対面で検証されなければならない (MUST)。CAは、登録機関が実行する主要個人の対面検証に依拠することができる (MAY)。ただし、CAが検証手順を評価し、対面検証手順に関するEV Guidelinesの要件を満たしていると結論付けた場合に限る。登録機関が対面検証を実施しなかった場合、または登録機関の対面検証手順がEV Guidelinesの要件を満たさない場合、CAは対面検証を実施する (SHALL)。 A. **対面による検証**: 対面による検証は、CAの従業員、公証人 (または申請者の管轄区域における同等の者)、弁護士、または会計士 (第三者検証者) のいずれかの前で実施しなければならない (MUST)。本人は、次の文書 (検証文書) を第三者検証者に直接提示しなければならない (MUST)。 - i. 以下の情報を含む個人の声明 1. 個人が現在または過去に知られているフルネーム（使用されている他のすべての名前を含む） 2. 居住地の住所 3. 生年月日 4. 証明書リクエストに含まれるすべての情報が真実かつ正確であることの確認 - ii. 個人の写真が含まれ、個人によって署名された、現在署名されている、以下の政府発行の身分証明書 1. 旅券 2. 運転免許証 3. 個人識別カード - iii. 本人確認書類として、本人の名前が記載された少なくとも 2 つの二次証拠書類が必要である。そのうち 1 つは金融機関が発行したものでなければならない (MUST)。 1. 受け入れ可能な金融機関の文書には以下のものがある。 a. 有効期限が記載されており、期限が切れていない主要なクレジットカード b. 有効期限が記載されており、期限が切れていない規制金融機関発行のデビットカード c. 認知度の高い貸し手からの6か月以内の住宅ローン明細書 d. 金融機関からの 6か月以内の銀行取引明細書。 2. 許容される非財務文書には以下のものがある。 a. 固定住所でサービス料金を支払う取り決めを確認する公共料金会社からの最近の公共料金の請求書または証明書（携帯電話の請求書は不可） b. リース料の支払い明細書のコピー（明細書の日付が過去6か月以内であるものに限る） c. 出生証明書のコピー d. 当該年度の地方自治体の税金の請求書 対面検証を実行する第三者検証者は、次の要件を満たさなければならない (MUST)。 - i. 個人声明の署名と署名者の身元を証明すること。 - ii. 身元確認に使用された元の審査文書を識別すること。さらに、第三者検証者は、現在署名されている政府発行の写真付き身分証明書のコピーで、それが元の文書の完全かつ真実で正確な複製であることを証明しなければならない (MUST)。 B. **第三者検証者の確認**: CAは、第三者検証者が個人の居住地の管轄区域の公証人 (または申請者の管轄区域における法的同等者)、弁護士、または会計士であることおよび第三者検証者が実際にサービスを実行し、個人の署名を証明したことを独自に確認しなければならない (MUST)。 C. **情報の相互チェック**: CAは、署名され証明された個人声明と、署名された最新の政府発行の写真付き身分証明書の証明されたコピーを入手しなければならない (MUST)。CAは、情報が一貫しており、申請書の情報と一致し、個人を特定できることを確認するために、文書を確認しなければならない（MUST）。CAは、次の条件を満たす場合、この文書の電子コピーに依拠することができる (MAY)。 - i. CAは、第三者検証機関にその真正性（元のオリジナルと比較して不適切に変更されていないこと）を確認する。 - ii. 同様の種類の文書の電子コピーは、CAの管轄地域の法律に基づいて、原本の法的代替物として認められる。 5. **非営利法人主体者識別名（国際機関）**: 6項に基づいて検証されない限り、[Section 3.2.2.2.1.1](#322211-verification-requirements) (4)に記載されているすべての項目は、次のいずれかの方法で検証されなければならない (MUST)。 A. 国際機関が設立された設立文書を参照している B. CAが事業を行うことが許可されている署名国の政府と直接関係している。このような証明は、適切な政府機関またはその国の法律から、または、その国の政府が国際機関でその国を代表する任務を持っていることを確認することによって取得できる。 C. CA/ブラウザフォーラムが で維持している、資格のあるエンティティの現在のリストに直接対している。 D. EV証明書を申請する国際機関が機関または代理店である場合 (検証済み国際機関の非政府組織を含む)、CAは、申請者が機関または代理店である検証済み上位国際機関に対して、国際機関申請者を直接検証することができる。 6. CAは、以下の場合、上記1～5に記載された申請者の情報を証明するため、認証された専門家による書簡に依拠することができる。 i. 検証済み専門家確認書には、登録証明書、定款、運営契約、法令、規制行為など、申請者の法的存在を証明するために使用される裏付け文書のコピーが含まれている。 ii. CAは、検証済み専門家確認書で指定された申請者の組織名を QIIS または QGIS で確認する。 ##### 3.2.2.2.2 Verification of Applicant's Legal Existence and Identity – Assumed Name (EV TLS Server Certificates) 3.2.2.2.2 申請者の法的存在と身元の検証 - 仮名 (EV TLSサーバー証明書) ###### 3.2.2.2.2.1 Verification Requirements 3.2.2.2.2.1 検証要件 申請者の法人設立または登録の管轄区域内の該当する法人設立機関または登録機関に記録されている申請者の正式な法定名称に加えて、EV証明書で主張されている申請者の身元に、申請者が事業を行うための仮名 (米国では「doing business as」、「DBA」または「d/b/a」、英国では「trading as」とも呼ばれる) が含まれる場合、CAは次のことを確認しなければならない (MUST)。 i. 申請者が、その事業所の管轄区域内の適切な政府機関に、その仮名の使用を登録している（EV Guidelinesに従って検証されている） ii. 当該申請は引き続き有効であること。 ###### 3.2.2.2.2.2 Acceptable Method of Verification 3.2.2.2.2.2 許容される検証方法 申請者が事業を行う際に使用する仮名を検証するには、次の事項を行う。 1. CAが、申請者の事業所の管轄区域内の適切な政府機関によって運営されている、またはその機関に代わって運営されているQGISを使用することによって、あるいはそのような政府機関に直接連絡して、もしくは郵便、Email、Webアドレス、または電話を介して、仮名を確認する場合がある (MAY)。 2. CAは、QIISが適切な政府機関で仮名を検証している場合、適格独立情報源を使用して仮名を検証できる (MAY)。 3. CAは、申請者がビジネスを行う際に使用する仮名、その仮名が登録されている政府機関およびその登録が引き続き有効であることを示す検証済み専門家確認書に依拠する場合がある (MAY)。 ##### 3.2.2.2.3 Verification of Applicant's Physical Existence (EV TLS Server Certificates) 3.2.2.2.3 申請者の実在検証（EV TLSサーバー証明書） ###### 3.2.2.2.3.1 Address of Applicant's Place of Business 3.2.2.2.3.1 申請者の事業所住所 1. **検証要件**: 申請者の物理的な存在と事業所の存在を確認するために、CAは、申請者が提供する住所が申請者または親会社/子会社が事業活動を行っている住所であり (たとえば、郵便受けや私書箱、または組織の代理人の住所などの「気付」(C/O) 住所ではない)、申請者の事業所住所であることを検証しなければならない (MUST)。 2. **許容される検証方法** A. **設立または登録国における事業所** i. 申請者の事業所が申請者の設立管轄地または登録管轄地と同じ国にあり、その事業所が、法的存在を確認するために [Section 3.2.2.2.1](#32221-verification-of-applicants-legal-existence-and-identity-ev-tls-server-certificates) で使用される関連する認定政府情報源に示されている事業所と同じではない場合 1. 少なくとも 1 つの QGIS (法的存在の検証に使用されるものを除く)、QIISまたは QTIS の現在のバージョンで同じ事業所住所が記載されている申請者の場合、CAは、EV証明書リクエストに記載されている申請者の住所が、そのような QGIS、QIISまたは QTIS を参照して申請者または親会社/子会社の有効な事業所住所であることを確認しなければならず (MUST)、そのような住所が事業所であるという申請者による表明を信頼する場合がある (MAY)。 2. 申請者が、現在のバージョンの少なくとも 1 つの QIIS または QTIS に同じ事業所住所として記載されていない場合、CAは、EV証明書リクエストで申請者が提供した住所が申請者または親会社/子会社の事業所住所であることを確認しなければならない (MUST)。確認には、信頼できる個人または会社が事業所住所への現地訪問の文書を取得しなければならない (MUST)。現地訪問の文書には、次の内容が記載されていなければならない (MUST)。 a. 申請者の事業所がEV証明書申請に記載されている正確な住所にあることを確認する（例：常設の看板、従業員の確認など）。 b. 施設の種類（商業ビル内のオフィス、個人住宅、店舗など）を特定し、恒久的な事業所であるかどうかを確認する。 c. 申請者を識別するための恒久的な標識（移動できないもの）があるかどうかを記載する。 d. 申請者がその場所で継続的な事業活動を行っている証拠があるかどうかを示す（たとえば、郵便受けや私書箱などだけではなく）。 e. 1枚以上の写真を含める。 - i. 敷地の外観（申請者の名前を示す標識がある場合は表示し、可能であれば住所も表示。 - ii. 内部の受付エリアまたは作業スペース。 ii. すべての申請者について、CAは、申請者または親会社/子会社の事業所の住所と、そこで事業活動が行われていることを示す検証済み専門家確認書に依拠することもできる (MAY)。 iii. 政府組織の申請者の場合、CAは申請者の管轄区域内の QGIS の記録に含まれる住所に依拠する場合がある (MAY)。 iv. 申請者の事業所が申請者の設立または登録の管轄区域と同じ国にあり、法的存在を確認するために [Section 3.2.2.2.1](#32221-verification-of-applicants-legal-existence-and-identity-ev-tls-server-certificates) で使用される QGIS に申請者の事業所住所が含まれている場合、CAは QGIS の住所を信頼して、EV証明書リクエストに記載されている申請者または親会社/子会社の住所を確認することができ (MAY)、その住所が事業所であるという申請者による表明を信頼することができる (MAY)。 B. **事業所が設立国または登録国にない**: CAは、申請者の事業所住所と、そこで事業活動が行われていることを示す検証済み専門家確認書に依拠しなければならない (MUST)。 ##### 3.2.2.2.4 Verified Method of Communication (EV TLS Server Certificates) 3.2.2.2.4 検証済み通信方法（EV TLSサーバー証明書） ###### 3.2.2.2.4.1 Verification Requirements 3.2.2.2.4.1 検証要件 申請者との通信を支援し、申請者が発行を認識して承認していることを確認するために、CAは、申請者との検証済み通信方法として、電話番号、ファックス番号、Email アドレスまたは郵便の配送先住所を検証しなければならない (MUST)。 ###### 3.2.2.2.4.2 Acceptable Methods of Verification 3.2.2.2.4.2 許容される検証方法 申請者との検証済み通信方法を検証するには、CAは次のことを行わなければならない (MUST)。 A. 検証済み通信方法が申請者、または申請者の親会社、子会社、または関連会社のものであることを確認するには、以下の申請者の親会社、子会社、または関連会社の事業所のいずれかと照合する。 i. 該当する電話会社から提供された記録 ii. QGIS、QTIS、またはQIIS iii. 検証済み専門家確認書 B. 検証済み通信方法を使用して、申請者、または申請者の親会社、子会社、または関連会社に検証済み通信方法を使用して確実に連絡できると合理的な人が結論付けるのに十分な肯定的な応答を取得することにより、検証済み通信方法を確認する。 ##### 3.2.2.2.5 Verification of Applicant's Operational Existence (EV TLS Server Certificates) 3.2.2.2.5 申請者の運用上の存在の検証（EV TLSサーバー証明書） ###### 3.2.2.2.5.1 Verification Requirements 3.2.2.2.5.1 検証要件 CAは、申請者または関連会社/親会社/子会社の事業上の存在を確認することで、申請者が事業に従事する能力があることを検証しなければならない (MUST)。CAは、政府組織の事業上の存在の確認として、[Section 3.2.2.2.1](#32221-verification-of-applicants-legal-existence-and-identity-ev-tls-server-certificates) に基づく政府組織の法的存在の確認に依拠することができる (MAY)。 ###### 3.2.2.2.5.2 Acceptable Methods of Verification 3.2.2.2.5.2 許容される検証方法 申請者の事業遂行能力を検証するために、CAは、以下の方法で申請者またはその関連会社/親会社/子会社の事業運営上の存在を確認しなければならない (MUST)。 1. 設立機関または登録局の記録に示されているように、申請者、関連会社、親会社、または子会社が少なくとも 3 年間存在していることを確認する。 2. 申請者、関連会社、親会社、または子会社が最新の QIIS または QTIS のいずれかに記載されていることを確認する。 3. 申請者、関連会社、親会社、または子会社が規制金融機関に有効な当座預金口座を持っていることを確認するため、申請者、関連会社、親会社、または子会社の当座預金口座の認証済み文書を規制金融機関から直接受け取る。 4. 申請者が規制金融機関に有効な当座預金口座を持っていることを証明する専門家による検証済み専門家確認書に依拠する。 ##### 3.2.2.2.6 Verification of Applicant's Domain Name (EV TLS Server Certificates) 3.2.2.2.6 申請者のドメイン名検証（EV TLSサーバー証明書） ###### 3.2.2.2.6.1 Verification Requirements 3.2.2.2.6.1 検証要件 1. 証明書に記載されているオニオンドメイン名ではない FQDN について、CAは、証明書の発行日時点で、申請者 (または申請者の親会社、子会社、もしくはは関連会社。このSectionでは総称して「申請者」と呼ぶ) がドメイン名登録者であるか、または Baseline Requirements のSection 3.2.2.4 で指定された手順を使用して FQDN を管理していることを確認する (SHALL)。 セコムトラストシステムズ は Onion ドメイン名を発行していない。 2. **混合文字セットドメイン名**: EV証明書には、ドメインレジストラによって定められた規則に準拠する場合に限り、混合文字セットを含むドメイン名を含めることができる (MAY)。CAは、混合文字セットを含むドメイン名を既知のハイリスクドメインと視覚的に比較しなければならない (MUST)。類似性が見つかった場合、EV証明書要求はハイリスクとしてフラグ付けされるなければならない (MUST)。CAは、申請者と問題の対象が同じ組織であることを合理的な疑いの余地なく確実にするために、合理的に適切な追加の認証と検証を実行しなければならない (MUST)。 ##### 3.2.2.2.7 Verification of Name, Title, and Authority of Contract Signer and Certificate Approver (EV TLS Server Certificates) 3.2.2.2.7 契約署名者および証明書承認者の氏名、役職、権限検証 (EV TLSサーバー証明書) ###### 3.2.2.2.7.1 Verification Requirements 3.2.2.2.7.1 検証要件 契約署名者と証明書承認者の両方について、CAは次の事項を検証しなければならない (MUST)。 1. **氏名、役職名および所属機関**: CAは、該当する場合、契約署名者および証明書承認者の名前と役職を検証しなければならない (MUST)。また、CAは、契約署名者および証明書承認者が申請者を代表する代理人であることを検証しなければならない (MUST)。 2. **契約署名者の署名権限**: CAは、契約署名者が申請者に代わって利用者契約 (およびその他の関連する契約上の義務) を締結する権限を申請者から与えられていることを検証しなければならない (MUST)。これには、申請者に代わって 1人以上の証明書承認者を指定する契約が含まれる。 3. **EV証明書承認機関**: CAは、証明書承認者自身以外の情報源を通じて、EV証明書要求の日付時点で、証明書承認者が申請者から以下のことを行う権限を明示的に付与されていることを検証しなければならない (MUST)。 A. 申請者に代わってEV証明書要求を提出し、該当する場合は証明書要求者に提出を許可する。 B. EV証明書の発行のためにCAが申請者に要求する情報を提供し、該当する場合は証明書要求者に提供を許可する。 C. 証明書要求者によって送信された EV 証明書要求を承認する。 ###### 3.2.2.2.7.2 Acceptable Methods of Verification – Name, Title and Agency 3.2.2.2.7.2 許容される検証方法 – 氏名、役職、所属組織 契約署名者および証明書承認者の名前、役職および代理権の確認に許容される方法は次のとおりである。 1. **名前と役職**: CAは、そのような役割を担うと主張する人物が実際にその役割を担うよう指名された人物であることを合理的に保証するために設計された適切な方法によって、契約署名者および証明書承認者の名前と役職を検証することができる (MAY)。 2. **代理権**: CAは、次の方法で契約署名者と証明書承認者の代理権を検証することができる (MAY)。 A. 申請者のための検証済み通信手段を使用して申請者に連絡し、契約署名者/証明書承認者が従業員であることを確認する。 B. 申請者から独立した確認書 [Section 3.2.2.2.10.4](#3222104-independent-confirmation-from-applicant)に記載、または、契約署名者/証明書承認者が申請者の従業員であるか、もしくは申請者の代理人として任命されていることを確認する専門家による確認書を取得する。 C. 契約署名者/証明書承認者が申請者の従業員であることを QIIS または QGIS から確認する。 CAは、契約署名者の雇用または代理権および署名権限が確認されている場合、契約署名者からの証明書（契約署名者によって署名されたCAと申請者間の契約を含む）を介して証明書承認者の代理権を検証することもできる (MAY)。 ###### 3.2.2.2.7.3 Acceptable Methods of Verification – Authority 3.2.2.2.7.3 許容される検証方法 – 権限 契約署名者の署名権限および証明書承認者のEV権限検証に許容される方法には、該当する場合、次のものがある。 1. **検証済み専門家確認書**: 契約署名者の署名権限/証明書承認者のEV権限は、検証済み専門家確認書に基づいて検証される場合がある (MAY)。 2. **法人決議**: 契約署名者の署名権限/証明書承認者のEV権限は、当該署名権限が付与されていることを確認する適切に認証された法人決議に依拠​​して検証される場合がある (MAY)が、当該決議は以下のとおり i. 適切な法人役員（例：米国における会社秘書役（法務文書の管理責任者））によって認証される。 ii. CAは、証明書が当該人物によって有効に署名されたことおよび当該人物が証明書を提供するために必要な権限を有していることを確実に検証できる。 3. **申請者から独立した確認**: 契約署名者の署名権限/証明書承認者のEV権限は、申請者から独立した確認を取得することによって検証される場合がある (MAY) ( [Section 3.2.2.2.10.4](#3222104-independent-confirmation-from-applicant)に記載)。 4. **CAと申請者間の契約**: 証明書承認者のEV権限は、契約が契約署名者によって署名され、契約署名者の機関と署名権限が検証されていることを条件として、証明書承認者をそのようなEV権限に指定するCAと申請者間の契約に基づいて検証される場合がある (MAY)。 5. **同等の権限を有する者**: 契約署名者の署名権限/証明書承認者のEV権限は、以前の同等権限の証明に依拠して検証される場合がある (MAY)。 A. 契約署名者の以前の同等権限は、契約署名者がCAと申請者の間で法的に有効かつ強制力のある印章または手書きの署名で拘束力のある契約を締結し、その契約がEV証明書の申請の 90 日以上前に締結された場合にのみ、契約署名者の署名権限の確認または検証に依拠できる (MAY)。CAは、以前の契約を正しく識別し、EV申請に関連付けるために、十分な詳細を記録しなければならない (MUST)。このような詳細には、次のいずれかが含まれる場合がある (MAY)。 - i. 契約書名 - ii. 契約書署名者の署名日 - iii. 契約参照番号 - iv. 提出場所 B. 証明書承認者が以下の 1 つ以上の手順を実行した場合、証明書承認者のEV権限の確認または検証には、証明書承認者の以前の同等権限をに依拠することができる (MAY)。 - i. CAとの契約に基づき、申請者のエンタープライズRAとして勤務した（または勤務中）。 - ii. CAによって発行され、申請者によって現在検証可能に使用されている証明書について、1 つ以上の証明書要求の承認に参加した。 この場合、CAは、以前に検証された電話番号で証明書承認者に電話で連絡するか、証明書要求を承認する署名および公証された手紙を受理していなければならない (MUST)。 6. **QIIS または QGIS**: 契約署名者の署名権限/証明書承認者のEV権限は、契約署名者/証明書承認者が申請者の法人役員、個人事業主またはその他の上級役員であることを確認する QIIS または QGIS によって検証される場合がある (MAY)。 7. **契約署名者の表明/保証**: CAは、契約署名者が申請者の従業員または代理人であることを確認した場合、次の承認を含む正式に実行された表明または保証を契約署名者から取得することにより、契約署名者の署名権限に依拠することができる (MAY)。 - A. 申請者は、契約署名者が申請者に代わって利用者契約に署名することを承認する。 - B. 利用契約は法的に有効かつ執行可能な契約である。 - C. 利用契約の締結により、申請者はそのすべての条件に拘束される。 - D. EV証明書の不正使用には重大な結果がともなう。 - E. 契約署名者は、会社の Web サイトの信頼性を証明するために、法人の印章または役員の署名に相当するデジタル証明書を取得する権限を持つ。 ###### 3.2.2.2.7.4 Pre-Authorized Certificate Approver 3.2.2.2.7.4 事前承認証明書承認者 CAと申請者が将来複数のEV証明書要求を提出することを検討している場合、CAは次の処理を実行する。 1. 契約署名者の氏名と役職およびその署名者が申請者の従業員または代理人であることを確認している。 2. [Section 3.2.2.2.7.3](#322273-acceptable-methods-of-verification--authority) の手順のいずれかに従って、契約署名者の署名権限を確認した。 CAと申請者は、申請者に代わって契約署名者が署名した書面による契約を締結することができる (MAY)。これにより、指定された期間、申請者は、当該契約で指定された 1人以上の証明書承認者に、申請者に代わって提出され、当該証明書承認者によって発行または承認されたことが適切に認証された将来の各EV証明書要求に関してEV権限を行使することを明示的に許可する。 当該契約では、申請者が、当該EV CAが失効されるまで、当該証明書承認者の要請により発行された、または当該証明書承認者により承認されたすべてのEV証明書について利用者契約に基づく義務を負うことを規定しなければならず (MUST)、また、以下の相互合意条項を含まなければならない (MUST)。 i. EV証明書要求が承認されるときに証明書承認者の認証 ii. 証明書承認者のEV権限の定期的な再確認 iii. 申請者がCAに対して、当該証明書承認者のEV認証局が失効したことを通知できる安全な手順 iv. 合理的に必要なその他の適切な予防措置 ##### 3.2.2.2.8 Verification of Signature on Subscriber Agreement and EV Certificate Requests (EV TLS Server Certificates) 3.2.2.2.8 利用者契約およびEV証明書申請 (EV TLSサーバー証明書) の署名検証 利用者契約と事前承認されていない各EV証明書申請の両方に署名しなければならない (MUST)。利用者契約は、権限のある契約署名者によって署名されなければならない (MUST)。EV証明書申請は、証明書申請が [Section 3.2.2.2.7.4](#322274-pre-authorized-certificate-approver) に従って事前承認されていない限り、文書を提出する証明書要求者によって署名されなければならない (MUST)。証明書要求者が権限のある証明書承認者でもない場合は、権限のある証明書承認者がEV証明書要求を個別に承認しなければならない (MUST)。すべての場合において、該当する署名は法的に有効であり、強制力のある印章または手書きの署名 (紙の利用者契約/EV証明書要求の場合)、または法的に有効で強制力のある電子署名 (電子利用者契約/EV証明書要求の場合) が含まれていなければならず (MUST)、申請者を各文書の条件に拘束する。 ###### 3.2.2.2.8.1 Verification Requirements 3.2.2.2.8.1 検証要件 1. **署名**: CAは、利用者契約書の契約署名者の署名と各EV証明書要求の証明書要求者の署名を、該当する文書に署名者として記載されている人物が実際に申請者に代わって文書に署名した人物であることを合理的に確実にする方法で認証しなければならない (MUST)。 2. **承認の代替**: EV証明書要求が証明書承認者として機能しない証明書要求者によって署名され提出された場合、[Section 3.2.2.2.9](#32229-verification-of-approval-of-ev-certificate-request-ev-tls-server-certificates) の要件に従って証明書承認者がEV証明書要求を承認および採択することで、そのEV証明書要求における証明書要求者の署名の認証に代わることができる。 ###### 3.2.2.2.8.2 Acceptable Methods of Signature Verification 3.2.2.2.8.2 許容される署名検証の方法 証明書要求者または契約署名者の署名を認証するための許容される方法は次のとおりである。 1. 申請者用の検証済み通信手段を使用して、該当する場合は証明書要求者または契約署名者宛に申請者に連絡し、その後、申請者に代わって該当する文書に署名したことを確認する、その人物であると特定される人物からの応答が続く。 2. 該当する場合は、EV Guidelinesに従って独立した手段で確認された申請者または代理人の住所に、証明書請求者または契約署名者宛てに手紙を郵送し、その後、本人確認ができた人物から、確認済みの通信手段を通じて、申請者に代わって該当文書に署名したことを確認する返信を送付する。 3. 署名前に署名者を識別する適切なセキュリティのログインプロセスの使用や、適切に検証された証明書を参照して作成されたデジタル署名の使用など、署名者の名前と肩書きを安全な方法で確立する署名プロセスの使用。 4. 公証人による公証。ただし、CAが、当該公証人が証明書要求者または契約署名者の管轄区域内で法的に資格のある公証人であることを独自に検証することを条件とする。 ##### 3.2.2.2.9 Verification of Approval of EV Certificate Request (EV TLS Server Certificates) 3.2.2.2.9 EV 証明書要求の承認の検証 (EV TLSサーバー証明書) ###### 3.2.2.2.9.1 Verification Requirements 3.2.2.2.9.1 検証要件 証明書要求者によってEV証明書要求が提出された場合、CAは要求されたEV証明書を発行する前に、権限のある証明書承認者がEV証明書要求を確認し、承認したことを確認しなければならない (MUST)。 ###### 3.2.2.2.9.2 Acceptable Methods of Verification 3.2.2.2.9.2 許容される検証方法 証明書承認者によるEV証明書要求の承認を確認するための許容される方法は次のとおりである。 1. 申請者のための検証済み通信方法を使用して証明書承認者に連絡し、証明書承認者がEV証明書要求を検討して承認したことを口頭または書面で確認する。 2. 指定されたアクセス制御された安全な Web サイトで 1 つ以上の新しいEV証明書要求が確認および承認可能であることを証明書承認者に通知し、その後、Web サイトで要求される方法で証明書承認者がログインして承認を示す。 3. [Section 3.2.2.2.8](#32228-verification-of-signature-on-subscriber-agreement-and-ev-certificate-requests-ev-tls-server-certificates) に従って、EV証明書要求に対する証明書承認者の署名を検証する。 ##### 3.2.2.2.10 Verification of Certain Information Sources (EV TLS Server Certificates) 3.2.2.2.10 特定の情報源の検証（EV TLSサーバー証明書） ###### 3.2.2.2.10.1 Verified Legal Opinion 3.2.2.2.10.1 検証済み法律意見書 1. **検証要件**: CAに提出された法律意見書に依拠する前に、CAは、その法律意見書が以下の要件を満たしていることを検証しなければならない (MUST)。 A. **作成者のステータス**: CAは、法律意見書が、申請者によって雇用され、申請者を代表する独立した法律専門家 (または申請者によって雇用されている社内法律専門家) (法律専門家) によって作成され、その法律専門家が次のいずれかに該当することを確認しなければならない（MUST）。 i. 申請者の設立または登録管轄国、または申請者が事務所または物理的な施設を維持している管轄区域で法律業務を行う資格を有する弁護士。 B. **意見の根拠**: CAは、弁護士が申請者に代わって行動していることおよび検証済み法律意見書の結論が、弁護士が表明した関連事実に関する精通と、弁護士の専門的判断および専門知識の行使に基づいていることを確認しなければならない (MUST)。 C. **真正性**: CAは検証済み法律意見書の信憑性を確認しなければならない (MUST)。 2. **許容される検証方法**: 検証済み法律意見書に対する前述の要件を確立するための許容される方法は次のとおりである。 A. **作成者のステータス**: CAは、該当する管轄区域でそのような法律専門家の登録またはライセンス発行を担当する当局に直接連絡して、法律意見の作成者の専門的地位を確認しなければならない (MUST)。 B. **意見の根拠**: 法律意見の文面には、弁護士が申請者に代わって行動していることおよび法律意見の結論が弁護士が関連事実に精通していることおよび弁護士の専門的判断と専門知識の行使に基づいていることが明記されていなければならない (MUST)。法律意見には、弁護士の管轄区域で慣例となっている免責事項やその他の制限事項を含めることもできる (MAY) が、その場合、免責される責任の範囲は、法律意見が誤っていることが判明した場合に弁護士に生じる重大なリスク（金銭的、専門的/評判上のリスク）を排除するほど大きくはない。 C. **真正性**: 法律意見の真正性を確認するには、CAは、法律専門家の登録またはライセンス発行を担当する機関に登録されている法律専門家の住所、電話番号、ファックス、または (利用可能な場合) Emailアドレスに電話をかけるか、法律意見のコピーを返送し、法律専門家または法律専門家のアシスタントから法律意見が真正であることの確認を得なければならない (MUST)。ライセンス発行機関から電話番号を入手できない場合、CAは、該当する電話会社、QGIS、または QIIS から提供された記録に記載されている法律専門家の番号を使用できる (MAY)。 意見が、文書の真正性と署名者の身元を確認する方法でデジタル署名されている場合、[Section 3.2.2.2.10.1](#3222101-verified-legal-opinion) (2)(A)でCAによって検証されているため、真正性のさらなる検証は必要ない。 ###### 3.2.2.2.10.2 Verified Accountant Letter 3.2.2.2.10.2 検証済み会計士確認書 1. **検証要件**: CAに提出された会計士確認書に依拠する前に、CAは、その会計士確認書が以下の要件を満たしていることを検証しなければならない (MUST)。 A. **作成者のステータス**: CAは、会計士確認書が申請者によって雇用または雇用され、申請者の設立管轄、登録管轄、または申請者が事務所や物理的な施設を維持している国でライセンスを取得した会計実務者によって作成されたものであることを確認しなければならない (MUST)。ライセンスの確認は、会計実務者の国または管轄内の組織または規制組織を通じて行わなければならない (MUST)。これらの組織は、その国または管轄内での会計士の実務ライセンスを確認する際に連絡を取るのに適切である。このような国または管轄には、国際会計士連盟の正式会員資格を保持している会計基準機関が必要である。 B. **意見の根拠**: CAは、会計実務者が申請者に代わって行動していることおよび検証済み会計士確認書の結論が会計実務者が関連する事実に精通していることおよび会計実務者の専門的な判断と専門知識の行使に基づいていることを確認しなければならない (MUST)。 C. **真正性**: CAは検証済み会計士証明書の真正性を確認しなければならない (MUST)。 2. **許容される検証方法**: 検証済み会計士証明書の前述の要件を確立するための許容される方法をここに示す。 A. **作成者のステータス**: CAは、該当する管轄区域で会計実務家の登録またはライセンス発行を担当する当局に直接連絡して、会計士確認書の作成者の専門的地位を確認しなければならない (MUST)。 B. **意見の根拠**: 認証された会計士確認書のテキストには、会計実務者が申請者に代わって行動していること、確認書内の情報は会計実務者が関連する事実に精通していることおよび実務者の専門的判断と専門知識の行使に基づいていることが明記されていなければならない (MUST)。認証された会計士確認書には、会計実務者の管轄区域で慣例となっている免責事項やその他の制限事項を含めることもできる (MAY)。ただし、認証された会計士確認書に誤りがあることが判明した場合に、免責される責任の範囲が会計実務者に対する重大なリスク (財務、専門的/評判) を排除するほど大きくないことが条件となる。 C. **真正性**: 会計士の意見の真正性を確認するには、CAは、会計士の登録またはライセンス発行を担当する機関に登録されている会計士の住所、電話番号、FAX、または (利用可能な場合) Emailアドレスに連絡するか、もしくは検証済み会計士確認書のコピーを会計士に送り返し、会計士確認書が信正正性があることを会計士または会計士のアシスタントから確認しなければならない (MUST)。ライセンス発行機関から電話番号を入手できない場合、CAは、該当する電話会社、QGIS、または QIIS から提供された記録に記載されている会計士の番号を使用できる (MAY)。 意見がデジタル署名されている場合、文書の真正性と署名者の身元がCAによって [Section 3.2.2.2.10.2](#3222102-verified-accountant-letter) (2)(A)で検証されたとおり確認され、それ以上の真正性の検証は必要ない。 ###### 3.2.2.2.10.3 Face-to-Face Validation 3.2.2.2.10.3 対面による検証 1. **検証要件**: CAに提出された対面審査文書に依拠する前に、CAは第三者の検証者が以下の要件を満たしていることを検証しなければならない (MUST)。 A. **第三者検証者の資格**: CAは、第三者の検証者が個人の居住地の管轄区域の公証人（または申請者の管轄区域における法的同等者）、弁護士、または会計士であることを独自に確認しなければならない (MUST)。 B. **文書保管の連鎖**: CAは、第三者の検証者が検証対象の個人と直接会って審査文書に目を通したことを確認しなければならない (MUST)。 C. **証明書の検証**: CAは、証明書および審査文書の真正性を確認しなければならない (MUST)。 2. **許容される検証方法**: 書類審査に関する前述の要件を確立するための許容される方法は次のとおりである。 A. **第三者検証者の資格**: CAは、該当する管轄区域で第三者検証者の登録またはライセンス発行を担当する当局に直接連絡して、第三者検証者の専門的ステータスを確認しなければならない (MUST)。 B. **文書保管の連鎖**: 第三者検証者は、個人との対面ミーティング中に、個人のためにCAに提出された審査文書を入手したことを証明する声明をCAに提出しなければならない (MUST)。 C. **証明書の検証**: CAは、第三者検証者から受け取った審査文書の真正性を確認しなければならない (MUST)。CAは第三者検証者に電話をかけ、第三者検証者またはそのアシスタントから対面検証を実施したという確認を得なければならない (MUST)。CAは、この検証プロセスを実行する目的でのみ、第三者検証者から取得した自己申告情報に依拠することができる (MAY)。証明書がデジタル署名されている場合、文書の真正性および [Section 3.2.2.2.10.3](#3222103-face-to-face-validation) (1)(A) で CA によって検証された署名者の ID を確認する方法で、真正性のさらなる検証は必要ない。 ###### 3.2.2.2.10.4 Independent Confirmation From Applicant 3.2.2.2.10.4 申請者から独立した確認 申請者から独立した確認とは、次のような特定の事実の確認（契約署名者または証明書承認者の従業員または代理店ステータスの確認、証明書承認者のEV権限の確認など）である。 A. 当該事実を確認する適切な権限を有し、かつ当該事実を確認した旨を表明する確認者（照会の対象者以外の者）からCAが受領したもの。 B. 確認のソースを認証および検証する方法でCAによって受領されるもの。 C. 申請者に対する拘束力があるもの。 申請者から独立した確認は、以下の手順で取得できる (MAY)。 1. **確認要求**: CAは、適切な別経路の通信手段を介して確認要求を開始し、問題となっている特定の事実の検証または確認を次のように要求しなければならない (MUST)。 A. **宛先**: 確認要求は必ず以下の宛先向けでなければならない (MUST)。 i. 申請者の組織内で確認者としての資格を有する役職（例：米国における会社秘書役（法務文書の管理責任者）、社長、CEO、CFO、COO、CIO、CSO、取締役など）であり、最新の QGIS、QIIS、QTIS、検証済み法律意見書、検証済み確認書または検証済み通信手段を使用して申請者に連絡することによって名前と役職が特定されていること。 ii. 設立機関の公式記録に記載されている、設立管轄区域内の申請者の登録代理人または登録事務所。適切な確認者に転送するよう指示する。 iii. 申請者の人事部に電話または郵便で連絡し、契約署名者または証明書承認者の直属の管理職であることが確認された指定の個人（EV Guidelinesに従って確認された申請者の事業所の電話番号または住所） B. **コミュニケーション手段**: 確認要求は、確認者に届く可能性が高い方法で確認者に伝達しなければならない (MUST)。次のオプションが許容される。 i. 確認者宛てに郵送の場合： - 1. EV Guidelinesに従ってCAにより確認された申請者の事業所住所 - 2. 最新のQGIS、QTIS、QIIS、検証済み専門家確認書に記載されている確認者の事業所住所 - 3. 設立管轄の公式記録に記載されている申請者の登録代理人または登録事務所の住所 ii. 最新のQGIS、QTIS、QIIS、検証済み法律意見書、または検証済み会計士確認書に記載されている確認者のビジネスメールアドレス宛てにEmailで送信する。 iii. 確認者への電話連絡。申請者の事業所の代表電話番号（EV Guidelinesに従って確認済み）に電話をかけ、確認者と話をしたい旨を伝え、電話を受けた人が確認者であることを確認する。 iv. 事業所の確認担当者にFAXで送信する。FAX番号は、最新の QGIS、QTIS、QIIS、検証済み法律意見書または検証済み会計士確認書に記載されていなければならない。表紙には、確認担当者宛てであることが明記されていなければならない。 2. **確認応答**: CAは、確認要求に対する応答を確認者から受け取り、問題となっている特定の事実を確認しなければならない (MUST)。このような応答は、確認要求に対する応答として確認者によって提供されたことをCAが確実に確認できる限り、電話、Emailまたは郵便でCAに提供できる (MAY)。 3. CAは、確認済みの確認者に、自身の連絡先情報 (Emailアドレス、電話番号およびFAX番号) を確認するよう依頼する場合がある (MAY)。CAは、次の場合に、確認者との今後のやり取りにこの確認済みの連絡先情報に依拠する場合がある (MAY)。 A. Emailアドレスのドメインは申請者が所有しており、確認者自身のEmailアドレスであり、グループEmailエイリアスではない。 B. 確認者の電話番号/FAX番号は、組織の電話システムの一部である電話番号であり、確認者の個人電話番号ではないことがCAによって確認される。 ###### 3.2.2.2.10.5 Qualified Independent Information Source 3.2.2.2.10.5 認定独立情報源 認定独立情報源 (QIIS) は、定期的に更新され、公開されているデータベースであり、特定の情報の信頼できる情報源として一般に認められている。CAが次のことを判断した場合、データベースは QIIS として認定される。 1. 証明書業界以外の業界では、正確な場所、連絡先、その他の情報についてデータベースに依存している。 2. データベースプロバイダーは少なくとも年に1回データを更新する。 CAは、データベースプロバイダの利用規約を確認するなど、データベースの正確性を確認し、そのデータが許容できるものであることを確認するために、文書化されたプロセスを使用する (SHALL)。CAは、CAが QIIS で不適切であると知っているデータを使用してはならない (SHALL NOT)。 i. 自己申告 ii. QIIS によって正確であると検証されていない。 CAまたはその所有者や関連会社が支配権を保持しているデータベース、またはCAが審査プロセスの一部を外注した登録機関や下請け業者 (またはその所有者や関連会社) が所有権や受益権を保持しているデータベースは、QIIS として適格ではない。 ###### 3.2.2.2.10.6 Qualified Government Information Source 3.2.2.2.10.6 認定政府情報源 認定政府情報源 (QGIS) は、定期的に更新され、最新の公開データベースで、参照される情報を正確に提供することを目的として設計されており、政府組織によって維持され、データの報告が法律で義務付けられ、虚偽または誤解を招く報告は刑事罰または民事罰の対象になるという条件で、信頼できる情報源として一般に認識されている。EV Guidelinesのいかなる条項も、第三者が政府組織から直接情報を取得することを条件として、第三者ベンダーを使用して政府組織から情報を取得することを禁止するものではない。 ###### 3.2.2.2.10.7 Qualified Government Tax Information Source 3.2.2.2.10.7 認定政府税務情報源 認定政府税務情報源とは、民間組織、事業体、または個人に関連する税務情報を具体的に含む認定政府情報源である (例: 米国の IRS)。 ##### 3.2.2.2.11 Other Verification Requirements (EV TLS Server Certificates) 3.2.2.2.11 その他の検証要件 (EV TLSサーバー証明書) ###### 3.2.2.2.11.1 High Risk Status 3.2.2.2.11.1 ハイリスクステータス Baseline Requirements のSection 4.2.1 のハイリスク証明書の要件は、EV証明書にも同様に適用される。 ###### 3.2.2.2.11.2 Denied Lists and Other Legal Block Lists 3.2.2.2.11.2 拒否リストおよびその他法的ブロックリスト 1. **検証要件**: CAは、申請者、契約署名者、証明書承認者、申請者の設立管轄、登録、または事業所が以下の条件を満たしているかどうかを検証しなければならない (MUST)。 A. CAの管轄区域の国の法律に基づき、そのような組織または個人との取引を禁止する政府の拒否リスト、禁止人物リスト、またはその他のリストに記載されている。 B. CAの管轄区域の法律により事業を行うことが禁止されている国に、設立管轄、登録管轄、または事業所がある。 申請者、契約署名者、証明書承認者のいずれか、または申請者の設立管轄区域、登録管轄区域、または事業所がそのようなリストに含まれている場合、CAは申請者に対してEV証明書を発行してはならない (MUST NOT)。 2. **許容される検証方法** CAは規制を確認するために合理的な手順を踏まなければならない (MUST)。 CAは、日本におけるすべての拒否リストおよび輸出規制を検証するために合理的な手順を踏まなければならない (MUST)。 ###### 3.2.2.2.11.3 Parent/Subsidiary/Affiliate Relationship 3.2.2.2.11.3 親会社/子会社/関連会社との関係 申請者の親会社、子会社、または関連会社の情報を使用して申請者を検証するCAは、[Section 3.2.2.2.3.1](#322231-address-of-applicants-place-of-business)、[Section 3.2.2.2.4](#32224-verified-method-of-communication-ev-tls-server-certificates)、 [Section 3.2.2.2.5.1](#322251-verification-requirements)、または [Section 3.2.2.2.6.1](#322261-verification-requirements)で許可されている場合、申請者と親会社、子会社、または関連会社との関係を検証しなければならない (MUST)。申請者と親会社、子会社、または関連会社との関係を検証する許容される方法は次のとおりである。 1. QIIS または QGIS: 申請者と親会社、子会社、または関連会社との関係は QIIS または QGIS で特定される。 2. 親会社、子会社、または関連会社からの独立した確認: CAは、適切な親会社、子会社、または関連会社から独立した確認を取得することにより、申請者と親会社、子会社、または関連会社との関係を確認することができる (MAY)([Section 3.2.2.2.10.4](#3222104-independent-confirmation-from-applicant)に記載)。 3. CAと親会社、子会社、または関連会社間の契約: CAは、契約が契約署名者によって署名され、契約署名者の機関および署名権限が検証されている場合に限り、CAと親会社、子会社、または関連会社との間で締結され、証明書承認者をそのようなEV権限とともに指定する契約を信頼することにより、申請者と親会社、子会社、または関連会社との関係を検証することができる (MAY)。 4. 検証済み専門家確認書: CAは、認証された専門家確認書に依拠し、申請者と親会社、子会社、または関連会社との関係を確認することができる (MAY)。 5. 法人決議: CAは、子会社または申請者の設立を承認する適切に認証された法人決議に依拠​​することにより、申請者と子会社の関係を検証することができる (MAY)。ただし、その決議が以下の条件を満たす必要がある。 i. 適切な法人役員（例：米国における会社秘書役（法務文書の管理責任者））によって認証される ii. CAは、証明書がその人物によって有効に署名されたことおよびその人物が証明書を提供するために必要な権限を持っていることを確実に検証できる (MAY)。 ##### 3.2.2.2.12 Final Cross-Correlation and Due Diligence (EV TLS Server Certificates) 3.2.2.2.12 最終的な相互照合と適切な精査 (EV TLSサーバー証明書) 1. EV Guidelinesで概説されている検証プロセスと手順の結果は、個別にもグループとしても確認されることが想定されている。したがって、検証プロセスと手順がすべて完了した後、CAは、情報収集の責任者ではない人物に、EV証明書の申請をサポートするために集められたすべての情報と文書をレビューさせ、矛盾点やさらに説明が必要な詳細がないか確認させなければならない (MUST)。 2. CAは、さらなる説明を必要とする矛盾や詳細を解決するために、必要に応じて、申請者、証明書承認者、証明書要求者、認定独立情報源およびその他の情報源から、さらなる説明や明確化を入手し、文書化しなければならない (MUST)。 3. CAは、EV証明書要求をサポートするために収集された情報と文書の集合全体が、EV証明書の発行によってCAが知っている事実情報、または収集された情報と文書から適切な精査の実行によって不正確であると判明する事実情報が伝達されないようになるまで、EV証明書の発行を控えなければならない (MUST)。十分な説明/追加文書が妥当な時間内に受信されない場合、CAはEV証明書要求を拒否しなければならず (MUST)、申請者にその旨を通知する必要がある (SHOULD)。 4. 申請をサポートするために使用された文書の一部またはすべてがCAの通常の運用言語以外の言語で書かれている場合、CAまたはその関連会社は、組織の識別と承認を確認し、[Section 5.3.2](#532-background-check-procedures) に含まれるすべての資格要件を満たすために、適切なトレーニング、経験、判断力を備えた管理下の従業員を使用して、この最終的な相互照合および適切な精査のSectionの要件を実行しなければならない (MUST)。CAの管理下にある従業員が最終的な相互照合および適切な精査を実行するために必要な言語スキルを持っていない場合、CAは次のことを行うことができる (MAY)。 A. 翻訳者が翻訳を受け取った場合、文書の関連部分の言語翻訳に依拠する。 B. CAがRAのサービスを利用している場合、RAが [Section 3.2.2.2.12](#322212-final-cross-correlation-and-due-diligence-ev-tls-server-certificates)、Sub Section (1)、(2)および (3) に準拠していることを条件として、CAは最終的な相互照合および適切な精査を実行するためにRAの言語スキルに依存することができる (MAY)。前述にかかわらず、EV証明書を発行する前にCAはRAによって完了した作業を確認し、すべての要件が満たされていることを確認しなければならない (MUST)。 C. CAがRAのサービスを利用している場合、RAがこのSectionに準拠し、 [Section 8.7](#87-self-audits) および [Section 8.2](#82-identityqualifications-of-assessor) の監査要件に従うことを条件として、CAは最終的な相互照合と適切な精査の実行をRAに依頼することができる (MAY)。 [Section 1.3.2](#132-registration-authorities) の要件に準拠して発行されるEV証明書の場合、エンタープライズRAは、この最終的な相互照合および適切な精査のSectionの要件を実行することができる (MAY)。 ##### 3.2.2.2.13 Requirements for Re-use of Existing Documentation (EV TLS Server Certificates) 3.2.2.2.13 既存ドキュメントの再利用に関する要件 (EV TLSサーバー証明書) 既存のEV証明書更新要求を含む各EV証明書要求について、CAは、要求が申請者によって適切に承認されていることおよびEV証明書の情報が正確かつ有効であることを確認するために、これらのガイドラインで要求されるすべての認証および検証タスクを実行しなければならない (MUST)。このSectionでは、CAが収集した文書の使用に関する年齢制限を規定する。 ###### 3.2.2.2.13.1 Validation For Existing Subscribers 3.2.2.2.13.1 既存の利用者検証 申請者がCAによって発行された現在有効なEV証明書を持っている場合、CAは以下の事前の認証と検証に依拠することができる (MAY)。 1. 当該個人が、申請者の以前に発行され現在有効なEV証明書に関連してCAによって確認された人物と同一人物である場合、[Section 3.2.2.2.1.2](#322212-acceptable-method-of-verification) に基づいて確認された本人。 2. [Section 3.2.2.2.3.1](#322231-address-of-applicants-place-of-business)に基づく申請者の事業所。 3. 申請者の検証済み通信方法は [Section 3.2.2.2.4](#32224-verified-method-of-communication-ev-tls-server-certificates) で要求されているが、[Section 3.2.2.2.4](#32224-verified-method-of-communication-ev-tls-server-certificates) (B) で要求されている検証を実行しなければならない (MUST)。 4. 申請者の事業上の存在 ( [Section 3.2.2.2.5](#32225-verification-of-applicants-operational-existence-ev-tls-server-certificates)に基づく） 5. 契約署名者および証明書承認者の氏名、役職、機関および権限（[Section 3.2.2.2.7](#32227-verification-of-name-title-and-authority-of-contract-signer-and-certificate-approver-ev-tls-server-certificates) 参照） 6. 申請者は、 [Section 3.2.2.2.6](#32226-verification-of-applicants-domain-name-ev-tls-server-certificates)に基づいて指定されたドメイン名を使用する権利を有する。ただし、CAが、最初のEV証明書の指定されたドメイン名を検証したときと同じ登録者が WHOIS レコードに表示されていることを検証する必要がある。 ###### 3.2.2.2.13.2 Re-issuance Requests 3.2.2.2.13.2 再発行要求 CAは、次の場合に、参照されている証明書が詐欺やその他の違法行為により失効されていない限り、以前に検証された証明書要求に基づいて代わりの証明書を発行できる。 1. 交換された証明書の有効期限は、交換されるEV証明書の有効期限と同じである。 2. 証明書の主体者識別名情報は、置き換えられるEV証明書の主体者識別名と同じである。 ###### 3.2.2.2.13.3 Age of Validated Data 3.2.2.2.13.3 検証済みデータの有効期限 1. [Section 3.2.2.2.13.2](#3222132-re-issuance-requests) に基づくEV証明書の再発行を除き、また[Section 3.2.2.2.13.1](#3222131-validation-for-existing-subscribers) で別途許可されている場合を除き、EV証明書の発行をサポートするために使用されるすべてのデータの経過期間 (再検証が必要になる前) は、次の制限を超えてはならない (SHALL NOT)。 A. 法的存在と身元 – 398 日間 B. 仮名 – 398 日間 C. 事業所の住所 – 398 日間 D. 検証済み通信手段 – 398 日間 E. 運用上の存在 – 398 日間 F. ドメイン名 – 398 日間 G. 名前、役職、機関、権限 – CAと申請者間の契約で異なる期間が指定されていない限り 398 日間。その場合は、その契約で指定された期間が適用される。たとえば、契約には、申請者またはCAによって失効されるまで、または契約が期限切れになるか終了するまで、EVの役割の永続的な割り当てが含まれる場合がある (MAY)。 2. 上記の 398 日間の期限は、CAによって情報が収集された日から開始される (SHALL)。 3. CAは、[Section 3.2.2.2.8](#32228-verification-of-signature-on-subscriber-agreement-and-ev-certificate-requests-ev-tls-server-certificates) および [Section 3.2.2.2.9](#32229-verification-of-approval-of-ev-certificate-request-ev-tls-server-certificates) で許可されている範囲で、同じ主体者識別名を含む複数のEV証明書をサポートするために単一のEV証明書要求を使用することを含め、以前に送信されたEV証明書要求、利用者契約、または利用規約を再利用できる (MAY)。 4. CAは、[Section 3.2.2.2.13.1](#3222131-validation-for-existing-subscribers) で別途許可されている場合を除き、上記の制限期間外で取得した情報については、EV Guidelinesで要求される検証プロセスを繰り返さなければならない (MUST)。 #### 3.2.2.3 Verification of Country 3.2.2.3 国名検証 If the `subject:countryName`フィールドが存在する場合、CAは次のいずれかを使用して、主体者識別名に関連付けられた国を検証する (SHALL)。 a. 要求されたドメイン名のccTLD b. ドメイン名登録機関が提供する情報 c. [Section 3.2.2.1](#3221-identity) で特定された方法。. #### 3.2.2.4 Validation of Domain Authorization or Control 3.2.2.4 ドメイン認証または管理の検証 **[TLSサーバー証明書]** このSectionでは、申請者のドメインの所有権または管理権を検証するための許可されたプロセスと手順を定義する。 CAは、発行前に、証明書に記載されている各完全修飾ドメイン名 (FQDN) を次のように検証したことを確認する (SHALL)。 CAは、以下にリストされている方法の少なくとも 1 つを使用して FQDN を検証する (SHALL)。 申請者の権限の完了した検証は、時間の経過とともに複数の証明書の発行に有効になる場合がある。いずれの場合も、証明書の発行前に、関連する要件 (このドキュメントの [Section 4.2.1](#421-performing-identification-and-authentication-functions) など) で指定された期間内に検証が開始されていなければならない。ドメイン検証の目的では、申請者という用語には、申請者の親会社、子会社、または関連会社が含まれる。 CAは、関連するBRバージョン番号を含む、すべてのドメインを検証するために使用したドメイン検証方法の記録を保持する (SHALL)。 **注**: FQDN は、`subjectAltName` 拡張の `dNSName` を使用して利用者証明書にリストされるか、または Name Constraints 拡張内の `permittedSubtrees` の `dNSName` を介して下位CA証明書にリストされることがある。 ##### 3.2.2.4.1 Validating the Applicant as a Domain Contact 3.2.2.4.1 ドメイン連絡先としての申請者の検証 セコムトラストシステムズではこの方法を使用しない。 ##### 3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact 3.2.2.4.2 ドメイン連絡先へのEmail、FAX、SMSまたは郵便 ランダム値を Email、ファックス、SMS または郵便経由で送信した後、レスポンス確認の受信により FQDN に対する申請者の権限を立証する。ランダム値はドメイン連絡先と認識される Emailアドレス、ファックス/SMS番号、または郵便アドレスでなければならない (MUST)。 それぞれの Email、ファックス、SMS または郵便は、複数認証ドメイン名の管理を確認できる。(MAY) CAは、本Sectionで特定される Email、ファックス、SMS、または郵便物を複数の受信者に送信してもよい (MAY)が、すべての受信者が、Email、ファックス、SMS、または郵便物を使用して検証されるすべての FQDN についてドメイン名登録者によってドメイン名登録者の代理として特定されていることを条件とする。 ランダム値はそれぞれの Email、ファックス、SMS または郵便に一意とする (SHALL)。 CAはランダム値の再利用を含めて、Email、ファックス、SMS または郵便全体を再送でき (MAY)、コミュニケーションの全体内容と受信者は変更しない条件とする。 ランダム値はその生成より30日間のレスポンス確認の使用に有効とする (SHALL)。CPSはランダム値の短縮有効期間を指定でき (MAY)、その場合CAはCPSに従わなければならない (MUST)。 **注**: この方式の使用で FQDN が承認されたら、CAは認証 FQDN のすべてのドメインラベルで終わる他の FQDN の証明書も発行できる (MAY) 。この方式はワイルドカードドメイン名の承認にも適している。 2025年1月15日より発効 - 利用者証明書を発行する場合、CAは、以前に取得した情報が再利用許可期間内であるかどうかに関係なく、HTTPS Web サイトを使用して取得したドメイン連絡先情報に依存してはならない (MUST)。 - 要求されたドメイン名のドメイン連絡先情報を取得する場合、CAは次の操作を行う。 - WHOIS プロトコル (RFC 3912) を使用する場合は、IANA の WHOIS サーバーにクエリを実行し、適切な WHOIS サーバーへの参照に従わなければならない (MUST)。 - レジストリデータアクセスプロトコル (RFC 7482)を使用する場合は、IANA のブートストラップファイルを使用して、ドメインの正しい RDAP サーバーを識別し、照会しなければならない (MUST)。 - 最新かつ正確な情報に依拠していることを保証するために、1) 48時間以上前の WHOIS サーバー情報、または 2) 48時間以上前の IANA からの RDAP ブートストラップデータにキャッシュされてはならない (MUST NOT)。 2025年 7月15日より発効 - CAはこの方法に依存してはならない (MUST NOT)。 - この方法を使用した以前の検証およびこの方法に従って収集された検証データは、利用者証明書の発行に使用してはならない (MUST NOT)。 ##### 3.2.2.4.3 Phone Contact with Domain Contact 3.2.2.4.3 ドメイン連絡先への電話連絡 セコムトラストシステムズではこの方法を使用しない。 ##### 3.2.2.4.4 Constructed Email to Domain Contact 3.2.2.4.4 ドメイン連絡先への指定アドレス宛Email FQDN 上の申請者管理の確認は、 1. ローカル部分として 'admin', 'administrator', 'webmaster', 'hostmaster', or 'postmaster'、("@")の後に認証されるドメイン名、 2. Emailにランダム値を含んで作成された 1つまたはそれ以上のアドレスへEmailを発信し 3. ランダム値を利用した確認レスポンスの受信にて行われる。 各Emailは、Emailで使用される承認ドメイン名が、確認される各 FQDN の承認ドメイン名である場合に、複数の FQDN の制御を確認することができる (MAY)。 ランダム値はそれぞれのEmailで一意とする (SHALL)。 Emailは、その内容全体と受信者が変更されない (SHALL) 限り、ランダム値の再利用を含めて完全に再送信されることがある (MAY)。 ランダム値はその生成より30日間以内のレスポンス確認の使用に有効とする (SHALL)。 **注**: この方法を使用して FQDN が検証されると、CAは検証された FQDN のすべてのドメインラベルで終わる他の FQDN の証明書も発行する場合がある (MAY)。この方法は、ワイルドカードドメイン名の検証に適している。 ##### 3.2.2.4.5 Domain Authorization Document 3.2.2.4.5 ドメイン認証文書 セコムトラストシステムズではこの方法を使用しない。 ##### 3.2.2.4.6 Agreed-Upon Change to Website 3.2.2.4.6 ウェブサイトへの合意に基づく変更 セコムトラストシステムズではこの方法を使用しない。 ##### 3.2.2.4.7 DNS Change 3.2.2.4.7 DNS変更 以下のいずれかで、DNS CNAME、TXT、またはCAAレコードにランダム値またはリクエストトークンが存在することを確認することで、申請者がFQDNを管理していることを確認する。 1. 認証ドメイン名 2. アンダースコア文字で始まるドメインラベルを接頭語に持つ認証ドメイン名 ランダム値が使用される場合、CAは証明書要求に一意のランダム値を提供するものとし (SHALL)、以下いずれかの後はランダム値を使用しない (SHALL NOT)。 1. 30日間 2. 申請者が証明書要求を提出した場合、証明書に関連する検証済み情報の再利用が許可される期間（EV Guidelinesの[Section 4.2.1](#421-performing-identification-and-authentication-functions) または EV ガイドラインの Section 3.2.2.14.3 など）。 この方法を使用するCAは、[Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration) で指定されているように、マルチパースペクティブ発行検証を実装しなければならない(MUST)。検証としてカウントするには、ネットワークパースペクティブは、プライマリネットワークパースペクティブと同じチャレンジ情報 (つまり、ランダム値またはリクエストトークン) を監視しなければならない (MUST)。 **注**: この方法を使用してFQDNが検証されると、CAは検証されたFQDNのすべてのドメインラベルで終わる他のFQDNの証明書も発行する場合がある (MAY)。この方法は、ワイルドカードドメイン名の検証に適している。 ##### 3.2.2.4.8 IP Address 3.2.2.4.8 IPアドレス セコムトラストシステムズではこの方法を使用しない。 ##### 3.2.2.4.9 Test Certificate 3.2.2.4.9 テスト証明書 セコムトラストシステムズではこの方法を使用しない。 ##### 3.2.2.4.10 TLS Using a Random Value 3.2.2.4.10 ランダム値を使用したTLS セコムトラストシステムズではこの方法を使用しない。 ##### 3.2.2.4.11 Any Other Method 3.2.2.4.11 その他の方法 セコムトラストシステムズではこの方法を使用しない。 ##### 3.2.2.4.12 Validating Applicant as a Domain Contact 3.2.2.4.12 ドメイン連絡先としての申請者検証 セコムトラストシステムズではこの方法を使用しない。 ##### 3.2.2.4.13 Email to DNS CAA Contact 3.2.2.4.13 DNS CAA連絡先へのEmail ランダム値をEmailで送信し、そのランダム値を使用した確認応答を受信することで、申請者がFQDNを管理していることを確認する。ランダム値は、DNS CAA Email連絡先に送信しなければならない (MUST)。関連するCAAリソースレコードセットは、RFC 8659 のSection 3 で定義されている検索アルゴリズムを使用して見つけなければならない (MUST)。 各Emailアドレスが検証中の各認証ドメイン名のDNS CAA Email連絡先である場合、各Emailは複数のFQDNの管理を確認することができる (MAY)。すべての受信者が検証中の各認証ドメイン名のDNS CAA Email連絡先である限り、同じEmailを複数の受信者に送信できる (MAY)。 ランダム値はそれぞれのEmailに一意とする。(SHALL) Emailはランダム値の再利用を含めて全体を再送でき(MAY)、全体内容と受信者は変更しない条件とする。(SHALL) ランダム値はその生成より30日間のレスポンス確認の使用に有効とする。(SHALL) CPSはランダム値の短縮有効期間を指定できる。(MAY) この方法を使用して検証を実行するCAは、[Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration) で指定されているように、マルチパースペクティブ発行検証を実装しなければならない (MUST)。検証としてカウントするには、ネットワークパースペクティブは、プライマリネットワークパースペクティブとしてドメイン検証に使用される同じ選択された連絡先アドレスを監視しなければならない (MUST)。 **注**: この方式の使用でFQDNが承認されたら、CAは認証されたFQDNのすべてのドメインラベルで終わる他のFQDNの証明書も発行できる。(MAY) この方式はワイルドカードドメイン名の承認にも適している。 ##### 3.2.2.4.14 Email to DNS TXT Contact 3.2.2.4.14 DNS TXT連絡先へのEmail ランダム値をEmailで送信し、そのランダム値を使用して確認応答を受信することで、申請者がFQDNを管理していることを確認する。ランダム値は、FQDNを検証するために選択された承認ドメイン名のDNS TXT レコードEmail連絡先に送信しなければならない (MUST)。 各Emailアドレスが検証中の各承認ドメイン名のDNS TXT Record のEmail連絡先である場合、各Emailは複数のFQDNの管理を確認することができる (MAY)。すべての受信者が検証中の各承認ドメイン名のDNS TXT Record のEmail連絡先である限り、同じEmailを複数の受信者に送信できる (MAY)。 ランダム値はそれぞれのEmailに一意とする。(SHALL) Emailはランダム値の再利用を含めて全体を再送でき(MAY)、全体内容と受信者は変更しない条件とする。(SHALL) ランダム値はその生成より30日間のレスポンス確認の使用に有効とする。(SHALL) CPSはランダム値の短縮有効期間を指定できる。(MAY) この方法を使用して検証を実行するCAは、[Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration) で指定されているように、マルチパースペクティブ発行検証を実装しなければならない (MUST)。検証としてカウントするには、ネットワークパースペクティブは、プライマリネットワークパースペクティブとしてドメイン検証に使用される同じ選択された連絡先アドレスを監視しなければならない (MUST)。 **注**: この方式の使用でFQDNが承認されたら、CAは認証されたFQDNのすべてのドメインラベルで終わる他のFQDNの証明書も発行できる。(MAY) この方式はワイルドカードドメイン名の承認に適している。 ##### 3.2.2.4.15 Phone Contact with Domain Contact 3.2.2.4.15 ドメイン連絡先への電話連絡 セコムトラストシステムズではこの方法を使用しない。 ##### 3.2.2.4.16 Phone Contact with DNS TXT Record Phone Contact 3.2.2.4.16 DNS TXT連絡先への電話連絡 セコムトラストシステムズではこの方法を使用しない。 ##### 3.2.2.4.17 Phone Contact with DNS CAA Phone Contact 3.2.2.4.17 DNS CAA連絡先への電話連絡 セコムトラストシステムズではこの方法を使用しない。 ##### 3.2.2.4.18 Agreed-Upon Change to Website v2 3.2.2.4.18 ウェブサイトへの合意に基づく変更 v2 リクエストトークンまたはランダム値がファイルの内容に含まれていることを検証することで、申請者がFQDNを管理していることを確認する。 1. リクエストトークン全体またはランダム値が、ファイルを取得するために使用されるリクエストに現れてはならない (MUST NOT)。 2. CAはリクエストから正常なHTTP応答を受信しなければならない(MUST)（つまり、2xx HTTPステータスコードを受信しなければならない）。 リクエストトークンまたはランダム値を含むファイル 1. 承認ドメイン名に配置しなければならない (MUST)。 2. 「/.well-known/pki-validation」ディレクトリの下に配置しなければならない (MUST)。 3. 「http」または「https」スキームのいずれかを介して取得しなければならない (MUST)。 4. 承認済みポートを介してアクセスしなければならない (MUST)。 CAがリダイレクトに従う場合、以下が適用される。 1. リダイレクトはHTTPプロトコル層で開始しなければならない (MUST)。 a. 2021年7月1日以降に実行される検証の場合、リダイレクトは、[RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4) で定義されている 301、302、または 307 HTTP ステータス コード応答の結果、または [RFC 7538, Section 3](https://tools.ietf.org/html/rfc7538#section-3) で定義されている 308 HTTP ステータスコード応答の結果でなければならない (MUST)。リダイレクトは、 [RFC 7231, Section 7.1.2](https://tools.ietf.org/html/rfc7231#section-7.1.2) で定義されている Location HTTP 応答ヘッダーの最終値でなければならない (MUST)。 b. 2021年7月1日より前に実行された検証の場合、リダイレクトは、[RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4)で定義されている 3xx リダイレクトクラスのステータスコード内の HTTP ステータスコード結果でなければならない (MUST)。CAは、受け入れ可能なステータス コードとリソース URL を 1.a 内で定義されているものに制限する必要がある (SHOULD)。 2. リダイレクトは、「http」または「https」スキームのいずれかのリソースURLに対して行わなければならない (MUST)。 3. リダイレクトは、承認されたポート経由でアクセスされるリソースURLに対して行わなければならない (MUST)。 ランダム値を使用する場合、次のようになる。 1. CAは証明書要求に一意のランダム値を提供しなければならない (MUST)。 2. ランダム値は、確認応答での使用のために、その作成から30日以内有効でなければならない (MUST)。CPSは、ランダム値の有効期間をより短く指定しても良い（MAY）。その場合、CAはCPSに従わなければならない (MUST)。 オニオンドメイン名を除き、この方法を使用するCAは、[Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration) で指定されているように、マルチパースペクティブ発行検証を実装しなければならない(MUST)。検証としてカウントするには、ネットワークパースペクティブは、プライマリ ネットワークパースペクティブと同じチャレンジ情報 (ランダム値またはリクエストトークンなど) を監視しなければならない(MUST)。 **注**: - CAは、承認された方法を使用してそのFQDNに対して個別の検証を実行しない限り、検証されたFQDNのすべてのラベルで終わる他のFQDNに対して証明書を発行してはならない（MUST NOT）。この方法は、ワイルドカードドメイン名の検証には適していない。 ##### 3.2.2.4.19 Agreed-Upon Change to Website - ACME 3.2.2.4.19 ウェブサイトへの合意に基づく変更 - ACME RFC 8555 のSection 8.3 で定義されているACME HTTP チャレンジメソッドを使用してFQDNのドメイン制御を検証することにより、申請者のFQDNの制御を確認する。以下は、RFC 8555への追加要件である。 CAは、リクエストから正常なHTTP応答を受信しなければならない (つまり、2xx HTTP ステータスコードを受信しなければならない) (MUST)。 トークン（RFC 8555、Section8.3で定義）は、作成から30日を超えて使用してはならない（MUST NOT）。CPSは、ランダム値の有効期間をより短く指定してもよい（MAY）が、そその場合、CAはCPSに従わなければならない (MUST)。 CAがリダイレクトに従う場合、以下が適用される。 1. リダイレクトはHTTPプロトコル層で開始しなければならない (MUST)。 a. 2021年7月1日以降に実行される検証の場合、リダイレクトは、[RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4) で定義されている 301、302、または 307 HTTP ステータスコード応答の結果、または [RFC 7538, Section 3](https://tools.ietf.org/html/rfc7538#section-3) で定義されている 308 HTTP ステータスコード応答の結果でなければならない (MUST)。リダイレクトは、[RFC 7231, Section 7.1.2](https://tools.ietf.org/html/rfc7231#section-7.1.2) で定義されている Location HTTP 応答ヘッダーの最終値でなければならない (MUST)。 b. 2021年7月1日より前に実行された検証の場合、リダイレクトは、[RFC 7231, Section 6.4](https://tools.ietf.org/html/rfc7231#section-6.4) で定義されている 3xx リダイレクトクラスのステータスコード内の HTTP ステータスコード結果でなければならない (MUST)。CAは、受け入れ可能なステータスコードとリソースURLを 1.a 内で定義されているものに制限する必要がある (SHOULD)。 2. リダイレクトは、「http」または「https」スキームのいずれかのリソースURLに対して行わなければならない (MUST)。 3. リダイレクトは、承認されたポート経由でアクセスされるリソースURLに対して行わなければならない (MUST)。 オニオンドメイン名を除き、この方法を使用して検証を実行するCAは、[Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration) で指定されているように、マルチパースペクティブ発行検証を実装しなければならない (MUST)。検証としてカウントするには、ネットワークパースペクティブは、プライマリネットワークパースペクティブと同じチャレンジ情報 (つまり、トークン) を監視しなければならない (MUST)。 **注**: \* CAは、承認された方法を使用して他のFQDNごとに個別の検証を実行しない限り、検証されたFQDNのすべてのラベルで終わる他のFQDNの証明書を発行してはならない (MUST nOT)。この方法は、ワイルドカードドメイン名の検証には適していない。 ##### 3.2.2.4.20 TLS Using ALPN 3.2.2.4.20 ALPNを使用したTLS セコムトラストシステムズではこの方法を使用しない。 #### 3.2.2.5 Authentication for an IP Address 3.2.2.5 IPアドレス認証 **[TLSサーバー証明書]** セコムトラストシステムズでは、IPアドレスを認証して証明書を発行しない。 #### 3.2.2.6 Wildcard Domain Validation 3.2.2.6 ワイルドカードドメイン認証 **[TLSサーバー証明書]** ワイルドカード証明書を発行する前に、CAは、証明書内のワイルドカードドメイン名のFQDN部分が「レジストリ制御」であるか「パブリックサフィックス」であるか (例: "\*.com", "\*.co.jp"、詳細については、RFC 6454 Section 8.2 を参照) を決定する文書化された手順を確立し、それに従わなければならない (MUST)。 ワイルドカードドメイン名のFQDN部分が「レジストリ制御」または「パブリックサフィックス」である場合、申請者がドメイン名全体の正当な制御を証明しない限り、CAは発行を拒否しなければならない (MUST)。(例: CAは「\*.co.jp」または「\*.local」を発行してはならない (MUST NOT)が、「\*.example.com」を Example Co. に発行することはできる (MAY))。 国別コードトップレベルドメイン名空間の「レジストリ制御」部分と登録可能部分の決定は、執筆時点では標準化されておらず、DNS自体のプロパティではない。現在のベストプラクティスは、 [Public Suffix List (PSL)]()などの「パブリックサフィックスリスト」を参照して、定期的に最新のコピーを取得することである。 PSLを使用する場合、CAは「プライベートドメイン」Sectionではなく、「ICANN ドメイン」Sectionのみを参照する必要がある (SHOULD)。PSLは定期的に更新され、ICANNによって委任された新しい gTLD が含まれる。これらの gTLD は、「ICANN ドメイン」Sectionにリストされている。名前空間全体の制御が適切な方法で実証されている場合、CAは gTLD 全体の登録者にワイルドカード証明書を発行することを禁止されていない。 #### 3.2.2.7 Data Source Accuracy 3.2.2.7 データソースの正確性 信頼できるデータソースとしてデータソースを使用する前に、CAはソースの信頼性、正確性および変更や改ざんに対する耐性を評価する (SHALL)。CAは評価中に次の点を考慮する必要がある (SHOULD)。 1. 提供された情報の古さ 2. 情報源の更新頻度 3. データ提供者とデータ収集の目的 4. データ入手の公開性 5. データの改ざんが比較的困難であること CA、その所有者、またはその関連会社によって管理されるデータベースは、データベースの主な目的が本 [Section 3.2](#32-initial-identity-validation) の検証要件を満たす目的で情報を収集することである場合、信頼できるデータ ソースとして適格ではない。 #### 3.2.2.8 CAA Records 3.2.2.8 CAAレコード **[TLSサーバー証明書]** 証明書発行プロセスの一環として、CAは、Onion ドメイン名を含まない `subjectAltName` 拡張子の各 `dNSName` について、RFC 8659 に従ってCAAレコードを取得して処理しなければならない (MUST)。これらの方法は、CAのCP/CPSの Section 4.2 で説明しなければならない (MUST)。これには、CAが発行を許可するものとしてCAAの「issue」または「issuewild」レコードで認識する発行者ドメイン名のセットを指定することが含まれる。 証明書に記載される対象ドメイン ([Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) を参照) または IP アドレス ([Section 3.2.2.5](#3225-authentication-for-an-ip-address)を参照) に対する申請者の所有権または管理権を検証するために使用する方法の中には、証明書の発行 ([Section 3.2.2.9](#3229-multi-perspective-issuance-corroboration) を参照) の前に追加のリモートネットワークパースペクティブからCAAレコードを取得して処理する必要があるものがある。プライマリネットワークパースペクティブを確認するには、両方のパースペクティブからの応答がバイト単位で同一であるかどうかに関係なく、リモートネットワークパースペクティブのCAAチェック応答を発行許可として解釈しなければならない (MUST。さらに、CAは、このSectionで定義されているように、1 つまたは両方のパースペクティブで許容可能なCAAレコード検索エラーが発生した場合、リモートネットワークパースペクティブからの応答を確認と見なすことができる (MAY)。 CAは他の時点でもCAAレコードをチェックする場合がある (MAY)。 CAAレコードを処理する場合、CAは RFC 8659 で指定されているように、issue、issuewildおよび iodef プロパティタグを処理しなければならない (MUST)が、iodef プロパティタグの内容に基づいて動作する必要はない。追加のプロパティタグはサポートされる場合がある (MAY)が、このドキュメントで規定されている必須のプロパティタグと競合したり、それらのプロパティタグに取って代わったりしてはならない (MUST NOT)。CAは、クリティカルフラグを尊重しなければならず (MUST)、このフラグが設定された認識されないプロパティタグに遭遇した場合は証明書を発行しない。 CAがCAAレコードを処理した後に証明書を発行する場合は、CAAレコードのTTL内、または 8 時間のいずれか長い方で発行しなければならない (MUST)。 RFC 8659 では、CAは「(1) 証明書要求が該当する CAA RRset と一致している、または (2) 関連するCPまたはCPSで指定された例外が適用されるとCAが判断しない限り、証明書を発行してはならない (MUST NOT)」と規定されている。 Baseline Requirements に準拠した発行の場合、CAは、次のいずれかに該当しない限り、CPまたはCPSで指定された例外に依存してはならない (MUST NOT)。 - CAAチェックは、証明書の透明性事前証明書 ([Section 7.1.2.9](#7129-precertificate-profile) を参照) が作成され、少なくとも 2 つのパブリックログに記録され、事前証明書の発行時にCAAがチェックされた証明書の場合、オプションである。 - [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) または[Section 7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile) に規定されている技術的に制約のある下位CA証明書によって発行された証明書の場合、CAAチェックはオプションである。この場合、申請者との契約においてCAAチェックを行わないことが明示的な契約条項となっている。 CAは、次の場合にレコード検索の失敗を発行許可として扱うことができる。 - 失敗がCAの基盤外である場合 - レコード検索が少なくとも一度は再試行されている - ドメインのゾーンにICANNルートへのDNSSEC検証チェーンを持っていない CAは、CAAレコードによって阻止された潜在的な発行について、CA/ブラウザフォーラムに状況に関するフィードバックを提供できるように十分な詳細を文書化しなければならない (MUST)。また、CAA iodef レコードに規定されている連絡先がある場合は、その連絡先にそのような発行要求のレポートを送信する必要がある (SHOULD)。CAは、mailto: または https 以外の URL スキームを iodef レコードでサポートする必要はない。 FQDNに証明書を発行する権限を付与する証明書利用者は、各DNSゾーンのCAAレコードのプロパティ「issue」または「issuewild」に「**``"secomtrust.net"``**」の値を含めなければならない。 証明書利用者の各DNSゾーンにすでにCAAエントリーがあり、このCAによって証明書が発行される必要がある場合は、CAAレコードのプロパティ「issue」または「issuewild」に「**``"secomtrust.net"``**」の値を含めなければならない。 #### 3.2.2.9 Multi-Perspective Issuance Corroboration 3.2.2.9 マルチパースペクティブ発行検証 **[TLSサーバー証明書およびS/MIME 証明書]** マルチパースペクティブ発行検証は、証明書の発行前に、プライマリネットワークパースペクティブによって行われた決定 (ドメイン検証の合格/不合格、CAAの許可/禁止など) を複数のリモートネットワークパースペクティブから確認しようとする。このプロセスにより、同様に特定のプレフィックスのボーダーゲートウェイプロトコル (BGP) 攻撃やハイジャックに対する保護を強化できる。 CAは、必要な 1) ドメイン認証または制御および 2) CAAレコードチェックに対してマルチパースペクティブ発行検証を実行するときに、同じセットまたは異なるセットのネットワークパースペクティブを使用できる (MAY)。 依存するネットワークパースペクティブからの応答セットは、CAが肯定的に評価できるようにするために必要な情報を提供しなければならない (MUST)。 - a. Section 3.2.2.4 および 3.2.2.5 で指定された検証方法で要求されていて、想定される 1)ランダム値、2)リクエストトークン、3)IPアドレス、または 4)連絡先アドレスの存在 - b. Section 3.2.2.8 に指定されているように、要求されたドメインに対して発行するCAの権限 [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) では、マルチパースペクティブ発行検証の使用を必要とする検証方法と、ネットワークパースペクティブがプライマリネットワークパースペクティブによって決定された結果を確認する方法について説明する。 あるネットワークパースペクティブから取得された結果または情報は、後続のネットワークパースペクティブを通じて検証を実行するときに再利用またはキャッシュしてはならない (MUST NOT) (たとえば、異なるネットワークパースペクティブは、共有DNSキャッシュに依存して、あるネットワークパースペクティブからのトラフィックを制御する攻撃者が他のネットワークパースペクティブが使用するDNSキャッシュを汚染するのを防ぐことはできない)。ネットワークパースペクティブへのインターネット接続を提供するネットワーク基盤は、ネットワークパースペクティブを運用するために必要な計算サービスを提供する同じ組織によって管理される場合がある (MAY)。リモートネットワークパースペクティブとCA間のすべての通信は、最新のプロトコル (HTTPS経由など) に依存する認証および暗号化されたチャネルを介して行わなければならない (MUST)。 ネットワークパースペクティブは、ネットワークパースペクティブと同じ場所に配置されていない再帰DNSリゾルバを使用できる (MAY)。ただし、ネットワークパースペクティブが使用するDNSリゾルバは、それに依存するネットワークパースペクティブと同じ地域インターネットレジストリサービスリージョン内になければならない (MUST)。さらに、マルチパースペクティブ発行検証の試行で使用されるDNSリゾルバのペアの場合、2 つのDNSリゾルバ間の直線距離は少なくとも500 kmでなければならない (MUST)。DNSリゾルバの場所は、通常、カプセル化されていない送信DNSクエリが、そのDNSリゾルバにインターネット接続を提供するネットワーク基盤に最初に渡されるポイントによって決まる。 CAは、同じ検証方法または代替方法を使用して、マルチ パースペクティブ発行確認を直ちに再試行できる (MAY) (例: 「合意された Web サイトの変更 -ACME」がマルチパースペクティブ発行検証の結果を裏付けない場合、CAは「DNS TXT連絡先へのEmail」を使用して直ちに検証を再試行できる)。マルチパースペクティブ発行検証を再試行する場合、CAは以前の試行からの裏付けに依存してはならない (MUST NOT)。任意の期間に実行できる検証試行の最大回数に関する規定はない。 「定足数要件」表は、マルチパースペクティブ発行検証に関連する定足数要件について説明している。CAがドメイン認証または制御とCAAレコード チェックの両方で同じネットワークパースペクティブセットに依存していない場合、両方のネットワークパースペクティブセット (つまり、ドメイン認証または制御セットとCAAレコードチェックセット) で定足数要件を満たさなければならない(MUST)。ネットワークパースペクティブ間の直線距離が 500 km 以上の場合、ネットワークパースペクティブは別個であると見なされる。ネットワークパースペクティブは、プライマリネットワークパースペクティブおよび定足数で表されている他のネットワークパースペクティブとは異なる場合、「リモート」であると見なされる。 CAは、CAAレコードの定足数準拠の裏付けとなる証拠を最大 398 日間再利用できる (MAY)。ドメインに証明書を発行した後、リモートネットワークパースペクティブは、同じ申請者からの後続の証明書要求において、同じドメインまたはそのサブドメインのCAAレコードの取得と処理を最大 398 日間省略できる (MAY)。 表: 定足数要件 | 使用される個別のリモートネットワークパースペクティブの数 | 許可された非確認の数 | | -------------------------------------------------------- | -------------------- | | 2-5 | 1 | | 6+ | 2 | マルチパースペクティブ発行検証を実行するリモート ネットワーク パースペクティブ MUST (必須) - ネットワークの強化 - ネットワークパースペクティブにインターネット接続を提供するためには、グローバルインターネットルーティングシステムでBGPルーティングインシデントを軽減する対策を実装しているネットワーク (インターネットサービスプロバイダーやクラウドプロバイダーネットワークなど) に依存する。 SHOULD (推奨) - 施設およびサービスプロバイダーの要件 - ISO/IEC 27001 認定施設または独立して監査および認証あるいは報告された同等のセキュリティフレームワークからホストされていること。 - 次のいずれかのレポートでカバーされているサービスに依存していること: System and Organization Controls 2 (SOC 2)、IASE 3000、ENISA 715、FedRAMP Moderate、C5:2020、CSA STAR CCM、または独立して監査および認証または報告された同等のサービスフレームワーク。 - 脆弱性の検出とパッチ管理 - 一般的なネットワークおよびシステムの脅威から保護するために、侵入検知および防止制御を実装する。 - 脆弱性の特定、レビュー、対応および修復に対処する脆弱性修正プロセスを文書化し、それに従う。 - 少なくとも 3 か月ごとに脆弱性スキャンを実施する。 - 少なくとも年に 1 回侵入テストを実施する。 - セキュリティパッチを適用すると、セキュリティパッチを適用する利点を上回る追加の脆弱性または不安定性が生じるとCAが文書化していない限り、セキュリティパッチが利用可能になってから 6 か月以内に、推奨されるセキュリティパッチを適用する。 - システムの強化 - 使用されていないすべてのアカウント、アプリケーション、サービス、プロトコル、ポートを無効にする。 - すべてのユーザーアカウントに多要素認証を実装する。 - ネットワークの強化 - 各ネットワーク境界制御 (ファイアウォール、スイッチ、ルーター、ゲートウェイ、またはその他のネットワーク制御デバイスまたはシステム) を、その操作に必要であると特定されたサービス、プロトコル、ポートおよび通信のみをサポートするルールで構成する。 - 1)セキュアインタードメインルーティング (RFC 6480) に基づくメカニズム (BGP プレフィックスオリジン検証 (RFC 6811) など) を使用する、2) その他の非 RPKI ルート漏洩防止メカニズム (RFC 9234 など) を使用する、3) BCP 194 で説明されている現在のベストプラクティスを適用する、といったネットワーク (インターネットサービスプロバイダーなど) に依存する。通常の動作条件下では、マルチパースペクティブ発行検証を実行するネットワーク パースペクティブが、RFC 6811 で定義されているように RPKI が無効な BGP ルートをフィルター処理するネットワークまたはネットワーク セットを介してすべてのインターネット トラフィックを転送することが推奨 (RECOMMENDED) されるが、必須(REQUIRED)ではない。 上記の考慮事項に加えて、マルチパースペクティブ発行検証を実行するコンピューティング システムは、Baseline Requirements Section 8 で説明されている監査範囲外であると見なされる。 上記の考慮事項のいずれかが外部委託先によって実行される場合、CAは、上記の考慮事項の 1 つ以上が遵守されていることを確認するために、外部委託先から合理的な証拠を取得する場合がある (MAY)。Section 1.3.2 の例外として、外部委託先は、上記の考慮事項を満たすために、Baseline Requirements Section 8 に記載されている監査範囲内にいる必要はない。 段階的な実装タイムライン - *2024年9月15日より*, CAは少なくとも 2 つのリモートネットワークパースペクティブを使用して、マルチパースペクティブ発行検証を実装する必要がある (SHOULD)。 - *2025年3月15日より*, CAは少なくとも 2 つのリモートネットワークパースペクティブを使用して、マルチパースペクティブ発行検証を実装しなければならない (MUST)。プライマリネットワークパースペクティブによる決定を裏付けないリモートネットワークパースペクティブ (「非裏付け」) の数が定足数要件テーブルで許可されている数より多い場合、CAは証明書の発行を続行できる (MAY)。 - *2025年 9月15日より*, CAは少なくとも 2 つのリモートネットワークパースペクティブを使用して、マルチパースペクティブ発行検証を実装しなければならない (MUST)。非検証の数が定足数要件表で許可されている数よりも多い場合、　CAは証明書の発行を進めてはならない (MUST NOT)。 - *2026年 3月15日より*, CAは少なくとも 3 つのリモートネットワークパースペクティブを使用して、マルチパースペクティブ発行検証を実装しなければならない (MUST)。CAは、定足数要件表で定義された要件が満たされていることおよびプライマリネットワークパースペクティブを裏付けるリモートネットワークパースペクティブが少なくとも 2 つの異なる地域インターネットレジストリのサービス地域内にあることを確認しなければならない (MUST)。要件が満たされていない場合、CAは証明書の発行を進めてはならない (MUST NOT)。 - *2026年 6月15日より*, CAは少なくとも 4 つのリモートネットワークパースペクティブを使用して、マルチパースペクティブ発行検証を実装しなければならない (MUST)。CAは、定足数要件表で定義された要件が満たされていることおよびプライマリネットワークパースペクティブを裏付けるリモートネットワークパースペクティブが少なくとも 2 つの異なる地域インターネットレジストリのサービス地域内にあることを確認しなければならない (MUST)。要件が満たされていない場合、CAは証明書の発行を進めてはならない (MUST NOT)。 - *2026年12月15日より*, CAは少なくとも 5 つのリモートネットワークパースペクティブを使用して、マルチパースペクティブ発行検証を実装しなければならない (MUST)。CAは、定足数要件表で定義された要件が満たされていることおよびプライマリネットワークパースペクティブを確認するリモートネットワークパースペクティブが少なくとも 2 つの異なる地域インターネットレジストリのサービス地域内にあることを確認しなければならない (MUST)。要件が満たされていない場合、CAは証明書の発行を進めてはならない (MUST NOT)。 ### 3.2.3 Authentication of individual identity 3.2.3 個人認証 セコムトラストシステムでは、以下の証明書ポリシー識別子に準拠する個人認証証明書 (IV証明書) を発行しない。 {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) individual-validated(3)} (2.23.140.1.2.3) **[ドキュメントサイニング証明書とクライアント認証証明書]** セコムトラストシステムズは、国や地方公共団体が発行する公文書、調査結果、セコムトラストシステムズが信頼するサードパーティのデータベース、または認証サービス向上委員会が同等に信頼できると判断した方法に基づき、申請者または利用者の本人確認を行う。申請者および加入者の審査は、セコムトラストシステムズが別途定める条件、またはSECOM Passport for PublicID LRA運用基準（以下「LRA運用基準」）に基づきLRAが定める方法により行われる。 **[AATL ドキュメントサイニング証明書]** AATLドキュメントサイニング証明書の証明書発行には、以下の方法が使用される。組織に属する個人を認証する場合、CAは代表者または代表者から委任された人物の存在を確認する。公務員の公職を認証する場合、CAは代表者または代表者から委任された人物の存在を確認する。代表者または代表者から委任された人物は、個人の身元を直接確認し、一致を確認した人物である。個人の身元は、次のいずれかの方法で認証される。 1. 書面で受領した申請書に添付された申請者の印影を確認する。 2. 公的文書を使用して申請者の身元を確認する。 3. 信頼できる第三者から取得した住所を使用して、申請者に対して郵便によるチャレンジ/レスポンスを実行する。 4. 信頼できる第三者の電話番号を使用して申請者に対して電話によるチャレンジ/レスポンスを実行する。 5. 信頼できる第三者のEmailアドレスを使用して、申請者に対してEmailによるチャレンジ/レスポンスを実行する。 審査に使用された情報は、CAが定める期間内であれば再利用できる。 #### 3.2.3.1 Attribute collection of organization identity (S/MIME Certificates) 3.2.3.1 組織のアイデンティティ属性の収集 (S/MIME 証明書) CAまたはRAは、組織の以下のアイデンティティ属性を裏付ける証拠を収集し、保持する (SHALL)。 1. 法人の正式名称 2. 法人の住所（主体者識別名に含まれている場合） 3. 法人の設立または登録の管轄 ### 3.2.4 Non-verified subscriber information 3.2.4 未検証の利用者情報 検証されていない証明書利用者に関する情報は、CAによって発行される証明書には含まれない。 ### 3.2.5 Validation of authority 3.2.5 権限検証 主体者識別名識別情報を含む証明書の申請者が組織である場合、CAは、信頼できる通信手段を使用して、申請権限者による証明書要求の真正性を検証する (SHALL)。 CAは、[Section 3.2.2.1](#3221-identity) に掲載された情報源を使用して、信頼できる通信手段を検証できる (MAY)。CAが信頼できる通信手段を使用することを条件として、CAは、申請権限者、申請者組織内の権限のある情報源 (申請者の本社、経営部門、人事部門、情報技術部門、またはCAが適切と見なすその他の部門) と直接やり取りして、証明書要求の真正性を確認できる (MAY)。 加えて、CAは、証明書を申請できる個人を申請者に指定させるプロセスを確立する (SHALL)。申請者が、証明書を申請できる個人を書面で指定している場合、CAは指定外の者による証明書要求を受け入れない (SHALL NOT)。CAは、申請者の検証済み申請書に関して、認証された証明書要求者のリストを提供する (SHALL)。 **[S/MIME 証明書]** CAまたはRAは、信頼できる通信手段を使用して、申請者代表が次の 1 つ以上の操作を実行する権限と承認を確認する (SHALL)。 - Enterprise RAとしての役割を果たす。 - 証明書の発行または失効を要求する。 - これらの役割を果たすために他の人に責任を割り当てる。 CAまたはRAは、申請者が継続的に申請者代理人として行動できる個人を指定できるプロセスを確立することができる (MAY)。CAは、申請者からの確認済みの書面による要求に応じて、承認された申請者代理人のリストを申請者に提供する (SHALL)。 CAまたはRAは、[Section 3.2.3.1](#3231-attribute-collection-of-organization-identity-smime-certificates) に記載されている情報源を使用して、信頼できる通信方法を検証できる (MAY)。CAまたはRAが信頼できる通信方法を使用する場合、CAまたはRAは、申請者の代表者または申請者の組織内の権威ある情報源 (申請者の主要な営業所、企業オフィス、人事部、情報技術部、またはCAまたはRAが適切と見なすその他の部門など) と直接連絡を取り、証明書要求の信頼性を確立できる (MAY)。 ### 3.2.6 Criteria for Interoperation or Certification 3.2.6 相互運用または認証の基準 CAは、信頼関係の確立を計画または承認した場合 (つまり、問題のクロス認証された下位CA証明書)、CAを主体者識別名として識別するすべてのクロス認証された下位CA証明書を開示する (SHALL)。 ## 3.3 Identification and authentication for re-key requests 3.3 鍵更新申請時の本人性確認と認証 ### 3.3.1 Identification and authentication for routine re-key 3.3.1 通常の鍵更新時における本人性確認と認証 利用者は、[Section 3.2](#32-initial-identity-validation) に規定されているのと同じ方法で、鍵更新のために識別および認証される (SHALL)。 ### 3.3.2 Identification and authentication for re-key after revocation 3.3.2 証明書失効後の鍵更新時における本人性確認と認証 失効後の定期的な鍵更新はサポートされていない。証明書の（鍵更新）申請は新規申請として扱われ、申請者である利用者は、[Section 3.2](#32-initial-identity-validation) に規定されているのと同じ方法で識別および認証される (SHALL)。 ## 3.4 Identification and authentication for revocation request 3.4 失効申請時の本人性確認と認証 CAは、所定の手順に従って利用者または申請者からの失効要求を受け付け、利用者を識別して認証する。 # 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS 4 証明書ライフサイクルの運用要件 ## 4.1 Certificate Application 4.1 証明書申請 ### 4.1.1 Who can submit a certificate application 4.1.1 証明書を申請できる者 証明書の申請をすることができる者は、証明書を利用する個人、法人、その他の団体、証明書の利用者から委任を受けた代理人（以下「申請者」）とする。 [Section 5.5.2](#552-retention-period-for-archive) に従い、CAは、フィッシングの疑いやその他の不正使用または懸念により、以前に失効したすべての証明書と以前に拒否された証明書要求の内部データベースを維持する (SHALL)。CAは、この情報を使用して、後続の疑わしい証明書要求を識別する (SHALL)。 **[S/MIME 証明書、ドキュメントサイニング証明書、クライアント認証証明書]** CAの申請は、LRAおよびセコムトラストシステムズが「3.2.2 組織本人の認証」に基づいて認定した組織が行うことができる。 LRAの申請は、LRA運用基準に基づいてLRAが指定した者が行うことができる。 ### 4.1.2 Enrollment process and responsibilities 4.1.2 申請手続および責任 証明書の発行前に、CAは申請者から以下の文書を入手する (SHALL)。 1. 証明書発行申請書、電子版でも可。 2. 契約締結された利用者契約または利用規約、電子版でも可。 CAは、 [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) を満たすために必要であると判断した追加の文書を取得する必要がある (SHOULD)。 証明書を発行する前に、CAは、CAが規定し、[Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) に準拠する形式で、申請者から証明書要求を取得する (SHALL)。各証明書が、申請者に代わって適切な申請者代表者によって署名された有効な最新の証明書要求によってサポートされていることを条件として、[Section 4.2.1](#421-performing-identification-and-authentication-functions) の有効期限と更新の要件に従い、1 つの証明書要求で、同じ申請者に複数の証明書を発行できる (MAY)。証明書要求は、電子的に作成、提出/署名できる (MAY)。 証明書要求には、申請者または申請者の代理人からの証明書発行要求と、そこに含まれるすべての情報が正しいことの申請者または申請者の代理人による証明が含まれていなければならない (MUST)。 **[S/MIME 証明書]** 証明書を発行する前に、CAは申請者から以下の文書を取得する (SHALL)。 1. 証明書発行申請書 2. 契約締結された利用者契約/利用規約 証明書要求および利用者契約または利用規約は、CAが規定する形式であり、[Section 9.6.3](#963-subscriber-representations-and-warranties) を含む[Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) に準拠する (SHALL)。CAは、[Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) を満たすために必要であると判断した追加の文書を取得する必要がある (SHOULD)。 証明書要求には、申請者または申請者の代理人からの証明書発行要求およびそこに含まれるすべての情報が正しいことの申請者または申請者の代理人による証明が含まれている (SHALL)。 各証明書が、申請者に代わって適切な申請代表者によって署名された有効な最新の証明書要求によってサポートされていることを条件として、[Section 4.2.1](#421-performing-identification-and-authentication-functions) に記載されている検証再利用期間に従い、1 つの証明書要求で、同じ申請者に複数の証明書を発行することができる (MAY)。 CAは、次の場合に、以前に検証された証明書要求に基づいて代替証明書を発行できる (MAY)。 1. 参照されている以前の証明書が失効されていない。 2. 交換する証明書の有効期限が、参照されている以前の証明書と同じである。 3. 証明書の主体者識別名情報が、参照されている以前の証明書と同じである。 ## 4.2 Certificate application processing 4.2 証明書申請手続 ### 4.2.1 Performing identification and authentication functions 4.2.1 本人性確認と認証の実施 セコムトラストシステムズは、 [Section 3.2](#32-initial-identity-validation) に従って、LRAまたは組織の本人確認および認証を行う。LRAから受理された証明書の申請においては、LRAが提示した証明書がLRAの本人確認および認証の対象となる。 LRAは、LRAの定める方法により、LRA運用基準に基づいて本人確認および認証を行う。 **[TLSサーバー証明書]** 証明書要求には、証明書に含める申請者に関するすべての事実情報および Baseline Requirements とCAのCP/CPSに準拠するためにCAが申請者から取得する必要がある追加情報を含めることができる (MAY)。証明書要求に申請者に関するすべての必要な情報が含まれていない場合、CAは残りの情報を申請者から取得するか、信頼できる独立した第三者のデータソースから取得して申請者に確認する (SHALL)。CAは、申請者が証明書に含めるように要求したすべてのデータを検証するための文書化された手順を確立し、それに従う (SHALL)。 申請者情報には、証明書の `subjectAltName` 拡張子に含まれる完全修飾ドメイン名 (FQDN) が少なくとも 1 つ含まれていなければならない (MUST) (ただし、これに限定されない)。 [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) は、利用者証明書の有効期間を制限する。CAは、[Section 3.2](#32-initial-identity-validation) で指定されたソースからデータまたは文書を取得するか、証明書の発行前 825 日以内に検証を完了している場合、[Section 3.2](#32-initial-identity-validation) で提供される文書およびデータを使用して証明書情報を検証することも、以前の検証自体を再使用することもできる (MAY)。Section 3.2.2.4 に従ったドメイン名の検証では、使用されるデータ、文書、または完了した検証は、証明書の発行前 398 日以内に取得しなければならない (MUST)。 以前の検証で使用されたデータまたは文書が、証明書の発行前にデータまたは文書の再利用に許可された最大期限を超えて取得された場合、以前の検証を再利用することはできない。 CAは、ハイリスク証明書要求が Baseline Requirements に従って適切に検証されることを保証するために合理的に必要な範囲で、証明書の承認前にハイリスク証明書要求に対する追加の検証アクティビティを識別して要求する文書化された手順を開発、維持、実装する (SHALL) 外部委託先が本項に基づくCAの義務のいずれかを履行する場合、CAは、ハイリスク証明書要求を識別し、さらに検証するために外部委託先が使用するプロセスが、少なくともCA自身のプロセスと同等の保証レベルを提供していることを確認する (SHALL)。 **[EV TLSサーバー証明書]** EV証明書の発行には、次の申請者の役割が必要になる。 1. **証明書要求者**: EV証明書申請は、許可された証明書要求者によって提出されなければならない (MUST)。証明書要求者とは、申請者、申請者に雇用されている人、申請者を代表する明示的な権限を持つ許可された代理人、または申請者に代わってEV証明書要求を完了して提出する第三者 (ISP やホスティング会社など) のいずれかである自然人である。 2. **証明書承認者**: EV証明書の申請は、認可された証明書承認者によって承認されなければならない (MUST)。証明書承認者とは、申請者本人、申請者に雇用されている人、または申請者を代理して証明書を発行する明示的な権限を持つ認可された代理人のいずれかの自然人である。 i. 証明書要求者として行動し、他の従業員または第三者が証明書要求者として行動することを許可する。 ii. 他の証明書要求者によって提出されたEV証明書要求を承認する。 3. **契約署名者**: 要求されたEV証明書に適用される利用者契約は、権限のある契約署名者によって署名されなければならない (MUST)。契約署名者とは、申請者自身、申請者に雇用されている人、または申請者を代表する明示的な権限を持ち、申請者に代わって利用者契約に署名する権限を持つ権限のある代理人のいずれかである自然人である。 4. **申請代表者**: CAと利用者が提携関係にある場合、要求されたEV証明書に適用される利用規約は、権限のある申請者代表者によって承認および同意されなければならない (MUST)。申請代表者とは、申請者自身、申請者に雇用されている人、または申請者を代表する明示的な権限を持ち、申請者に代わって利用規約を承認および同意する権限を持つ権限のある代理人のいずれかである自然人である。 申請者は、1 人の個人がこれらの役割のうち 2 つ以上を担当することを許可できる (MAY)。申請者は、複数の個人がこれらの役割のいずれかを担当することを許可できる (MAY)。 **[S/MIME 証明書]** 申請者情報には、証明書の `subjectAltName` 拡張に含まれる少なくとも 1 つのメールボックスフィールドが含まれるが、これに限定されない (SHALL)。 [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) は利用者証明書の有効期間を制限する。 CAは、 [Section 3.2](#32-initial-identity-validation) に従って実行された完了した検証/裏付けとなる証拠を、以下の制限内で再利用することができる (MAY)。 1. **メールボックスの承認または制御の検証**: [Section 3.2.2.1.1](#32211-validating-authority-over-mailbox-via-domain-smime-certificates) または [Section 3.2.2.1.3](#32213-validating-applicant-as-operator-of-associated-mail-servers-smime-certificates) に従ったメール サーバの制御の検証の完了は、証明書の発行の 398 日前までに取得する (SHALL)。 [Section 3.2.2.1.1](#32211-validating-authority-over-mailbox-via-domain-smime-certificates) で指定されたTLS Baseline Requirements 方法に変更があった場合、CAはこのSectionに記載されている期間、完了した検証/裏付けとなる証拠を再利用し続けることができる (MAY)。 [Section 3.2.2.1.2](#32212-validating-control-over-mailbox-via-email-smime-certificates) に従ったメールボックスの制御の検証は、証明書の発行の 30 日前までに完了する (SHALL)。 以前の検証で使用されたデータまたは文書が、証明書の発行前にデータまたは文書の再利用に許可された最大期限を超えて取得された場合、以前の検証は再利用されない (SHALL NOT)。 **[ドキュメントサイニング証明書とタイムスタンプ証明書]** CAは、[Section 3.2](#32-initial-identity-validation) に従って実行された完了した検証/裏付けとなる証拠を以下の制限内で再利用することができる (MAY)。 検証は証明書の発行日の 398 日以内に取得する (SHALL)。 ### 4.2.2 Approval or rejection of certificate applications 4.2.2 証明書申請の承認または却下 CAは、承認した申請に対応する証明書を発行し、当該利用者にその完了と証明書の発行を通知する。なお、すべての項目の審査が適切に完了していない証明書の申請は拒否することができ、以下の理由を含むものは拒否される。 - 以前に拒否された、または以前に契約条件に違反した申請者または利用者の証明書 **[TLSサーバー証明書]** - 内部名または予約済みIPアドレスを含む証明書を発行しない (SHALL NOT)。このような名前は、[Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) または [Section 3.2.2.5](#3225-authentication-for-an-ip-address) に従って検証できないためである。 #### 4.2.2.1 Certification authority authorization (CAA) (S/MIME Certificates) 4.2.2.1 認証局認可 (CAA) (S/MIME 証明書) **[S/MIME 証明書]** 2024年9月15日以降、CAはCP/CPSの Section 4.2 で、メールボックスアドレスのCAAレコードの処理に関するポリシーまたはプラクティスを明記する (SHALL)。そのポリシーはS/MIME Baseline Requirementsと一致しているものとし (SHAL)、CAがCAA`issuemail`レコードで発行を許可していると認識する発行者ドメイン名のセットを明確に指定する (SHALL)。2024年9月15日以降、メールボックスアドレスを含む証明書を発行する前に、CAは [RFC 9495: Certification Authority Authorization (CAA) Processing for Email Addresses](https://www.rfc-editor.org/rfc/rfc9495.html) の Section 4 に従ってCAAレコードを取得して処理する必要がある (SHOULD)。 2025年3月15日以降、メールボックスアドレスを含む証明書を発行する前に、CAは [RFC 9495: Certification Authority Authorization (CAA) Processing for Email Addresses](https://www.rfc-editor.org/rfc/rfc9495.html) のSection 4「に従ってCAAレコードを取得して処理する (SHALL)。 証明書で使用されるメールボックスアドレスのドメイン部分に対する申請者の制御を検証するために依存している一部の方法 ([Section 3.2.2.1.1](#32211-validating-authority-over-mailbox-via-domain-smime-certificates) および [Section 3.2.2.1.3](#32213-validating-applicant-as-operator-of-associated-mail-servers-smime-certificates) を参照) では、証明書の発行前に追加のリモート ネットワークパースペクティブからCAAレコードを取得して処理する必要がある ([Section 4.2.2.2](#4222-multi-perspective-issuance-corroboration-smime-certificates) を参照)。プライマリネットワークパースペクティブを確認するには、両方のパースペクティブからの応答がバイト単位で同一であるかどうかに関係なく、リモートネットワークパースペクティブのCAAチェック応答を発行の許可として解釈しなければならない (MUST)。さらに、CAは、このSectionで定義されているように、1 つまたは両方のパースペクティブで許容可能なCAAレコード検索エラーが発生した場合、リモートネットワークパースペクティブからの応答を確認と見なすことができる (MAY)。 CAAレコードを処理する場合、CAは RFC 9495 で指定されているように、`issuemail` プロパティタグを処理する (SHALL)。追加のプロパティタグがサポートされる場合がある (MAY) が、`issuemail` プロパティタグで指定されているS/MIME証明書を発行する承認と競合したり、その承認に取って代わったりしてはならない (SHALL NOT)。 CAがCAAチェック後に証明書を発行する場合、CAAレコードのTTL内、または 8 時間以内のいずれか長い方に発行する (SHALL)。この規定は、CAが他の時間にCAAレコードをチェックすることを妨げるものではない。 証明書に複数のメールボックスアドレスが含まれている場合、CAは各メールボックスアドレスに対して上記の手順を実行する (SHALL)。 [Section 7.1.5](#715-name-constraints) に規定されているように、技術的に制約のある下位CA証明書によって発行された証明書の場合、CAAチェックはオプションである。この場合、技術的に制約のある下位CA申請者との契約において、CAAチェックを行わないことが明示的な契約条項となる。 CAは、証明書要求が該当する CAA RRset と一致していると判断しない限り、証明書を発行しない (SHALL NOT)。CAは、CAA 処理方法に従って、実行されたすべてのアクション (ある場合) をログに記録する (SHALL)。 CAは、次の場合にレコード検索の失敗を発行許可として扱うことができる。 - 障害がCAの基盤の外部で発生している。 - 検索が少なくとも1回再試行された。 - ドメインのゾーンには、ICANNルートへのDNSSEC検証チェーンがない。 S/MIME証明書を発行する許可を希望する利用者は、DNSの issuemail プロパティタグに値 **``"secomtrust.net"``** を含めなければならない。S/MIME利用者がDNSゾーンにすでにCAAエントリを持っており、CAからの証明書発行を必要とする場合は、issuemail プロパティ タグに値 **``"secomtrust.net"``** を含めなければならない (MUST)。 #### 4.2.2.2 Multi-perspective issuance corroboration (S/MIME Certificates) 4.2.2.2 マルチパースペクティブ発行検証 (S/MIME 証明書) **[S/MIME 証明書]** CAは、2025年3月15日までに TLS Baseline Requirements の [Section 3.2.2.9](https://github.com/cabforum/servercert/blob/main/docs/BR.md#3229-multi-perspective-issuance-corroboration) を実装するべきである (SHOULD)。 2025年5月15日より、CAは TLS Baseline Requirements の [Section 3.2.2.9](https://github.com/cabforum/servercert/blob/main/docs/BR.md#3229-multi-perspective-issuance-corroboration)を実装する必要がある (SHALL)。 ### 4.2.3 Time to process certificate applications 4.2.3 証明書申請の処理時間 規定しない。 ## 4.3 Certificate issuance 4.3 証明書発行 ### 4.3.1 CA actions during certificate issuance 4.3.1 証明書発行時の処理手続 #### 4.3.1.1 Manual authorization of certificate issuance for Root CAs 4.3.1.1 Root CAの証明書発行の手動承認 Root CAによる証明書発行では、Root CAは、証明書への署名操作を実行するために、CAによって承認された個人(つまり、CAシステムオペレーター、システム責任者、またはPKI管理者)に対し、直接コマンドを実行し、慎重に発行することを求める (SHALL)。 #### 4.3.1.2 Linting of to-be-signed Certificate content 4.3.1.2 署名される証明書のリンティング **[TLSサーバー証明書]** Baseline Requirements に準拠する証明書プロファイルの実装は複雑であるため、CAがリンティングプロセスを実装して、署名する前の各署名対象アーティファクトの技術的適合性をテストすることがベストプラクティスと見なされる。事前証明書がリンティングされている場合、CAが RFC 6962 の Section 3.2 で説明されている方法で署名対象の証明書が署名対象の事前証明書に対応していることを検証するための技術的制御を備えている限り、対応する署名対象の証明書もリンティングを受ける必要はない。 - 2024年9月15日より、CAはこのようなリンティングプロセスを実装する必要がある (SHOULD)。 - 2025年3月15日より、CAはこのようなリンティングプロセスを実装する (SHALL)。 **[S/MIME 証明書]** CAが署名する前に、署名対象の各アーティファクトの技術的適合性をテストするためのリンティングプロセスを実装することがベストプラクティスであると考えられている。 - 2025年3月15日より、CAは S/MIME Baseline Requirements への準拠をテストするリンティングプロセスを実装するべきである (SHOULD)。 - 2025年9月15日より、CAは S/MIME Baseline Requirements への準拠をテストするリンティングプロセスを実装する (SHALL)。 **[TLSサーバー証明書および S/MIME証明書]** 署名対象の証明書コンテンツを含む証明書を作成するために使用される方法には、次のものが含まれるが、これらに限定されない。 1. 公開鍵コンポーネントが公的に信頼されているCA証明書にチェーンされている証明書によって認証されていない「ダミー」私有鍵を使用して `tbsCertificate` に署名する。 2. 証明書 ASN.1 SEQUENCE の`signature`フィールドに固定値を指定する。 CAは独自の証明書リンティングツールを実装できる (MAY)が、業界で広く採用されているリンティングツールを使用する必要がある (SHOULD) ( を参照)。 #### 4.3.1.3 Linting of issued Certificates 4.3.1.3 発行済み証明書のリンティング CAは、発行された各証明書をテストするためにリンティングプロセスを使用する場合がある (MAY)。 ### 4.3.2 Notification to subscriber by the CA of issuance of certificate 4.3.2 CAによる利用者への証明書発行通知 CAは、証明書利用者のみがアクセスできる Web サイトまたはEmailを通じて、証明書利用者に発行を通知する。 **[TLSサーバー証明書]** 一部のTLSサーバー証明書は、ACMEプロトコル経由で提供される場合がある。 ## 4.4 Certificate acceptance 4.4 証明書受領確認 ### 4.4.1 Conduct constituting certificate acceptance 4.4.1 証明書受領確認手続 **[TLSサーバー証明書および S/MIME証明書]** 利用者が証明書をダウンロードしたとき、または利用者が送信した証明書がその他の方法によりサーバーに導入されたときに、その承諾が完了したものとみなされる。 **[クライアント認証証明書、ドキュメントサイニング証明書、タイムスタンプ証明書]** CAがLRAまたは利用者から受領報告を受け取った場合、またはCAによる証明書の配布後14日以内に異議が申し立てられなかった場合は、LRAまたは利用者が証明書を受領したものとみなされる。 ### 4.4.2 Publication of the certificate by the CA 4.4.2 CAによる証明書公開 CA証明書はリポジトリーに公開される。 **[TLSサーバー証明書]** CAは、証明書利用者の証明書をCT (Certificate Transparency) ログに登録し、公開できる。 ### 4.4.3 Notification of certificate issuance by the CA to other entities 4.4.3 CAによる他の関係者への証明書発行通知 CAは、証明書申請提出時に登録された担当者以外の者には証明書発行の通知を送信しない。 ## 4.5 Key pair and certificate usage 4.5 鍵ペアおよび証明書の用途 ### 4.5.1 Subscriber private key and certificate usage 4.5.1 利用者における私有鍵および証明書の用途 [Section 9.6.3](#963-subscriber-representations-and-warranties) の2項および4項を参照。 ### 4.5.2 Relying party public key and certificate usage 4.5.2 検証者における公開鍵および証明書の用途 検証者は、CA証明書を使用する前に、このCP/CPSの規定を承認し、同意する。 検証者は、利用者証明書の審査のためにCA証明書を使用することができる。 ## 4.6 Certificate renewal 4.6 鍵更新をともなわない証明書更新 ### 4.6.1 Circumstance for certificate renewal 4.6.1 鍵更新をともなわない証明書更新の要件 鍵更新をともなわない証明書更新は、利用者の要求に応じて、またはCAの裁量により実施される。 ### 4.6.2 Who may request renewal 4.6.2 鍵更新をともなわない証明書更新申請の処理手続 [Section 4.1.1 - Who can submit a certificate application](#411-who-can-submit-a-certificate-application) の規定が適用される。 ### 4.6.3 Processing certificate renewal requests 4.6.3 鍵更新をともなわない証明書更新申請の処理手続 [Section 4.3.1 - CA actions during certificate issuance](#431-ca-actions-during-certificate-issuance) の規定が適用される。 ### 4.6.4 Notification of new certificate issuance to subscriber 4.6.4 利用者への新更新証明書の発行通知 [Section 4.3.2 - Notification to subscriber by the CA of issuance of certificate](#432-notification-to-subscriber-by-the-ca-of-issuance-of-certificate) の規定が適用される。 ### 4.6.5 Conduct constituting acceptance of a renewal certificate 4.6.5 鍵更新をともなわない更新証明書の受領確認手続 [Section 4.4.1 - Conduct constituting certificate acceptance](#441-conduct-constituting-certificate-acceptance) の規定が適用される。 ### 4.6.6 Publication of the renewal certificate by the CA 4.6.6 CAによる鍵更新をともなわない更新証明書の公開 [Section 4.4.2 - Publication of the certificate by the CA](#442-publication-of-the-certificate-by-the-ca) の規定が適用される。 ### 4.6.7 Notification of certificate issuance by the CA to other entities 4.6.7 CAによる他の関係者への証明書発行通知 [Section 4.4.3 - Notification of certificate issuance by the CA to other entities](#443-notification-of-certificate-issuance-by-the-ca-to-other-entities) の規定が適用される。 ## 4.7 Certificate re-key 4.7 証明書鍵更新 ### 4.7.1 Circumstance for certificate re-key 4.7.1 証明書鍵更新に関する要件 証明書の有効期間が切れそうになったとき、または鍵危殆化により証明書が失効したときに、証明書の鍵が再生成される。 ### 4.7.2 Who may request certification of a new public key 4.7.2 鍵更新をともなう新証明書の申請を行うことができる者 [Section 4.1.1 - Who can submit a certificate application](#411-who-can-submit-a-certificate-application) の規定が適用される。 ### 4.7.3 Processing certificate re-keying requests 4.7.3 鍵更新をともなう証明書申請の処理手続 [Section 4.3.1 - CA actions during certificate issuance](#431-ca-actions-during-certificate-issuance) の規定が適用される。 ### 4.7.4 Notification of new certificate issuance to subscriber 4.7.4 利用者への新証明書発行通知 [Section 4.3.2 - Notification to subscriber by the CA of issuance of certificate](#432-notification-to-subscriber-by-the-ca-of-issuance-of-certificate) の規定が適用される。 ### 4.7.5 Conduct constituting acceptance of a re-keyed certificate 4.7.5 鍵更新をともなう証明書受領確認手続 [Section 4.4.1 - Conduct constituting certificate acceptance](#441-conduct-constituting-certificate-acceptance) の規定が適用される。 ### 4.7.6 Publication of the re-keyed certificate by the CA 4.7.6 CAによる鍵更新された証明書の公開 [Section 4.4.2 - Publication of the certificate by the CA](#442-publication-of-the-certificate-by-the-ca) の規定が適用される。 ### 4.7.7 Notification of certificate issuance by the CA to other entities 4.7.7 CAによる他の関係者への証明書発行通知 [Section 4.4.3 - Notification of certificate issuance by the CA to other entities](#443-notification-of-certificate-issuance-by-the-ca-to-other-entities) の規定が適用される。 ## 4.8 Certificate modification 4.8 証明書記載事項変更による証明書変更 ### 4.8.1 Circumstance for certificate modification 4.8.1 証明書記載事項変更による証明書変更の要件 証明書記載事項変更による証明書変更は、利用者の要求に応じて、またはCAの裁量により実施される場合がある。 ### 4.8.2 Who may request certificate modification 4.8.2 証明書記載事項変更による証明書変更を要求できる者 [Section 4.9.2](#492-who-can-request-revocation) および [Section 4.1.1](#411-who-can-submit-a-certificate-application) の規定が適用される。 ### 4.8.3 Processing certificate modification requests 4.8.3 証明書変更要求の処理 [Section 4.3.1 - CA actions during certificate issuance](#431-ca-actions-during-certificate-issuance) の規定が適用される。 ### 4.8.4 Notification of new certificate issuance to subscriber 4.8.4 利用者への新証明書発行通知 [Section 4.3.2 - Notification to subscriber by the CA of issuance of certificate](#432-notification-to-subscriber-by-the-ca-of-issuance-of-certificate) の規定が適用される。 ### 4.8.5 Conduct constituting acceptance of modified certificate 4.8.5 変更された証明書受領確認手続 [Section 4.4.1 - Conduct constituting certificate acceptance](#441-conduct-constituting-certificate-acceptance) の規定が適用される。 ### 4.8.6 Publication of the modified certificate by the CA 4.8.6 CAによる変更済み証明書の公開 [Section 4.4.2 - Publication of the certificate by the CA](#442-publication-of-the-certificate-by-the-ca) の規定が適用される。 ### 4.8.7 Notification of certificate issuance by the CA to other entities 4.8.7 CAによる他の関係者への証明書発行通知 [Section 4.4.3 - Notification of certificate issuance by the CA to other entities](#443-notification-of-certificate-issuance-by-the-ca-to-other-entities) の規定が適用される。 ## 4.9 Certificate revocation and suspension 4.9 証明書の失効と一時停止 ### 4.9.1 Circumstances for revocation 4.9.1 証明書失効要件 #### 4.9.1.1 Reasons for Revoking a Subscriber Certificate 4.9.1.1 利用者証明書の失効理由 **[TLSサーバー証明書]** CAは、ショートリブド利用者証明書の失効をサポートしてもよい (MAY)。 ショートリブド利用者証明書を除き、以下の1つ以上が発生した場合、CAは24時間以内に証明書を失効し、対応する CRLReason ([Section 7.2.2](#722-crl-and-crl-entry-extensions) を参照) を使用する(SHALL)。 1. 利用者が、CRLreasonを指定せずに、CAに証明書失効することを書面で要求する (CRLReason “unspecified (0)” の場合、CRLに reasonCode 拡張を含めない)。 2. 利用者が、元の証明書要求が承認されなかったことをCAに通知し、遡及的に承認を付与しない (CRLReason #9、privilegeWithdrawn)。 3. CAが、利用者証明書内の公開鍵に対応する私有鍵が危殆化された証拠を得た (CRLReason #1, keyCompromise)。 4. CAが、証明書内の公開鍵に基づいて利用者の私有鍵を容易に計算できる実証済みまたは証明済みの方法を認識しており、これには [Section 6.1.1.3(5)](#6113-subscriber-key-pair-generation)（CRLReason #1、keyCompromise）で特定されているものが含まれるが、これに限定されない。 5. CAが、証明書内におけるドメイン認証の承認またはFQDNやIPアドレスの管理が信用できない証拠を得た (CRLReason #4, superseded)。 ショートリブド利用者証明書を除き、CAは、以下のいずれかが発生した場合、24 時間以内に利用者証明書を失効させる必要があり(SHOULD)、5日以内に証明書を失効し、対応するCRLReason [Section 7.2.2](#722-crl-and-crl-entry-extensions) を使用しなければならない(MUST)。 6. 証明書が [Section 6.1.5](#615-key-sizes) および [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking) の要件に準拠しなくなった (CRLReason #4, superseded)。 7. CAが証明書の不正使用の証拠を得た (CRLReason #9, privilegeWithdrawn)。 8. 利用者が利用者契約または利用規約に基づく重大な義務の1つ以上に違反していることをCAが知り得た (CRLReason #9, privilegeWithdrawn)。 9. CAが、証明書内におけるFQDNまたはIPアドレスの使用が法的にもはや許可されていないことを示す状況を知り得た(例えば、ドメイン名を使用するドメイン名登録者の権利が裁判所または調停機関によって失効となった。ドメイン名登録者と申請者との間の関連するライセンス契約またはサービス契約が解除された。ドメイン名登録者がドメイン名の更新しなかったなど) (CRLReason #5, cessationOfOperation)。 10. 詐欺的な紛らわしい下位FQDNを認証するためにワイルドカード証明書が使用されていたことをCAが知り得た (CRLReason #9, privilegeWithdrawn)。 11. CAが、証明書に含まれている情報の重大な変更を知り得た (CRLReason #9, privilegeWithdrawn)。 12. 証明書が [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) またはCAのCP/CPSに従って発行されなかったことをCAが知り得た (CRLReason #4, superseded)。 13. 証明書に表示されている情報が不正確であると、CAが判断または知り得た (CRLReason #9, privilegeWithdrawn)。 14. Baseline Requirements に基づいて証明書を発行するためのCAの権利が期限切れ、失効または停止となった(CAがCRL/OCSPリポジトリーの維持を継続するための手続きを済ませている場合を除く) (CRLReason "unspecified (0)" の場合、CRLに reasonCode 拡張が提供されない)。 15. Section 4.9.1.1 で指定する必要のない理由により、CA のCP/CPSにより失効が必要とされる場合 (CRLReason "unspecified (0)" の場合、CRL に reasonCode 拡張が提供されない)。 16. CAが、証明書利用者の私有鍵を危殆化させる実証済みの方法、または私有鍵の生成に使用された特定の方法に欠陥があるという明確な証拠があることを認識した (CRLReason #1, keyCompromise)。 **[S/MIME 証明書]** CAは、以下の1つ以上が発生した場合、24時間以内に証明書を失効する (SHALL)。 1. 利用者が、CAに対して証明書の失効を書面で要求する。 2. 利用者が、元の証明書要求が承認されなかったことをCAに通知し、遡及的に承認を付与しない。 3. CAが、証明書内の公開鍵に対応する利用者の私有鍵が鍵危殆化を受けたことを示す証拠を取得する。 4. CAが、証明書内の公開鍵に基づいて利用者の私有鍵を簡単に計算できる実証済みまたは証明済みの方法を認識している (Debian の弱い鍵など) を参照)。 5. CAが、証明書内のメールボックスアドレスのドメイン認証またはメールボックス制御の検証を信頼できないという証拠を取得する。 CAは、以下の1つ以上が発生した場合、24時間以内に証明書を失効する必要があり (SHOULD)、5日以内に証明書を失効する (SHALL)。 1. 証明書が [Section 6.1.5](#615-key-sizes) および [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking) の要件に準拠しなくなる。 2. CAが、証明書が不正使用されたという証拠を取得する。 3. CAが、利用者が利用者契約または利用規約に基づく重要な義務の 1 つ以上に違反したことを認識する。 4. CAが、証明書内のEmailアドレスまたはFQDNの使用が法的に許可されなくなったことを示す状況を認識している (例: 裁判所または調停機関がEmailアドレスまたはドメイン名の使用権を失効した、利用者間の関連するライセンス契約またはサービス契約が終了した、またはアカウント所有者がEmailアドレスまたはドメイン名のアクティブステータスを維持できなかった)。 5. CAが、証明書に含まれる情報に重大な変更があったことを認識する。 6. CAが、証明書が [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) またはCAのCP/CPSに従って発行されなかったことを認識する。 7. CAが、証明書に記載されている情報のいずれかが不正確であると判断または認識する。 8. CAが、CRL/OCSPリポジトリーの維持を継続する手続きを行っていない限り、S/MIME Baseline Requirementsに基づいて証明書を発行するCAの権利が期限切れになるか、失効されるか、または終了する。 9. CAのCP/CPSによって失効が要求される。 10. CAが、利用者の私有鍵が危殆化する可能性のある実証済みまたは証明済みの方法を認識している場合、または私有鍵を生成するために使用された特定の方法に欠陥があったという明確な証拠がある場合に通知される。 **[Code Signing Certificates]** [コードサイニング証明書 ] CAは、以下の1つ以上が発生した場合、24時間以内に証明書を失効する (SHALL)。 1. 利用者が、CAに証明書の失効を書面で要求する。 2. 利用者が、元の証明書要求が承認されなかったことをCAに通知し、遡及的に承認を付与しない。 3. CAが、証明書内の公開鍵に対応する利用者の私有鍵が鍵危殆化を受けたことを示す証拠を取得する。 4. CAが、証明書内の公開鍵に基づいて利用者の私有鍵を簡単に計算できる実証済みまたは証明済みの方法を認識している。 5. CAが、利用者の私有鍵が危殆化される実証済みまたは証明済みの方法を認識している場合、または私有鍵を生成するために使用された特定の方法に欠陥があったという明確な証拠がある。 6. CAが、証明書が疑わしいコードに署名するために使用されたことを合理的に保証する。 CAは、以下の1つ以上が発生した場合、24時間以内に証明書を失効する必要があり (SHOULD)、5日以内に証明書を失効する (SHALL)。 7. 証明書が [Section 6.1.5](#615-key-sizes) および [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking) の要件に準拠しなくなる。 8. CAが証明書が不正使用されたという証拠を入手する。 9. CAが、利用者が利用者契約または利用規約に基づく重要な義務の 1 つ以上に違反したことを認識する。 10. CAが、証明書に含まれる情報に重大な変更があったことを認識する。 11. CAが、証明書が [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) またはCAのCPやCPSに従って発行されなかったことを認識する。 12. CAが、証明書に記載されている情報のいずれかが不正確であると判断するか、またはそのことを認識する。 13. CAが、CRL/OCSPリポジトリーの維持を継続する手配を行わない限り、[Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) に基づいて証明書を発行するCAの権利は期限切れになるか、失効されるか、または終了する。 14. CAのCP/CPSによって失効が必要になる。 即時失効がエコシステムに潜在的に大きな悪影響を及ぼす場合、CAはアプリケーションソフトウェアサプライヤーからの要求に基づいて失効を遅らせることがある (MAY)。 **[Client Authentication Certificates, Document Signing Certificates and Timestamp Certificates]** [クライアント認証証明書、ドキュメントサイニング証明書、タイムスタンプ証明書 ] CAは、以下の1つ以上が発生した場合に証明書を失効する (SHALL)。 1. 利用者が、CAに対して証明書の失効を書面で要求する。 2. 利用者が、元の証明書要求が承認されなかったことをCAに通知し、遡及的に承認を付与しない。 3. CAが、証明書内の公開鍵に対応する利用者の私有鍵が鍵危殆化を受けたことを示す証拠を取得する。 4. CAが、証明書内の公開鍵に基づいて利用者の私有鍵を簡単に計算できる実証済みまたは証明済みの方法を認識している。 5. CAが、利用者の私有鍵が危殆化する実証済みまたは証明済みの方法を認識している、もしくは私有鍵を生成するために使用された特定の方法に欠陥があったという明確な証拠がある。 6. 証明書が [Section 6.1.5](#615-key-sizes) および [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking) の要件に準拠しなくなる。 7. CAが、証明書が不正使用されたという証拠を入手する。 8. CAが、利用者が利用者契約または利用規約に基づく重要な義務の 1 つ以上に違反したことを認識する。 9. CAが、証明書に含まれる情報に重大な変更があったことを認識する。 10. CAが、証明書が [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) またはCAのCPやCPSに従って発行されなかったことを認識する。 11. CAが、証明書に記載されている情報のいずれかが不正確であると判断するか、またはそのことを認識する。 12. CAが CRL/OCSPリポジトリーの維持を継続する手続きを行わない限り、[Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) に基づいて証明書を発行するCAの権利は期限切れになるか、失効されるか、または終了する。 13. CAのCP/CPSによって失効が必要になる。 #### 4.9.1.2 Reasons for Revoking a Subordinate CA Certificate 4.9.1.2 下位CA証明書の失効理由 以下の1つ以上が発生した場合、発行CAは7日間以内に下位CA証明書を失効させる(SHALL)。 1. 下位CAが書面で失効を要求する。 2. 下位CAが発行CAに対し、元の証明書要求が承認されていなかったことおよび遡及的に承認を許可しないことを通知する。 3. 発行CAが、下位CAの証明書内の公開鍵に対応する私有鍵が危殆化された、または [Section 6.1.5](#615-key-sizes)および [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking)の要件に準拠しなくなった証拠を得る。 4. 発行CAが、証明書の不正使用の証拠を得る。 5. 証明書が [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) または適用されるCP/CPSに従って発行されなかったこと、または下位CAが [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) または適用されるCP/CPSに準拠していないことを、発行CAが認識する。 6. 証明書に表示されている情報が不正確または誤解を招く恐れがあると発行CAが判断する。 7. 発行CAまたは下位CAが何らかの理由で運用を中止したが、証明書の失効サポートが別のCAによって提供されるように手配しない。 8. [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) に基づいて証明書を発行するための発行CAまたは下位CAの権利が期限切れ、失効または終了となる。(発行CAがCRL/OCSPリポジトリーの維持を継続するための手配を済ませている場合を除く) 9. 発行CAのCP/CPSによって失効が必要になる。 ### 4.9.2 Who can request revocation 4.9.2 証明書の失効申請を行うことができる者 利用者、RAまたは発行CAが失効手続きを開始できる。加えて、利用者、検証者、アプリケーションソフトウェアサプライヤーおよびその他の第三者は、証明書失効に関する妥当な根拠となる証明書問題レポートを発行CAに提出できる。 ### 4.9.3 Procedure for revocation request 4.9.3 失効申請手続 CAは、利用者に対し、自身の証明書の失効を要求するためのプロセスを提供する (SHALL)。 利用者は、所定の手続きに従い、CAに対して利用者証明書の失効申請を行う。LRAが申請し発行した証明書については、LRA運用基準に基づきLRAが定める方法により利用者証明書の失効申請を行う。LRAは、LRA証明書を使用してセコムトラストシステムズが提供するサイトにアクセスし、CAに対して利用者証明書の失効申請を行う。 CAは、失効要求および証明書問題レポートを24時間365日継続的に受け入れ、対応する機能を維持する (SHALL)。 CAは、利用者、検証者、アプリケーションソフトウェアサプライヤーおよびその他の第三者に、私有鍵危殆化、証明書の不正使用、またはその他の種類の詐欺、侵害、不正使用、不適切な行為、もしくは証明書に関連するその他の問題の疑いを報告するための明確な手順を提供する (SHALL)。CAは、容易にアクセスできるオンライン手段を通じておよびCPSの [Section 1.5.2](#152-contact-person) で手順を公開する (SHALL)。 ### 4.9.4 Revocation request grace period 4.9.4 失効申請の猶予期間 実際の失効スケジュールは、この [section 4.9.1.1](#4911-reasons-for-revoking-a-subscriber-certificate) および [section 4.9.1.2](#4912-reasons-for-revoking-a-subordinate-ca-certificate) に記載されている失効の理由によって異なる。 ### 4.9.5 Time within which CA must process the revocation request 4.9.5 CAが失効処理する時間 証明書問題レポートの受領後24時間以内に、CAは証明書問題レポートに関連する事実と状況を調査し、その調査結果に関する予備レポートを利用者と証明書問題レポートを提出したエンティティの両方に提供する (SHALL)。事実と状況を確認した後、CAは利用者および証明書問題レポートまたはその他の失効関連通知を報告したエンティティと協力して、証明書を失効するかどうか、また失効する場合はCAが証明書を失効する日付を確定する (SHALL)。証明書問題レポートまたは失効関連通知の受領から失効の公表までの期間は、[Section 4.9.1.1](#4911-reasons-for-revoking-a-subscriber-certificate) で規定されている期間を超えてはならない (MUST NOT)。CAが選択する日付は、次の基準を考慮する必要がある (SHOULD)。 1. 申し立てられた問題の性質(範囲、状況、厳しさ、規模、被害リスク) 2. 失効の結果（利用者および検証者への直接的および付随的な影響） 3. 特定の証明書または利用者に関して受領した証明書問題レポートの数 4. 苦情を申し立てるエンティティ（たとえば、Web サイトが違法行為を行っているとする法執行官からの苦情は、注文した商品を受け取っていないと主張する消費者からの苦情よりも重視されるべきである (SHOULD)。 5. 関連法規 ### 4.9.6 Revocation checking requirement for relying parties 4.9.6 検証者に対する失効確認要件 検証者は、CRL配布ポイントまたはOCSPポインターを含むすべての証明書の失効ステータスを確認する必要がある。 ### 4.9.7 CRL issuance frequency 4.9.7 CRLの発行頻度 CRLは、パブリックでアクセス可能な HTTP URL (公開) 経由で利用できなければならない。 **[TLSサーバー証明書]** 最初の証明書の発行から24時間以内に、CAは、次のいずれかを生成および公開しなければならない (MUST)。 - full CRL - 分割CRLは、集約するとfull CRLと同等になる。 利用者証明書を発行するCAは以下を実施する。 1. 新しいCRLを、少なくとも次の間隔で更新および公開しなければならない (MUST)。 - すべての証明書に id-ad-ocsp accessMethod (「AIA OCSP ポインター」) を使用した機関情報アクセス拡張機能が含まれている場合は7日 - その他すべての場合は4日 2. 証明書が失効したと記録してから24時間以内に、新しいCRLを更新して公開しなければならない (MUST)。 **[Client Authentication Certificates, S/MIME Certificates, Code Signing Certificates, Document Signing Certificates and Timestamp Certificates]** [クライアント認証証明書、S/MIME証明書、コードサイニング証明書、ドキュメントサイニング証明書、タイムスタンプ証明書 ] CAは少なくとも 7日ごとにCRLを更新および再発行するものとし (SHALL)、`nextUpdate` フィールドの値は `thisUpdate` フィールドの値より10日を超えない (SHALL NOT)。 **[Common to all certificates]** [すべての証明書に共通] CA証明書を発行するCAは以下を実施する。 1. 少なくとも12か月ごとに新しいCRLを更新して公開しなければならない (MUST)。 2. 証明書が失効したと記録してから24時間以内に、新しいCRLを更新して公開しなければならない (MUST)。 CAは、次のいずれかが満たされるまでCRLを発行し続けなければならない (MUST)。 - 同じ主体者識別名公開鍵を含むすべての下位CA証明書が期限切れまたは失効している。 - 対応する下位CA私有鍵が破棄される。 ### 4.9.8 Maximum latency for CRLs (if applicable) 4.9.8 CRL発行の最大遅延 (該当する場合) Root CAの場合、新しいCRLが発行され、発行後24時間以内にリポジトリーに公開される。 CAによって発行されたCRLは、妥当な時間内にリポジトリーに反映される。 ### 4.9.9 On-line revocation/status checking availability 4.9.9 オンライン失効/ステータス確認の可用性 OCSP応答の有効期間は、`thisUpdate`フィールドと`nextUpdate`フィールドの時間差（両端を含む）である。その差を算出する目的で、うるう秒を無視すると、3,600秒の差は1時間に等しいものとし(SHALL)、86,400秒の差は1日に等しいものとなる(SHALL)。 証明書のシリアルナンバーが「割り当てられている」のは、次の場合である - そのシリアルナンバーを持つ証明書または事前証明書が発行CAによって発行されている。 - そのシリアルナンバーを持つ事前証明書が、発行CAに関連付けられた [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile) で定義される事前証明書サイニング証明書によって発行されている 証明書のシリアルは、「割り当てられていない」場合、「未割り当て」となる。 id-ad ocsp accessMethod を使用した Authority Information Access 拡張を含む証明書および事前証明書のステータスを通信する場合は、以下が適用される (SHALL) CAが運用するOCSPレスポンダは、RFC 6960 / RFC 5019 で説明されているように、HTTP GETメソッドをサポートする (SHALL)。CAは、RFC 8954 に従って Nonce 拡張 (`1.3.6.1.5.5.7.48.1.2`) を処理する場合がある(MAY)。 利用者証明書または対応する事前証明書の場合、以下が適用される。 - 2025年1月15日より、証明書または事前証明書が最初に公開された、またはその他の方法で利用可能になってから 15分以内に、信頼できるOCSP応答が利用可能にならなければならない (MUST) (つまり、応答者は「不明」ステータスで応答してはならない (MUST NOT))。 - 有効期間が16時間未満のOCSP応答の場合、CAは nextUpdate の前の有効期間半分に先立ち更新されたOCSP応答を提供する（SHALL）。 - 有効期間が16時間以上のOCSP応答の場合、CAは nextUpdate の少なくとも8時間前および thisUpdate の4日後までに、更新されたOCSP応答を提供する（SHALL）。 下位CAのステータスの場合、CAは少なくとも12か月ごとおよび証明書の失効後24時間以内に更新されたOCSP 応答を提供する (SHALL)。 OCSPレスポンダーが応答する意思がある、または応答する必要があるすべての証明書のステータスを通信するには、以下が適用される (SHALL)。 OCSP応答は、RFC 6960 / RFC 5019 に準拠していなければならない (MUST)。OCSP応答は、次のいずれかでなければならない (MUST)。 1. 失効ステータスがチェックされている証明書を発行したCAによって署名されている 2. [Section 7.1.2.8](#7128-ocsp-responder-certificate-profile) のOCSPレスポンダ証明書プロファイルに準拠しているOCSPレスポンダによって署名されている 利用者証明書のOCSP応答の有効期間は 8時間以上10日以下でなければならない (MUST)。 OCSPレスポンダーが「未割り当て」の証明書シリアルナンバーのステータスのリクエストを受信した場合、レスポンダーは「good」ステータスで応答すべきではない (SHOULD NOT)。OCSPレスポンダーが [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) または [Section 7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile) に沿って技術的に制約されていないCA向けである場合、レスポンダーはそのような要求に対して「good」ステータスで応答してはならない(MUST NOT)。 ### 4.9.10 On-line revocation checking requirements 4.9.10 オンライン失効確認の要件 規定しない。 ### 4.9.11 Other forms of revocation advertisements available 4.9.11 その他の形式での証明書有効性確認方法 CAは、利用者が RFC4366 (トランスポート層セキュリティ (TLS) 拡張)、RFC 5246 (トランスポート層セキュリティ (TLS) プロトコル バージョン 1.2)、RFC 8446 (トランスポート層セキュリティ (TLS) プロトコル バージョン 1.3) に従って OCSP ステープリングを使用することを許可する。 ### 4.9.12 Special requirements re key compromise 4.9.12 鍵危殆化の特別要件 [Section 4.9.1](#491-circumstances-for-revocation) を参照。 ### 4.9.13 Circumstances for suspension 4.9.13 証明書一時停止の要件 リポジトリーには、証明書が 一時停止されていることを示すエントリーを含めてはならない (MUST NOT)。 一時停止の使用に関する制限については、[Section 7.2.2](#722-crl-and-crl-entry-extensions) を参照。 ### 4.9.14 Who can request suspension 4.9.14 証明書一時停止を要求できる者 適用外とする。 ### 4.9.15 Procedure for suspension request 4.9.15 証明書一時停止要求の手順 適用外とする。 ### 4.9.16 Limits on suspension period 4.9.16 一時停止可能期間 適用外とする。 ## 4.10 Certificate status services 4.10 証明書有効性確認サービス ### 4.10.1 Operational characteristics 4.10.1 運用特性 CRLまたはOCSPレスポンスの失効エントリーは、失効した証明書の有効期限日が過ぎるまで削除してはならない (MUST NOT)。 **[コードサイニング証明書]** 失効情報は有効期限後少なくとも10年間確認可能とする。 ### 4.10.2 Service availability 4.10.2 サービスの可用性 CAは、通常の運用状況の下で10秒以内のレスポンス時間を提供するために十分なリソースで、CRLおよびオプションのOCSP機能を運用および維持する (SHALL)。 CAは、アプリケーションソフトウェアが、CAによって発行されたすべての有効期限内証明書の現在のステータスを自動的にチェックするために使用できるオンラインリポジトリーを24時間365日体制で維持する (SHALL)。 CAは、重大な証明書問題報告（Certificate Problem Report）に対して、24時間365日体制で継続的に内部対応できる能力を維持しなければならない（SHALL）。また、適切な場合には、当該苦情を法執行機関に通報し、さらにその通報の対象となっている証明書を失効させなければならない。 ### 4.10.3 Optional features 4.10.3 オプション機能 規定しない。 ## 4.11 End of subscription 4.11 利用者の利用終了 利用者は、本サービスの利用を終了する場合には、契約等に定めるサービス利用終了手続きを行う必要がある。 利用者は、証明書の利用を終了する場合には、証明書失効申請を行う。 証明書更新申請を行わない場合または証明書有効期間満了の場合、利用は終了する。 ## 4.12 Key escrow and recovery 4.12 キーエスクロー（鍵預託）と鍵回復 ### 4.12.1 Key escrow and recovery policy and practices 4.12.1 キーエスクロー（鍵預託）と鍵回復に関するポリシーと実施手順 CAは利用者の私有鍵をエスクローしない。 ### 4.12.2 Session key encapsulation and recovery policy and practices 4.12.2 セッション鍵のカプセル化および鍵回復に関するポリシーと実施手順 適用外とする。 # 5. MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS 5 管理、運用、物理的制御 CAは、以下の目的で設計された包括的なセキュリティプログラムを開発、実装、維持する (SHALL)。 1. 証明書データおよび証明書管理プロセスの機密性、完全性および可用性を保護する。 2. 証明書データおよび証明書管理プロセスの機密性、完全性および可用性にとっての潜在的な脅威または危険から保護する。 3. 証明書データおよび証明書管理プロセスに対する不正または違法なアクセス、使用、開示、改変、または破壊から保護する。 4. 証明書データおよび証明書管理プロセスの不慮の損失、破壊、または損傷から保護する。 5. 法律によってCAに適用されるその他のセキュリティ要件すべてに準拠する。 証明書管理プロセスは、以下を含まなければならない (MUST)。 1. 物理的なセキュリティや環境の制御 2. 構成管理、信頼済みコードの整合性メンテナンス、マルウェア検出/防止を含む、システム整合性の制御 3. ポート制限やIPアドレスフィルタリングを含む、ネットワークセキュリティおよびファイアウォール管理 4. ユーザー管理、信頼済みロールの分担、教育、意識向上、トレーニング 5. 個々の責任を明確にするための論理的なアクセス制御、アクティビティロギングおよびアイドル時のタイムアウト CAのセキュリティプログラムには、以下のような年次リスクアセスメントを含まなければならない (MUST)。 1. 証明書データまたは証明書管理プロセスに対する不正なアクセス、開示、不正使用、改変、または破壊につながる、予測可能な内外の脅威を特定する。 2. これらの脅威がもたらす可能性があるダメージについて、証明書データや証明書管理プロセスの秘密度を考慮に入れて評価する。 3. このような脅威に対抗するためにCAが配備したポリシー、手順、情報システム、技術、その他の手配の充実度に関して評価する。 リスクアセスメントに基づき、CAは、上述の目的を実現するべく設計されたセキュリティ手順、対策および製品で構成されるセキュリティ計画を開発、実装および維持し、リスクアセスメント中に識別されたリスクを、証明書データおよび証明書管理プロセスの重要度に応じて管理する (SHALL)。セキュリティ計画には、証明書データおよび証明書管理プロセスの秘密度に適した管理上、組織的、技術的および物理的な保護対策を含めなければならない (MUST)。また、セキュリティ計画では、その時点で利用可能な技術および特定の対策の実装コストを考慮に入れなければならず (MUST)、セキュリティの危殆化から生じる可能性がある損害および保護対象のデータの性質に適した合理的な水準のセキュリティを実装する (SHALL)。 ## 5.1 Physical Security Controls 5.1 物理的セキュリティ管理 ### 5.1.1 Site location and construction 5.1.1 立地場所と建築構造 CAは、認証基盤システムを安全なデータセンター内に設置している。データセンターは、水害、地震、火災などの災害の影響を受けにくい場所に建設されており、また、こうした災害を防止し保護するための構造的対策も実施されている。 ### 5.1.2 Physical access 5.1.2 物理的アクセス CA は、認証基盤システムの重要度に応じて、物理的アクセス制御と電子的アクセス制御を組み合わせた適切なセキュリティ制御を実施する。また、認証基盤システムへのアクセスは、設置された監視カメラやその他のセンサーによって監視される。 ### 5.1.3 Power and air conditioning 5.1.3 電力と空調 データセンターには、瞬時停電や長時間停電時でも認証基盤システムが継続して稼動できるよう、無停電電源装置や非常用発電機を設置し、電源確保に努めて​​いる。また、空調設備により常に最適な温度・湿度に保たれる空調環境に設置している。 ### 5.1.4 Water exposures 5.1.4 水害対策 CAは、洪水対策のために建物の2階以上に認証基盤システムを設置し、その他の水の影響から保護するために、システムが設置されている部屋に漏水センサーを配置する。 ### 5.1.5 Fire prevention and protection 5.1.5 防火対策 認証基盤システムが設置されている部屋は、ファイアウォールで仕切られた耐火区画であり、火災警報器や消火設備が備え付けられている。 ### 5.1.6 Media storage 5.1.6 媒体保管 CAは、認証サービスの実行に不可欠なアーカイブ、バックアップ、その他のデータと情報を適切なアクセス制御が行われた室内の金庫に保管し、潜在的な損害や損失を防ぐための対策を講じている。 ### 5.1.7 Waste disposal 5.1.7 廃棄処理 CAは、機密情報を含む機密紙文書および電子メディアを廃棄する前に初期化または細断する。 ### 5.1.8 Off-site backup 5.1.8 オフサイトバックアップ CAは、認証基盤システムの運用に必要なデータ、機器およびその他の項目のリモートストレージと取得/調達のための対策を講じる。 ## 5.2 Procedural controls 5.2 手順の管理 ### 5.2.1 Trusted roles 5.2.1 信頼された役割 CAは、認証基盤システムの運用に必要な役割を次のように定義する。 1. サービス責任者 - 電子認証基盤を管理する。 - 認証基盤システムおよび運用手順の変更/改訂を承認する。 2. サービス運用管理者 - 運用担当者に作業指示を与える。 - 現場でCA私有鍵の操作を監視する。 - サービス業務全体を管理する。 3. CA管理者 - CAサーバー、リポジトリーサーバーおよびその他の認証基盤システムを維持および管理する。 - CA私有鍵の有効化と無効化を実行する。 4. RA担当者 - 認証基盤システムを使用してRAサービスを実行する顧客の情報の登録と削除を管理する。 - 認証基盤システムを通じて、CAが運営するRAサービスを実施する。 ### 5.2.2 Number of Individuals Required per Task 5.2.2 職務ごとに必要とされる人数 CA私有鍵は、物理的に保護された環境で少なくとも二重制御を使用して、信頼された役割の担当者によってのみバックアップ、保存および回復される (SHALL)。 セコムトラストシステムズは、サービス運用管理者を除き、[Section 5.2.1](#521-trusted-roles) に記載されている役割を遂行する担当者を少なくとも2名配置し、サービス提供の中断を回避する。CA私有鍵に関連する操作などの重要な操作は、少なくとも2名が共同で行う。 ### 5.2.3 Identification and authentication for each role 5.2.3 各役割の本人性確認と認証 セコムトラストシステムズは、認証基盤システムへのアクセスに関して、物理的または論理的な手段により、アクセスを許可された個人の識別および認証ならびにアクセスが正当な行為であることの妥当性を確認する。 ### 5.2.4 Roles requiring separation of duties 5.2.4 各役割の権限分割 原則として、[Section 5.2.1](#521-trusted-roles) に記載されている役割は、独立した担当者によって実行される。サービス運用管理者は、ログ検査担当者を兼務することができる。 **[EV TLSサーバー証明書]** 1. CAは、検証義務の分割に関する厳格な管理手順を実施して、1 人の人物が単独でEV証明書の発行を検証および承認できないようにしなければならない (MUST)。[Section 3.2.2.2.12](#322212-final-cross-correlation-and-due-diligence-ev-tls-server-certificates) で概説されているように、最終的な相互照合および適切な精査の手順は、いずれかの人物によって実行される場合がある (MAY)。たとえば、1 人の検証スペシャリストがすべての申請者情報を確認して検証し、2 人目の検証スペシャリストがEV証明書の発行を承認する場合がある (MAY)。 2. このような管理は監査可能でなければならない (MUST)。 ## 5.3 Personnel controls 5.3 人事管理 ### 5.3.1 Qualifications, experience, and clearance requirements 5.3.1 資格、経歴およびクリアランス要件 証明書管理プロセスに人物を関与させる前に、それがCAの従業員、代理人または独立請負業者であるかどうかにかかわらず、CAはその人物の身元と信頼性を検証する (SHALL)。 ### 5.3.2 Background check procedures 5.3.2 身元調査の手順 セコムトラストシステムズは、[Section 5.2.1](#521-trusted-roles) に記載された役割を担当する個人の信頼性と適性を任命時およびその後、定期的に審査する。 **[EV TLSサーバー証明書]** CAがEVプロセスに従事するために従業員、代理人、または独立請負業者として人を雇用し始める前に、CAは次のことを行わなければならない (MUST)。 1. **該当者の身元確認**: 本人確認は、以下の方法でま実施しなければならない (MUST)。 A. 人事またはセキュリティ機能を実行する信頼できる人物の前に、当該人物を個人的（物理的）に同席させる B. 政府発行の写真付き身分証明書（旅券/運転免許証など）の一般的な形式による検証 2. **該当者の信頼性確認**: 信頼性の検証には、少なくとも以下の項目またはそれと同等の項目を対象とした身元調査が含まれる (SHALL)。 A. 職歴の確認 B. 経歴推薦状の確認 C. 取得した最高学位または最も関連性の高い教育資格の確認 3. EV Guidelinesの採用時にすでにCAに雇用されており、その身元および経歴が上記のとおり以前に確認されていない従業員の場合、CAはEV Guidelinesの採用日から3か月以内にそのような確認を行う (SHALL)。 ### 5.3.3 Training Requirements and Procedures 5.3.3 教育要件と手順 CAは、情報検証業務を実行するすべての要員に、基本的な公開鍵基盤の知識、認証および検証ポリシーおよび手順（CAのCP/CPSを含む）、情報検証プロセスに対する一般的な脅威（フィッシングおよびその他のソーシャル・エンジニアリング手法を含む）および Baseline Requirements を網羅したスキル研修を提供する（SHALL）。 CAは、このようなトレーニングの記録を保持し、検証スペシャリストの職務を委託された要員が、そのような職務を満足に遂行できるスキルレベルを維持していることを保証する (SHALL)。 CAは、検証スペシャリストにタスクの実行を許可する前に、各検証スペシャリストがそのタスクに必要なスキルを有していることを文書化する (SHALL)。 CAは、すべての検証スペシャリストに対して、Baseline Requirements に概説されている情報検証要件に関してCAが提供する試験に合格することを要求する (SHALL)。 ### 5.3.4 Retraining frequency and requirements 5.3.4 再教育の頻度および要件 信頼される役割に携わるすべての要員は、CAのトレーニングおよびパフォーマンスプログラムと一致するスキルレベルを維持する (SHALL)。 CAは、必要に応じて [Section 5.2.1](#521-trusted-roles) に記載されている役割を担当する個人に更新トレーニングを提供する。 ### 5.3.5 Job rotation frequency and sequence 5.3.5 ジョブローテーションの頻度と方法 CAは、サービス品質の一貫性と向上の確保および不正行為の防止を目的として、人員のローテーションを実施する。 ### 5.3.6 Sanctions for unauthorized actions 5.3.6 不正行為に対する制裁 セコムトラストシステムズ就業規則に定める罰則の規定が適用される。 ### 5.3.7 Independent Contractor Controls 5.3.7 委託契約の要件 CAは、証明書の発行に関与する外部委託先の担当者が、[Section 5.3.3](#533-training-requirements-and-procedures) のトレーニングおよびスキルの要件および [Section 5.4.1](#541-types-of-events-recorded) の文書保持およびイベントログの要件を満たしていることを確認する (SHALL)。 CAが認証基盤システムの運用の全部または一部を独立請負業者に委託する場合、CAは契約を通じて、請負業者が運用義務を適切に遂行することを保証する。 ### 5.3.8 Documentation supplied to personnel 5.3.8 担当者に提供される文書 CAは、関連業務の遂行に必要な文書のみに担当者のアクセスを許可する。 ## 5.4 Audit logging procedures 5.4 監査ログ手順 ### 5.4.1 Types of events recorded 5.4.1 記録されるイベントの種類 CAおよび外部委託先は、証明書システム、証明書管理システム、Root CAシステムおよび外部委託先システムのセキュリティに関連するイベントを記録する (SHALL)。CAおよび各外部委託先は、証明書を発行する目的で証明書要求を処理するために実行されたアクションに関連するイベントを記録する (SHALL)。その中には証明書の要求に関連して生成されたすべての情報と受け取った文書、日時と関係者が含まれる。CAは、[Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) に準拠していることを証明するものとして、公認監査人にこれらの記録を提示できるようにする (SHALL)。 CAは、少なくとも以下のイベントを記録する (SHALL)。 1. 以下を含むCA証明書と鍵ライフサイクルイベント 1. 鍵の生成、バックアップ、保管、回復、アーカイブ化、破棄 2. 証明書の要求、更新、鍵の再生成の要求および失効 3. 証明書要求の承認と拒否 4. 暗号化デバイスライフサイクル管理イベント 5. 証明書失効リストの生成 6. OCSP応答の署名（[Section 4.9](#49-certificate-revocation-and-suspension) および [Section 4.10](#410-certificate-status-services)で説明） 7. 新しい証明書プロファイルの導入と既存の証明書プロファイルの廃止 2. 以下を含む利用者証明書ライフサイクル管理イベント 1. 証明書の要求、更新、鍵の再生成要求および失効 2. Baseline Requirements およびCAのCPSで定められたすべての検証業務 3. 証明書要求の承認と拒否 4. 証明書の発行 5. 証明書失効リストの生成 6. OCSP応答の署名（[Section 4.9](#49-certificate-revocation-and-suspension) および [Section 4.10](#410-certificate-status-services)で説明） 7. 各ネットワークパースペクティブからのマルチ パースペクティブ発行確認の試行。最低限、以下の情報を記録する。 - a. 使用されたネットワーク パースペクティブを一意に識別する識別子 - b. 試行されたドメイン名/ IP アドレス - c. 試行の結果 (例:「ドメイン検証の合格/不合格」、「CAA の許可/禁止」) 8. 証明書要求で表された試行されたドメイン名またはIPアドレスごとに、マルチパースペクティブ発行検証定足数の結果 (つまり、「3/4」は、「試行された 4 つのネットワークパースペクティブのうち 3 つが、プライマリネットワーク パースペクティブによって行われた決定を確認した」と解釈される)。 3. 以下を含むセキュリティイベント 1. 成功および失敗したPKIシステムアクセス試行 2. 実行されたPKIおよびセキュリティシステムアクション 3. セキュリティプロファイルの変更 4. 証明書システムへのソフトウェアのインストール、更新および削除 5. システムクラッシュ、ハードウェア障害およびその他の異常 6. 関連するルーターおよびファイアウォールのアクティビティ ([Section 5.4.1.1](#5411-router-and-firewall-activities-logs) で説明) 7. CA施設への出入記録 ログ記録には、少なくとも以下の要素を含めなければならない (MUST)。 1. イベントの日時 2. ジャーナルレコードを作成する人の身元 (該当する場合) 3. イベントの詳細 #### 5.4.1.1 Router and firewall activities logs 5.4.1.1 ルーターとファイアウォールのアクティビティログ [Section 5.4.1](#541-types-of-events-recorded) Subsection 3.6 の要件を満たすために必要なルーターとファイアウォールのアクティビティのログには、少なくとも次のものが含まれなければならない (MUST)。 1. ルーターとファイアウォールへのログイン試行の成功と失敗 2. 構成の変更、ファームウェアの更新、アクセス制御の変更など、ルーターおよびファイアウォール上で実行されたすべての管理アクションのログ 3. 追加、変更、削除を含む、ファイアウォールルールに対して行われたすべての変更のログ 4. ハードウェアの障害、ソフトウェアのクラッシュ、システムの再起動など、すべてのシステムイベントとエラーのログ #### 5.4.1.2 Types of events recorded for Timestamp Authorities 5.4.1.2 タイムスタンプ局に記録されるイベントの種類 **[コードサイニング証明書]** タイムスタンプ認証局は、Baseline Requirements for Code Signing Certificates へのタイムスタンプ局の準拠の証拠として、以下の情報を記録し、これらの記録を公認監査人が利用できるようにしなければならない (MUST)。 1. タイムスタンプサーバーへの物理的またはリモートアクセス（アクセス時刻、サーバーにアクセスした個人のIDを含む） 2. タイムスタンプサーバー設定の履歴 3. タイムスタンプログを削除または変更しようとする試み 4. 以下を含むセキュリティイベント - a. タイムスタンプ局へのアクセス試行の成功と失敗 - b. タイムスタンプ局のサーバーアクションの実行 - c. セキュリティプロファイルの変更 - d. システムクラッシュやその他の異常 - e. ファイアウォールとルーターのアクティビティ 5. タイムスタンプ証明書の失効 6. タイムスタンプサーバーの時間の大きな変更 7. システムの起動とシャットダウン ### 5.4.2 Frequency of processing audit log 5.4.2 監査ログの処理頻度 CAは定期的に監査ログを確認する。現在の監査ログとアーカイブされた監査ログの確認には、監査ログの整合性の検証および不正なアクティビティや疑わしいアクティビティのタイムリーな特定とフォローアップが含まれる。 ### 5.4.3 Retention period for audit log 5.4.3 監査ログの保管期間 CAおよび各外部委託先は、少なくとも2年間、以下を保管する (SHALL)。 1. CA 証明書および鍵のライフサイクル管理イベント記録（[Section 5.4.1](#541-types-of-events-recorded) (1)に記載）は、以下のいずれかが発生した後に保管する。 1. CA私有鍵の破壊 2. `cA`フィールドが true に設定された X.509v3`basicConstraints`拡張を持ち、CA私有鍵に対応する共通の公開鍵を共有する一連の証明書のうち、最後のCA証明書の失効または有効期限切れ 2. 利用者証明書の有効期限が切れた後の利用者証明書ライフサイクル管理イベント記録（[Section 5.4.1](#541-types-of-events-recorded) (2)に規定） 3. イベント発生後のセキュリティイベント記録（[Section 5.4.1](#541-types-of-events-recorded) (3)に規定） 4. **Code Signing Certificates** の場合、TSA証明書私有鍵の失効または更新後のタイムスタンプ局データ記録[Section 5.4.1.2](#5412-types-of-events-recorded-for-timestamp-authorities)およびイベント発生後のセキュリティイベント記録（[Section 5.4.1.2](#5412-types-of-events-recorded-for-timestamp-authorities)に規定） ### 5.4.4 Protection of audit log 5.4.4 監査ログの保護 CAは、監査ログへのアクセスに対して適切な制御を実施し、許可された担当者によるアクセスのみを保護し、許可されていない担当者の目にログが触れないようにする。 ### 5.4.5 Audit log backup procedures 5.4.5 監査ログのバックアップ手順 監査ログは、監査ログを生成する機器とは別の安全なオフサイト環境にバックアップされ、保存される。 ### 5.4.6 Audit collection System (internal vs. external) 5.4.6 監査収集システム（内部および外部） 監査ログ収集システムは、認証基盤システムの機能として組み込まれている。 ### 5.4.7 Notification to event-causing subject 5.4.7 イベントの要因となるサブジェクトへの通知 CAは、対応するイベントの要因となった人物、システムまたはアプリケーションに通知せずに監査ログを収集する。 ### 5.4.8 Vulnerability assessments 5.4.8 脆弱性アセスメント さらにCAのセキュリティプログラムには、以下のような年次リスクアセスメントを含めなければならない (MUST)。 1. 証明書データまたは証明書管理プロセスに対する不正なアクセス、開示、不正使用、改変または破壊につながる、予測可能な内外の脅威を特定する。 2. 証明書データおよび証明書管理プロセスの機密性を考慮して、これらの脅威の可能性および潜在的な損害を評価する。 3. このような脅威に対抗するために CA が導入しているポリシー、手順、情報システム、技術およびその他の取り決めが十分であるかどうかを評価する。 ## 5.5 Records archival 5.5 記録のアーカイブ ### 5.5.1 Types of records archived 5.5.1 アーカイブされる記録の種類 CAおよび各外部委託先は、すべての監査ログをアーカイブする (SHALL)（[Section 5.4.1](#541-types-of-events-recorded)に規定）。 さらに、CAおよび各外部委託先は以下をアーカイブするのとする (SHALL)。 1. 証明書システムのセキュリティに関連するドキュメント、証明書管理システム、Root CAシステムおよび外部委託先システム 2. 証明書要求および証明書の検証、発行および失効に関連するドキュメント ### 5.5.2 Retention period for archive 5.5.2 アーカイブ保存期間 アーカイブされた監査ログ（[Section 5.5.1](#551-types-of-records-archived) に規定されているように)は、レコード作成のタイムスタンプから少なくとも2年間、または [Section 5.4.3](#543-retention-period-for-audit-log) に従って保持する必要がある限り、いずれか長い方の期間保持される (SHALL)。 さらに、CAおよび各外部委託先は、少なくとも2年間、以下を保持する (SHALL)。 1. 証明書システム、証明書管理システム、Root CAシステムおよび外部委託先システムのセキュリティに関連するすべてのアーカイブされたドキュメント ([Section 5.5.1](#551-types-of-records-archived) に規定) 2. 証明書要求および証明書の検証、発行、失効（[Section 5.5.1](#551-types-of-records-archived) に規定）に関連する、以下のいずれかの事象が発生した後のアーカイブされたすべての文書 1. このような記録と文書は、証明書要求と証明書の検証、発行、または失効の際に最後に参照されたものである。 2. 当該記録および文書に基づく利用者証明書の有効期限。 ### 5.5.3 Protection of archive 5.5.3 アーカイブ保護 アーカイブは、許可された担当者のみアクセスが制限されている施設に保管される。 ### 5.5.4 Archive backup procedures 5.5.4 アーカイブバックアップ手順 証明書の発行/失効やCRLの発行など、認証基盤システムの機能に関わる重要なデータに変更があった場合は、必ずアーカイブがバックアップされる。 ### 5.5.5 Requirements for time-stamping of records 5.5.5 記録のタイムスタンプ要件 セコムトラストシステムズは、NTP (Network Time Protocol) を使用して認証基盤システムの時刻同期を行い、そこに記録された重要なデータにタイムスタンプを押す。 ### 5.5.6 Archive collection system (internal or external) 5.5.6 アーカイブ収集システム (内部または外部) アーカイブ収集システムは、認証基盤システムの機能として組み込まれている。 ### 5.5.7 Procedures to obtain and verify archive information 5.5.7 アーカイブ情報の取得および検証手順 アーカイブは、適切なアクセス権限を持つ指定担当者によって安全な保管場所から取り出され、メディアの保管状態を定期的にチェックする。さらに、アーカイブは、その完全性と機密性を維持するために、必要に応じて新しいメディアにコピーされる。 ## 5.6 Key changeover 5.6 鍵の切り替え CAの鍵ペア更新、証明書更新は、原則として、残りの有効期間が利用者に発行された証明書の最大有効期間よりも短くなる前に行う。新しい鍵ペアが生成された後、証明書とCRLは新しい鍵ペアを使用して発行される。 ## 5.7 Compromise and disaster recovery 5.7 危殆化および災害復旧 ### 5.7.1 Incident and compromise handling procedures 5.7.1 インシデントおよび危殆化対応手順 CAは、インシデント対応計画と災害復旧計画を策定する。 CAは、災害、セキュリティの危殆化または業務障害が発生した場合にアプリケーションソフトウェアサプライヤー、利用者および検証者に通知し、それらを合理的に保護するように設計された、事業継続および災害復旧手順を文書化する (SHALL)。CAは事業継続計画を公開する必要はないが、CAの監査人が要求した時には事業継続計画とセキュリティ計画を提供できるようにする (SHALL)。CAは、年1回これらの手順をテスト、レビューおよび更新する (SHALL)。 事業継続計画には以下を含めなければならない(MUST)。 1. 計画を始動するための条件 2. 緊急対応手順 3. フォールバック手順 4. 再開手順 5. 計画の保守スケジュール 6. 意識向上および教育要件 7. 個人の責任範囲 8. 目標復旧時間 (RTO) 9. 緊急対策計画の定期的なテスト 10. 重要な事業プロセスの中断または障害発生後、タイムリーにCAの事業運営を維持または復元するための計画 11. 重要な暗号化資材(つまり、セキュリティ保護された暗号化装置やアクティベーション資材)を代替場所に保管するための要件 12. 容認可能なシステム停止および回復時間 13. 必須の事業情報およびソフトウェアのバックアップコピーの作成頻度 14. 復旧施設からCAのメインサイトまでの距離 15. 災害発生から元のサイトまたはリモートサイトで安全な環境を復元するまでの期間に可能な範囲で設備を保護するための手順 2025年9月1日より、CAは、Mozilla Root Store Policyの規定に従い、大量失効イベントに対処するための包括的かつ実行可能な計画を策定し、維持する。 ### 5.7.2 Recovery Procedures if Computing resources, software, and/or data are corrupted 5.7.2 コンピューティングリソース、ソフトウェア、データが破損した場合の復旧手順 認証基盤システムのハードウェア、ソフトウェア、データが破損した場合、セコムトラストシステムズは、バックアップとして保管されている関連するハードウェア、ソフトウェア、データを使用して、認証基盤システムの復旧作業をすみやかに行う。 ### 5.7.3 Recovery Procedures after Key Compromise 5.7.3 鍵危殆化発生後の復旧手順 利用者は、私有鍵が危殆化したか、その可能性があると判断した場合、関連するCAに失効要求をすみやかに行わなければならない。失効要求を受け取った後、関連するCA は、電子認証基盤で運用されている[Section 4.9](#49-certificate-revocation-and-suspension)に規定されている手順に従って失効を処理する。 CAに係るシステムの運用が中断または停止した場合、CAは、あらかじめ定められた計画および手順に従って、アプリケーションソフトウェアサプライヤーを含む関係者に通知し、安全に運用を再開する。 ### 5.7.4 Business continuity capabilities after a disaster 5.7.4 災害後の事業継続 セコムトラストシステムズでは、不測の事態が発生した場合でもすみやかに復旧できるよう、交換用・バックアップ用ハードウェアの確保、復旧のための継続的なデータバックアップ、復旧手順の確立など、認証基盤システムの最短復旧に向けた予防措置を講じる。 ## 5.8 CA or RA termination 5.8 CAまたはRAの終了 CAが終了する場合、CAは終了の3か月前に、外部委託先を通じて利用者に通知することがある。その他の影響を受ける参加者（アプリケーションソフトウェアサプライヤーを含む）にも通知する。 # 6. TECHNICAL SECURITY CONTROLS 6 技術的セキュリティ管理 ## 6.1 Key pair generation and installation 6.1 鍵ペアの生成とインストール 本CP/CPS は、電子認証基盤上で運用されるCAによる鍵管理および利用者などの他の参加者による鍵管理を規定する。 ### 6.1.1 Key pair generation 6.1.1 鍵ペアの生成 #### 6.1.1.1 CA Key Pair Generation 6.1.1.1 CA鍵ペアの生成 次のいずれかのCA鍵ペアの場合: i. Root 証明書のCA鍵ペアとして使用されている ii. 下位CA証明書のCA鍵ペアとして使用されるもので、下位CAがルート CA の運営者でもルート CA の関連会社でもない場合 CAは次のことを行う (SHALL)。 1. 鍵生成スクリプトを準備してそれに従う。 2. 公認監査人に、CA鍵ペアの生成プロセスに立ち会わせる、またはCA鍵ペアの生成プロセス全体を録画する。 3. 公認監査人に、CAが鍵と証明書の生成プロセス中に鍵セレモニーに従い、鍵ペアの整合性と機密性を確保するために使用された制御に従ったという意見を述べるレポートを発行させる。 Root CA の運営者またはRoot CAの関連会社向けのその他のCA鍵ペアの場合、CAは次のことを行う必要がある (SHOULD)。 1. 鍵生成スクリプトを準備してそれに従う。 2. 公認監査人にCA鍵ペアの生成プロセスに立ち会わせる、またはCA鍵ペアの生成プロセス全体を録画する。 いかなる場合でも、CAは次のことを行う (SHALL)。 1. CAのCP/CPSに記載されているように、物理的に保護された環境でCA鍵ペアを生成する。 2. 複数人による管理と知識の分割の原則に基づいて、信頼された役割の担当者を使用してCA鍵ペアを生成する。 3. CAのCP/CPSに開示されている適用可能な技術要件およびビジネス要件を満たす暗号モジュール内でCA鍵ペアを生成する。 4. CA鍵ペア生成アクティビティをログに記録する。 5. 私有鍵がCP/CPSおよび (該当する場合) 鍵生成スクリプトに記載されている手順に従って生成され、保護されていることを合理的に保証するための効果的な管理を維持する。 #### 6.1.1.2 RA Key Pair Generation 6.1.1.2 RA鍵ペアの生成 規定しない。 #### 6.1.1.3 Subscriber Key Pair Generation 6.1.1.3 利用者鍵ペアの生成 CAは、以下の条件の 1 つ以上が満たされた場合、証明書要求を拒否する (SHALL)。 1. 鍵ペアが[Section 6.1.5](#615-key-sizes) / [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking) に定められた要件を満たしていない。 2. 私有鍵を生成するために使用された特定の方法に欠陥があったという明確な証拠がある。 3. CAが、申請者の私有鍵が危殆化する実証済みまたは証明済みの方法を認識している。 4. CAが、 [Section 4.9.3](#493-procedure-for-revocation-request) および [Section 4.9.12](#4912-special-requirements-re-key-compromise) に記載されているCAの失効要求手順を使用して、申請者の私有鍵が鍵危殆化を受けたことを以前に通知されている。 5. 公開鍵は、業界で実証された弱い私有鍵に適合している。2024年11月15日以降に提出されたリクエストについては、少なくとも以下の予防措置を実施する (SHALL)。 1. Debian の弱い鍵の脆弱性 () の場合、CAはリポジトリーにリストされている各鍵のタイプ (RSA、ECDSAなど) とサイズについて、 で見つかったすべての鍵を拒否する (SHALL)。[Section 6.1.5](#615-key-sizes) の要件を満たすその他のすべての鍵については、8192 ビットを超えるRSA鍵サイズを除き、CAは Debian の弱鍵を拒否する (SHALL)。 2. ROCAの脆弱性の場合、CAは または同等のツールによって識別された鍵を拒否する (SHALL)。 3. Close Primes 脆弱性 () の場合、CAは、フェルマー因数分解法を使用して100ラウンド以内に因数分解できる弱鍵を拒否する (SHALL)。 弱い鍵をチェックするための推奨ツール: 利用者証明書に、`id-kp-serverAuth` [RFC5280] または `anyExtendedKeyUsage` [RFC5280] のいずれかの値を含む `extKeyUsage` 拡張機能が含まれる場合、CAは利用者に代わって鍵ペアを生成しないものとし (SHALL NOT)、CAによって以前に生成された鍵ペアを使用した証明書要求を受け入れない (SHALL NOT)。 **[AATL ドキュメントサイニング証明書とコードサイニング証明書]** 利用者の鍵ペアは、安全な暗号ハードウェアデバイスによって直接生成され、そのデバイス内に保管されるものとする。 ### 6.1.2 Private key delivery to subscriber 6.1.2 利用者への私有鍵配布 利用者以外の当事者は、利用者の許可なく利用者の私有鍵をアーカイブしてはならない (SHALL NOT)。 CAまたは指定されたRAのいずれかが、利用者の私有鍵が権限のない人物または利用者と関係のない組織に漏洩したことを認識した場合、CAは私有鍵に対応する公開鍵を含むすべての証明書を失効する (SHALL)。 **[S/MIME 証明書]** 利用者以外の当事者は、利用者の許可なく利用者の私有鍵をアーカイブしてはならない (SHALL NOT)。 CAまたはその指定されたRAのいずれかが、利用者の私有鍵が利用者によって承認されていない個人または組織に伝達されたことを認識した場合、CAは伝達された私有鍵に対応する公開鍵を含むすべての証明書を失効する (SHALL)。 CAまたは外部委託先が利用者に代わって私有鍵を生成し、その私有鍵が利用者に転送される場合、私有鍵を生成するエンティティは次のいずれかを実行する (SHALL)。 1. 私有鍵は、128ビットの暗号化に相当するアクティベーション方法を使用してハードウェアで転送される。この場合、私有鍵をアクティベート/保護するために使用される素材（PKCS 12ファイルのセキュリティ保護に使用されるパスワードなど）は、私有鍵を保持するコンテナとは別に、安全に利用者に送られなければならない。 2. 少なくとも112ビットの暗号化強度で私有鍵を暗号化する。 具体例としては次のようなものが含まれる。 - 128ビットのAES鍵を使用して私有鍵をラップする。 - 少なくとも112ビットの暗号化強度を提供するパスワードとアルゴリズムを使用して暗号化されたPKCS 12ファイルに鍵を保存する。 - 少なくとも112ビットの暗号化強度を持つTLSまたはその他の認証および暗号化されたネットワーク接続を介して、私有鍵/PKCS 12ファイル/アクティベーションマテリアルを転送する。 - 要件を満たすその他のアプローチも許可されている。 **[コードサイニング証明書]** CAまたは外部委託先が利用者に代わって私有鍵を生成し、その私有鍵が署名サービスの安全な基盤の外部で利用者に転送される場合、私有鍵を生成するエンティティは、128ビットの暗号化に相当するアクティベーション方法を使用して、私有鍵をハードウェアで転送しなければならない (MUST)。 利用者以外の当事者は、利用者の許可なく利用者の私有鍵をアーカイブしてはならない (SHALL NOT)。 CAまたはその指定されたRAが、利用者の私有鍵が権限のない人物または利用者と関係のない組織に伝達されたことを認識した場合、CAは伝達された私有鍵に対応する公開鍵を含むすべての証明書を失効する (SHALL)。署名サービスが利用者に代わって私有鍵を生成している場合、その私有鍵は利用者に転送されない (SHALL NOT)。 ### 6.1.3 Public key delivery to certificate issuer 6.1.3 証明書発行者への公開鍵配布 利用者公開鍵はCAにオンラインで配信され、その通信経路はTLS通信によって暗号化される。TLSサーバー証明書の公開鍵の一部は、ACMEプロトコルを介してCAに電子的に配送される。 ### 6.1.4 CA public key delivery to relying parties 6.1.4 検証者へのCA公開鍵配布 検証者は、CAリポジトリーにアクセスしてCA公開鍵を取得できる。 ### 6.1.5 Key sizes 6.1.5 鍵サイズ **TLSサーバー証明書、S/MIME証明書、AATLドキュメントサイニング証明書およびAATLタイムスタンプ証明書を発行する場合は、次の確認を行う必要がある。** RSA鍵ペアの場合、CAは次のことを行う (SHALL)。 - エンコード時のモジュラスサイズが少なくとも 2048 ビットであることを確認する。 - モジュラスサイズ (ビット単位) が 8 で割り切れることを確認する。 ECDSA鍵ペアの場合、CAは次のことを行う (SHALL)。 - 鍵がNIST P-256、NIST P-384、またはNIST P-521楕円曲線上の有効なポイントを表していることを確認する。 他のアルゴリズムや鍵サイズは許可されていない。 **Baseline Requirements for Code Signing Certificates に準拠したコードサイニング証明書とタイムスタンプ証明書を発行する場合は、次の確認を行う必要がある。** RSA鍵ペアの場合、CAは次のことを行う (SHALL)。 - エンコード時のモジュラスサイズが少なくとも 3072 ビットであることを確認する。 - モジュラスサイズ (ビット単位) が 8 で割り切れることを確認する。 ECDSA鍵ペアの場合、CAは次のことを行う (SHALL)。 - 鍵がNIST P-256またはNIST P-384楕円曲線上の有効なポイントを表していることを確認する。 他のアルゴリズムや鍵サイズは許可されていない。 ### 6.1.6 Public key parameters generation and quality checking 6.1.6 公開鍵パラメーターの生成と品質確認 RSA: CAは、公開指数の値が 3 以上の奇数であることを確認する (SHALL)。さらに、公開指数は 2^16 + 1 から 2^256 - 1 の範囲にある必要がある (SHOULD)。係数には、奇数であること、素数の累乗ではないこと、752 より小さい因数がないことなどの特性も必要である (SHOULD)。[出典: Section 5.3.3、NIST SP 800-89] ECDSA: CAは、ECC完全公開鍵検証ルーティンまたはECC部分公開鍵検証ルーティンのいずれかを使用して、すべての鍵の有効性を確認する必要がある (SHOULD)。[出典: NIST SP 800-56A: 改訂 2 の Section 5.6.2.3.2 および 5.6.2.3.3] ### 6.1.7 Key usage purposes (as per X.509 v3 key usage field) 6.1.7 鍵の使用目的（X.509 v3 Key usageフィールドに準拠） Root 証明書に対応する私有鍵は、以下の場合を除き、証明書の署名に使用してはならない (MUST NOT)。 1. Root CA自体を表す自己署名証明書 2. 下位CA証明書およびクロス認証下位CA証明書 3. 基盤管理目的の証明書(管理者証明書、内部CA運用デバイス証明書) 4. OCSPからのレスポンスを検証する証明書 ## 6.2 Private Key Protection and Cryptographic Module Engineering Controls 6.2 私有鍵の保護および暗号モジュールの運用管理 CAは、不正な証明書の発行を防ぐために、物理的および論理的な保護手段を実装する (SHALL)。[Section 6.2.7](#627-private-key-storage-on-cryptographic-module) で指定されている検証済みシステムまたはデバイスの外部でのCA私有鍵の保護は、私有鍵の漏洩を防ぐ方法で実装された物理的なセキュリティ、暗号化、またはその両方の組み合わせで構成されていなければならない (MUST)。CAは、暗号化された鍵または鍵部分の残存寿命の間、暗号解読攻撃に耐えることができる最新のアルゴリズムと鍵長を使用して、私有鍵を暗号化する (SHALL)。 ### 6.2.1 Cryptographic module standards and controls 6.2.1 暗号モジュールの規格と管理 CA私有鍵の生成、保存、署名操作は、[Section 6.2.7](#627-private-key-storage-on-cryptographic-module) を使用して実行される。 利用者の私有鍵については規定がない。 **[AATL ドキュメントサイニング証明書]** AATLドキュメントサイニング証明書には、次のいずれかの認定が必要になる。 1. FIPS 140-2 レベル 2 以上 2. 共通基準 (ISO 15408 および ISO 18045) - 保護プロファイル CEN prEN 14169 (デバイスタイプに適用されるすべての部分) またはリモート管理デバイス用の CEN EN 419 241 シリーズなどの標準または同等の標準 3. 2016年7月1日以降にEU加盟国により適格署名作成デバイス (QSCD) として認定されたデバイス、または2016年7月1日以前にEU加盟国の指定機関によりセキュア署名作成デバイス (SSCD) として認定されたデバイス。 ### 6.2.2 Private key (n out of m) multi-person control 6.2.2 私有鍵の複数人管理 CA私有鍵に関する有効化、無効化、バックアップ、その他の操作は、安全な環境で少なくとも 2 人の承認された個人によって共同で実行される。利用者私有鍵に関する有効化、無効化、バックアップ、その他の操作は、関連する利用者の管理下で安全に実行されなければならない。 ### 6.2.3 Private key escrow 6.2.3 私有鍵のエスクロー CAはCA私有鍵をエスクローしない。 CAは利用者私有鍵をエスクローしない。 ### 6.2.4 Private key backup 6.2.4 私有鍵のバックアップ [Section 5.2.2](#522-number-of-individuals-required-per-task) を参照。 ### 6.2.5 Private key archival 6.2.5 私有鍵のアーカイブ 下位CA以外の当事者は、下位CAの許可なしに下位CAの私有鍵をアーカイブしてはならない (SHALL NOT)。 ### 6.2.6 Private key transfer into or from a cryptographic module 6.2.6 私有鍵の暗号モジュールへの移行または暗号モジュールからの移行 発行CAが下位CAに代わって私有鍵を生成した場合、発行CAは下位CAに転送するために私有鍵を暗号化する (SHALL)。発行CAは、下位CAの私有鍵が権限のない人物または下位CAに所属していない組織に漏洩されたことを認識した場合、漏洩された私有鍵に対応する公開鍵を含むすべての証明書を失効する (SHALL)。 ### 6.2.7 Private key storage on cryptographic module 6.2.7 暗号モジュールでの私有鍵保管 CAは、少なくともFIPS 140-2 レベル 3、FIPS 140-3 レベル 3、または適切な 共通基準保護プロファイル (Common Criteria Protection Profile) またはセキュリティターゲット、EAL 4 (またはそれ以上) を満たしていると検証されたシステムまたはデバイスで私有鍵を保護する (SHALL)。これには、私有鍵およびその他の資産を既知の脅威から保護するための要件が​​含まれる。 **[コードサイニング用のタイムスタンプ証明書]** コードサイニング用のタイムスタンプ証明書は、2025年4月15日以降は発行しない。 コードサイニング用のタイムスタンプ下位CA証明書は、2026年6月6日までに失効する。 **[コードサイニング証明書]** コードサイニング証明書は、2024年5月1日以降は発行しない。 コードサイニング下位CA証明書は 2026年6月6日までに失効する。 2023年6月1日より、コードサイニング証明書の利用者私有鍵は、以下の要件に従って保護される (SHALL)。CAは、利用者が以下のいずれかのオプションを使用して、少なくとも FIPS 140-2 レベル 2 または Common Criteria EAL 4+ に準拠していると認定されたユニット設計フォームファクターを持つハードウェア暗号モジュールでコードサイニング証明書の私有鍵を生成および保護するという契約上の表明を利用者から取得しなければならない (MUST)。 1. 利用者は、指定された要件を満たすハードウェア暗号モジュールを使用する。 2. 利用者は、次の要件を満たすクラウドベースの鍵生成および保護ソリューションを使用する。 a 鍵の生成、保存および私有の使用は、指定された要件に準拠するクラウドソリューションのハードウェア暗号モジュールのセキュリティ境界内にとどまらなければならない。 b 私有鍵を管理するレベルのサブスクリプションは、私有鍵を保護するリソースに対するすべてのアクセス、操作および構成の変更をログに記録するように構成しなければならない。 1. 利用者は、Section 6.2.7.3 のBaseline Requirements for Code Signing Certificatesを満たす署名サービスを使用する。 2023年6月1日より、コードサイニング証明書については、Baseline Requirements for Code Signing Certificates を満たすために、次のいずれかの方法を採用しなければならない (MUST)。 1. CAは、適切なハードウェア暗号モジュールと、CAがハードウェア暗号モジュールを使用して生成した 1 つ以上の事前生成済み鍵ペアを出荷する。 2. 利用者は、製造元の証明書（一般に鍵証明と呼ばれる）を使用して検証できる証明書要求に副署名し、適切なハードウェア暗号モジュールを使用して、私有鍵がエクスポート不可能な方法で生成されたことを示す。 3. 利用者は、鍵ペアの生成と保存に、CAが規定した暗号ライブラリと適切なハードウェア暗号モジュールの組み合わせを使用する。 4. 利用者は、コードサイニング証明書に関連付けられる鍵ペアを生成するために適切なハードウェア暗号モジュールのみを使用していることを示す内部または外部の IT監査を提供する。 5. 利用者は、適切なハードウェア暗号モジュールで私有鍵を保護するクラウドベースのキー保護ソリューションのサブスクリプションとリソース構成から適切なレポートを提供する。 6. CAは、CAによって承認され、ITおよびセキュリティのトレーニングを受けた、またはクラウドベースの鍵生成および保護ソリューションを含む適切なハードウェア暗号モジュールソリューションで鍵ペアの作成に立ち会ったCISAである監査人によって署名された申請者から提供されたレポートに依存する。 7. 利用者は、Section 6.2.7.3 のBaseline Requirements for Code Signing Certificatesを満たす署名サービスを使用する契約書を提出する。 **[AATL ドキュメントサイニング証明書]** 認証局が利用者が使用するHSM内に私有鍵を生成したことが確認された場合、認証局は証明書申請手続きにおいて、証明書発行要求の署名を検証し、証明書発行要求に含まれる公開鍵に対応する私有鍵で署名されていることを確認する。 あるいは、CAは暗号ハードウェアデバイス上で私有鍵を生成し、その私有鍵を利用者に安全に配布して、該当する証明書に対応する私有鍵を利用者が所有していることを証明する。 ### 6.2.8 Activating Private Keys 6.2.8 私有鍵の活性化 CA私有鍵は、安全な部屋で少なくとも 2 人の承認された個人によって共同で有効化される。利用者の私有鍵について規定しない。 ### 6.2.9 Deactivating Private Keys 6.2.9 私有鍵の非活性化 CA私有鍵は、安全な部屋で少なくとも 2 人の承認された個人によって共同で無効化される。利用者の私有鍵について規定しない。 ### 6.2.10 Destroying Private Keys 6.2.10 私有鍵の破棄 CAの私有鍵は、完全な初期化または物理的破壊によって、少なくとも 2 人の権限のある個人によって共同で破壊される。私有鍵のバックアップも同様の方法で破壊される。利用者の私有鍵について規定はない。 ### 6.2.11 Cryptographic Module Rating 6.2.11 暗号モジュールの評価 CAが使用する暗号モジュールに適用される品質基準は、[Section 6.2.1](#621-cryptographic-module-standards-and-controls) に規定されているとおりである。利用者の私有鍵について規定はない。 ## 6.3 Other aspects of key pair management 6.3 鍵ペア管理に関するその他の事項 ### 6.3.1 Public key archival 6.3.1 公開鍵のアーカイブ CA公開鍵に関する条項は [Section 6.2.1](#621-cryptographic-module-standards-and-controls) に規定されている。利用者私有鍵について規定しない。 電子認証基盤上で運用されるCA公開鍵のアーカイブについては、[Section 5.5.1](#551-types-of-records-archived) に規定される。 ### 6.3.2 Certificate operational periods and key pair usage periods 6.3.2 証明書有効期間と鍵ペア使用期間 下位CAの鍵ペアの有効期間は指定されないが、下位CA証明書の有効期間は20年以下とする。 **[TLSサーバー証明書]** 2020年 9月 1日以降に発行されたTLSサーバー利用者証明書の有効期間は397日を超えるべきではなく (SHOULD NOT)、398日を超えてはならない (MUST NOT)。 **[EV TLSサーバー証明書]** EV Guidelinesに準拠するEV TLSサーバー証明書の有効期間は398日を超えない (SHALL NOT)。 **[コードサイニング証明書とコードサイニング証明書のタイムスタンプ証明書]** Baseline Requirements for Code Signing Certificates に準拠するコードサイニング証明書の有効期間は39か月を超えてはならない。コードサイニング証明書に使用されるタイムスタンプ局は、タイムスタンプ証明書の私有鍵が危殆化された場合に利用者への影響を最小限に抑えるために、15か月ごとに新しい私有鍵を持つ新しいタイムスタンプ証明書を使用しなければならない。タイムスタンプ証明書の有効期間は135か月を超えてはならない。 Baseline Requirements for Code Signing Certificates に準拠するタイムスタンプ証明書鍵ペアは、[Section 6.1.5](#615-key-sizes) の要件を満たさなければならない (MUST)。タイムスタンプ認証局は、タイムスタンプ証明書の notBefore 日付から15か月以上経過したタイムスタンプ証明書に関連付けられた私有鍵を使用しない (SHALL NOT)。2025年4月15日より、15か月を超えて発行されたタイムスタンプ証明書に関連付けられた私有鍵は、タイムスタンプ証明書の発行後18か月以内に、私有鍵を保護するハードウェア暗号モジュールから削除しなければならない (MUST)。2024年 6月 1日以降に発行されたタイムスタンプ証明書の場合、CAは、CA によって実行され、少なくとも 2 人の信頼できる役割メンバーによって証明および承認された鍵削除セレモニーによって、ハードウェア暗号モジュールからの私有鍵の削除を記録する (SHALL)。CAは、Baseline Requirements for Code Signing Certificates を満たすために、バックアップの一部としての鍵のインスタンスを含め、その私有鍵のすべてのコピーが明確/安全に破棄される (つまり、鍵を回復する方法がない)、鍵破棄セレモニーを実行することもできる (MAY)。CAは、タイムスタンプ証明書に対応する私有鍵を含む既存のバックアップセットを維持できる (MAY)。CAは、タイムスタンプ証明書がバックアップの復元より15か月以上前に発行された場合、バックアップ内に含まれるタイムスタンプ証明書に対応する私有鍵を復元するべきではない (SHOULD NOT)。CAがそのような私有鍵を復元する場合、CAは、高セキュリティゾーンでオフライン状態または他のすべてのネットワークから隔離された状態で維持されている適切なHSMでのみ私有鍵を復元し、HSMをオンライン状態にする前に新しい鍵破棄セレモニーを実行する (SHALL)。 **[AATL タイムスタンプ証明書]** タイムスタンプ証明書の有効期間は135か月を超えてはならない。 **[S/MIME 証明書]** 2022年4月1日以降に発行されたS/MIME 証明書の有効期間は825日を超えてはならない。 **[ドキュメントサイニング証明書とクライアント認証証明書 ]** 利用者証明書の有効期間は1827日を超えてはならない。 計算上、1 日は 86,400 秒として測定される。小数秒やうるう秒を含め、これを超える時間はすべて、追加の 1 日を表す。このため、このような調整を考慮するために、利用者証明書はデフォルトで最大許容時間で発行されるべきではない (SHOULD NOT)。 ## 6.4 Activation data 6.4 アクティベーションデータ ### 6.4.1 Activation data generation and installation 6.4.1 アクティベーションデータの生成と設定 電子認証基盤上で運用されるCAの私有鍵を使用するために必要なアクティベーションデータは、少なくとも2人の承認された個人によって共同で生成され、デジタルメディアに保存される。 ### 6.4.2 Activation data protection 6.4.2 アクティベーションデータの保護 電子認証基盤上で運用されるCAの私有鍵の有効化に必要なデータを保存するデジタルメディアは、安全な室内で管理下にて保管される。 ### 6.4.3 Other aspects of activation data 6.4.3 アクティベーションデータに関するその他の事項 電子認証基盤上で運用される認証局の私有鍵のアクティベーションデータの生成および設定の管理は、[Section 5.2.1](#521-trusted-roles) に記載された者によって行われる。 ## 6.5 Computer security controls 6.5 コンピューターのセキュリティ管理 ### 6.5.1 Specific computer security technical requirements 6.5.1 特定のコンピューターのセキュリティ技術要件 CAは、証明書の発行を直接実行できるすべてのアカウントに対して多要素認証を実施する (SHALL)。 ### 6.5.2 Computer security rating 6.5.2 コンピューターのセキュリティ評価 認証基盤システムで採用されるすべてのソフトウェアおよびハードウェアについて、認証局が実稼働前のシステムテストを実施し、システムの信頼性確保に努めて​​いる。また、認証基盤システムのセキュリティ上の脆弱性に関する情報をセコムトラストシステムズが常時収集し、脆弱性が発見された場合に迅速に対応できるよう評価を行っている。 ## 6.6 Life cycle technical controls 6.6 ライフサイクルの技術的管理 ### 6.6.1 System development controls 6.6.1 システム開発の管理 **[TLSサーバー証明書]** CAが第三者によって開発された Linting ソフトウェアを使用する場合、そのソフトウェアの更新バージョンを監視し、更新のリリースから 3か月以内に更新を計画する (SHOULD)。 CAは、Linting ソフトウェアを更新するたびに、有効期限が切れておらず、失効していない利用者証明書に対して Linting を実行する場合がある (MAY)。 ### 6.6.2 Security management controls 6.6.2 セキュリティ運用管理 CAは、情報資産、人員、権限の管理、ハッキング対策やウイルス対策アプリケーションなどのセキュリティソフトウェアのタイムリーな更新などの運用管理を実施することで、セキュリティを確保する。 ### 6.6.3 Life cycle security controls 6.6.3 ライフサイクルセキュリティの管理 CAは、認証基盤システムが適切に開発、運用、保守されていることを確認し、必要に応じて改善するために、適切な評価を実行する。 ## 6.7 Network security controls 6.7 ネットワークセキュリティの管理 CAは、ネットワーク経由で認証基盤システムへの不正アクセスを防止するために、ファイアウォール、IDSなどの対策を実装する。 ## 6.8 Time-stamping 6.8 タイムスタンプ タイムスタンプに関する要件は、[Section 5.5.5](#555-requirements-for-time-stamping-of-records) に規定される。 # 7. CERTIFICATE, CRL, AND OCSP PROFILES 7 証明書、CRLおよびOCSP プロファイル ## 7.1 Certificate profile 7.1 証明書プロファイル CAは、[Section 6.1.5 - Key Sizes](#615-key-sizes)および[Section 6.1.6 - Public Key Parameters Generation and Quality Checking](#616-public-key-parameters-generation-and-quality-checking) に定められた技術要件を満たさなければならない。 **[TLSサーバー証明書]** 2023年9月15日より前は、CAは Baseline Requirements に指定されたプロファイルまたはBaseline Requirements version 1.8.6 に指定されたプロファイルに従って証明書を発行しなければならない。2023年9月15日以降は、CAは Baseline Requirements に指定されたプロファイルに従って証明書を発行しなければならない。 [APPENDIX B – Certificate profile](#appendix-b--certificate-profile) を参照。 ### 7.1.1 Version number(s) 7.1.1 バージョン番号 証明書は X.509 v3 形式とする。 ### 7.1.2 Certificate Content and Extensions 7.1.2 証明書拡張 CAが Baseline Requirements への準拠を主張する場合、発行するすべての証明書は、以下のいずれかの証明書プロファイルに準拠しなければならない。これらのプロファイルは、[RFC 5280](https://tools.ietf.org/html/rfc5280)から派生し、組み込まれている。明示的に記載されている場合を除き、RFC 5280によって課されるすべての規範的要件が、この文書によって課される規範的要件に加えて適用される。 - CA 証明書 - [Section 7.1.2.1 - Root CA 証明書プロファイル](#7121-root-ca-certificate-profile) - 下位 CA 証明書 - クロス証明書 - [Section 7.1.2.2 - クロス下位CA証明書プロファイル](#7122-cross-certified-subordinate-ca-certificate-profile) - 技術的制約されたCA証明書 - [Section 7.1.2.3 - 技術的制約されたTLS以外の下位CA証明書プロファイル](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) - [Section 7.1.2.4 - 技術的制約された事前CA証明書プロファイル](#7124-technically-constrained-precertificate-signing-ca-certificate-profile) - [Section 7.1.2.5 - 技術的制約されたTLS下位CA証明書プロファイル](#7125-technically-constrained-tls-subordinate-ca-certificate-profile) - [Section 7.1.2.6 - TLS下位CA証明書](#7126-tls-subordinate-ca-certificate-profile) - [Section 7.1.2.7 - 利用者 (EE) 証明書プロファイル](#7127-subscriber-server-certificate-profile) - [Section 7.1.2.8 - OCSPレスポンダー証明書プロファイル](#7128-ocsp-responder-certificate-profile) - [Section 7.1.2.9 - 事前証明書プロファイル](#7129-precertificate-profile) #### 7.1.2.1 Root CA Certificate Profile 7.1.2.1 Root CA 証明書プロファイル | **フィールド** | **説明** | | ------------------------ | --------------------------------------------------------------------- | | `tbsCertificate` | | | - `version` | v3(2) | | - `serialNumber` | CSPRNGからの64ビット以上の出力を含む1以上かつ2¹⁵⁹未満の連番ではない値 | | - `signature` | 参照 [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | - `issuer` | エンコードされた値はエンコードされた`subject`とバイト単位で同一 | | - `validity` | 参照 [Section 7.1.2.1.1](#71211-root-ca-validity) | | - `subject` | 参照 [Section 7.1.2.10.2](#712102-ca-certificate-naming) | | - `subjectPublicKeyInfo` | 参照 [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | - `issuerUniqueID` | 使用禁止 | | - `subjectUniqueID` | 使用禁止 | | - `extensions` | 参照 [Section 7.1.2.1.2](#71212-root-ca-extensions) | | - `signatureAlgorithm` | エンコードされた値は`tbsCertificate.signature`とバイト単位で同一 | | `signature` | - | ##### 7.1.2.1.1 Root CA Validity 7.1.2.1.1 Root CA の有効期間 | **フィールド** | **最小** | **最大** | | -------------- | -------------- | --------------- | | `notBefore` | 署名日の1日前 | 署名日時 | | `notAfter` | 2922日 (約8年) | 9132日 (約25年) | **注意**: この制限は、既存の `subject` および `subjectPublicKeyInfo` に対して新しいルート CA 証明書を生成する場合 (再発行等) にも適用される。 新しい CA 証明書は、これらのルールに準拠する必要がある。 ##### 7.1.2.1.2 Root CA Extensions 7.1.2.1.2 Root CA 拡張 | **拡張** | **存在** | **Critical** | **説明** | | -------------------------------------- | --------------- | ------------ | ---------------------------------------------------------------------- | | `authorityKeyIdentifier` | RECOMMENDED | N | 参照 [Section 7.1.2.1.3](#71213-root-ca-authority-key-identifier) | | `basicConstraints` | MUST | Y | 参照 [Section 7.1.2.1.4](#71214-root-ca-basic-constraints) | | `keyUsage` | MUST | Y | 参照 [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) | | `subjectKeyIdentifier` | MUST | N | 参照 [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `extKeyUsage` | MUST NOT | - | - | | `certificatePolicies` | NOT RECOMMENDED | N | 参照 [Section 7.1.2.10.5](#712105-ca-certificate-certificate-policies) | | 署名された証明書のタイムスタンプリスト | MAY | N | 参照 [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | その他の拡張 | NOT RECOMMENDED | - | 参照 [Section 7.1.2.11.5](#712115-other-extensions) | ##### 7.1.2.1.3 Root CA Authority Key Identifier 7.1.2.1.3 Root CA 認証局鍵識別子 | **フィールド** | **説明** | | --------------------------- | ----------------------------------------------- | | `keyIdentifier` | MUST。`subjectKeyIdentifier` フィールドと同一。 | | `authorityCertIssuer` | MUST NOT | | `authorityCertSerialNumber` | MUST NOT | ##### 7.1.2.1.4 Root CA Basic Constraints 7.1.2.1.4 Root CA の基本制約 | **Field** | **Description** | | ------------------- | ------------------- | | `cA` | MUST。 TRUEに設定。 | | `pathLenConstraint` | MUST NOT | #### 7.1.2.2 Cross-Certified Subordinate CA Certificate Profile 7.1.2.2 クロス認証下位CA証明書プロファイル この証明書プロファイルは、Root CA証明書または下位CA証明書のいずれであっても、1つ以上の既存のCA証明書と同じ主体者識別名と主体者公開鍵情報を使用してCA証明書を発行するときに使用できる (MAY)。 クロス認証された下位CAを発行する前に、発行CAは、既存のCA証明書が Baseline Requirements の対象であり、発行時点での Baseline Requirements の最新バージョンに準拠して発行されたことを確認しなければならない (MUST)。 | **フィールド** | **説明** | | ------------------------ | ------------------------------------------------------------------------------------------- | | `tbsCertificate` | | | - `version` | v3(2) | | - `serialNumber` | CSPRNGからの64ビット以上の出力を含む1以上かつ2¹⁵⁹未満の連番ではない値 | | - `signature` | 参照 [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | - `issuer` | 発行CAの`subject`フィールドとバイト単位で同一。 参照 [Section 7.1.4.1](#7141-name-encoding) | | - `validity` | 参照 [Section 7.1.2.2.1](#71221-cross-certified-subordinate-ca-validity) | | - `subject` | 参照 [Section 7.1.2.2.2](#71222-cross-certified-subordinate-ca-naming) | | - `subjectPublicKeyInfo` | 参照 [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | - `issuerUniqueID` | MUST NOT | | - `subjectUniqueID` | MUST NOT | | - `extensions` | 参照 [Section 7.1.2.2.3](#71223-cross-certified-subordinate-ca-extensions) | | `signatureAlgorithm` | エンコードされた値は`tbsCertificate.signature`とバイト単位で同一 | | `signature` | - | ##### 7.1.2.2.1 Cross-Certified Subordinate CA Validity 7.1.2.2.1 クロス認証下位CAの有効期間 | **フィールド** | **最小** | **最大** | | -------------- | ------------------------------------------------------------------------ | -------- | | `notBefore` | 署名日の1日前または既存のCA証明書の最も早い`notBefore`日のいずれか早い日 | 署名日時 | | `notAfter` | 署名日時 | 指定なし | ##### 7.1.2.2.2 Cross-Certified Subordinate CA Naming 7.1.2.2.2 クロス認証下位CAの識別名 `subject`は [Section 7.1.4](#714-name-forms) の要件に準拠していなければならない (MUST)。または、既存のCA 証明書が当時の Baseline Requirements のバージョンに準拠して発行されている場合、エンコードされた`subject`名は、既存のCA証明書のエンコードされた`subject`名とバイト単位で同一でなければならない (MUST)。 **注意**: 上記の例外により、既存のCA証明書が発行時に有効な Baseline Requirements に準拠している場合、CAはクロス認証された下位CA証明書を発行できる。これにより、クロス認証を許可しながら、[Section 7.1.4](#714-name-forms) の要件を時間の経過とともに改善できる。既存のCA証明書が準拠していない場合、クロス証明書の発行は許可されない。 ##### 7.1.2.2.3 Cross-Certified Subordinate CA Extensions 7.1.2.2.3 クロス認証下位CA拡張 | **拡張** | **存在** | **Critical** | **説明** | | -------------------------------------- | --------------- | ---------------------- | ------------------------------------------------------------------------------------------------ | | `authorityKeyIdentifier` | MUST | N | 参照 [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `basicConstraints` | MUST | Y | 参照 [Section 7.1.2.10.4](#712104-ca-certificate-basic-constraints) | | `certificatePolicies` | MUST | N | 参照 [Section 7.1.2.2.6](#71226-cross-certified-subordinate-ca-certificate-certificate-policies) | | `crlDistributionPoints` | MUST | N | 参照 [Section 7.1.2.11.2](#712112-crl-distribution-points) | | `keyUsage` | MUST | Y | 参照 [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) | | `subjectKeyIdentifier` | MUST | N | 参照 [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `authorityInformationAccess` | SHOULD | N | 参照 [Section 7.1.2.10.3](#712103-ca-certificate-authority-information-access) | | `nameConstraints` | MAY | \*[^name_constraints1] | 参照 [Section 7.1.2.10.8](#712108-ca-certificate-name-constraints) | | 署名された証明書のタイムスタンプリスト | MAY | N | 参照 [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | その他の拡張 | NOT RECOMMENDED | - | 参照 [Section 7.1.2.11.5](#712115-other-extensions) | 上記に加えて、extKeyUsage 拡張の要件は、クロス証明書で表された発行者組織と主体者識別名組織の関係によって異なる。 extKeyUsage 拡張は、次の表に示すように、以下の場合に「無制約」になる場合がある (MAY)。 - 対応する証明書の発行者名と主体者識別名で表される organizationName は、次のいずれかである。 - 同じ - 主体者識別名で表される organizationName は、発行者名で表される organizationName の関連会社である。 - クロス証明書の主体者識別名によって表される対応するCAは、発行CAと同じ組織または発行CAの関連会社によって運営されている。 表: 制約されてないEKUを持つクロス認証された下位CA | **拡張** | **存在** | **Critical** | **説明** | | ------------- | --------------- | ------------ | ------------------------------------------------------------------------------------------------- | | `extKeyUsage` | SHOULD[^eku_ca] | N | 参照 [Section 7.1.2.2.4](#71224-cross-certified-subordinate-ca-extended-key-usage---unrestricted) | それ以外の場合、extKeyUsage 拡張機能は、次の表に示すように「制限」されなければならない (MUST)。 表: 制約されたEKUを持つクロス認証された下位CA | **拡張** | **存在** | **Critical** | **説明** | | ------------- | -------------- | ------------ | ----------------------------------------------------------------------------------------------- | | `extKeyUsage` | MUST[^eku_ca1] | N | 参照 [Section 7.1.2.2.5](#71225-cross-certified-subordinate-ca-extended-key-usage---restricted) | [^eku_ca]: [RFC 5280, Section 4.2.1.12](https://tools.ietf.org/html/rfc5280#section-4.2.1.12) では、この拡張機能は通常、エンドエンティティ証明書内にのみ表示されると記載されているが、[Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) では、多くのアプリケーションソフトウェアサプライヤーによって実装されているように、この拡張機能を使用してCA証明書の範囲を制限することで、検証者をさらに保護する。 [^name_constraints1]: この拡張機能の重要性を含む詳細な要件については、[Section 7.1.2.10.8](#712108-ca-certificate-name-constraints) を参照のこと。 ##### 7.1.2.2.4 Cross-Certified Subordinate CA Extended Key Usage - Unrestricted 7.1.2.2.4 クロス認証下位CA拡張鍵使用法 - 制約無し 表: 制約されてない拡張鍵の使用目的（関連クロス認証CA） | **鍵の目的** | **説明** | | --------------------- | ------------------------------------------------------------------------------------------------------------------- | | `anyExtendedKeyUsage` | 制約が適用されていないことを示す特別な拡張鍵使用法。存在する場合、これが唯一の鍵の使用法でなければならない (MUST)。 | | その他の値 | CAは、`anyExtendedKeyUsage` 鍵使用法が存在する場合に、他の鍵使用法を含めてはならない (MUST NOT)。 | あるいは、発行CAがこの形式を使用しない場合、拡張鍵使用法の拡張機能が存在する場合は、[Section 7.1.2.2.5](#71225-cross-certified-subordinate-ca-extended-key-usage---restricted)で指定されているようにエンコードされなければならない (MUST)。 ##### 7.1.2.2.5 Cross-Certified Subordinate CA Extended Key Usage - Restricted 7.1.2.2.5 クロス認証下位CA拡張鍵使用法 - 制約あり 表: 制約されたTLSクロス認証下位CA拡張鍵の使用目的 (つまり、TLS証明書を直接または推移的に発行する制約ありクロス認証下位CAの場合) | **鍵の目的** | **説明** | | ----------------------- | --------------- | | `id-kp-serverAuth` | MUST | | `id-kp-clientAuth` | MAY | | `id-kp-emailProtection` | MUST NOT | | `id-kp-codeSigning` | MUST NOT | | `id-kp-timeStamping` | MUST NOT | | `anyExtendedKeyUsage` | MUST NOT | | 他の値 | NOT RECOMMENDED | 表: 制約された非TLSクロス認証下位CA拡張鍵の使用目的 (つまり、TLS証明書を直接または推移的に発行しない制限されたクロス認証下位CAの場合) | **鍵の目的** | **説明** | | --------------------- | -------- | | `id-kp-serverAuth` | MUST NOT | | `anyExtendedKeyUsage` | MUST NOT | | 他の値 | MAY | それぞれに含まれる拡張鍵使用法の鍵使用目的: 1. 次の場合を除き、パブリックインターネットのコンテキストで適用しなければならない (MUST) (例: プライベートに管理されたネットワークでのみ有効なサービスには適用できない)。 a. 鍵の使用目的が、申請者が所有権を証明できるOIDの範囲内にある。 b. 申請者が、それ以外の場合には、公的な文脈で鍵の使用目的を主張する権利を実証することができる。 2. CAによって検証された証明書情報について、検証者を誤解させるようなセマンティクスを含めてはならない (MUST NOT)。たとえば、リモート発行のため、対応する私有鍵がそのようなハードウェアに限定されていることをCAが検証できない場合に、スマートカードへの保存を主張する鍵使用目的を含めるなどである。 3. 発行CAによって検証されなければならない (MUST) (つまり、発行CAは、クロス認証された下位 CAが鍵の使用目的を主張する権限を持っていることを確認すしなければならない (MUST))。 CAは、証明書に鍵使用目的を含める理由を認識していない限り、追加の鍵使用目的を含めてはならない (MUST NOT)。 ##### 7.1.2.2.6 Cross-Certified Subordinate CA Certificate Certificate Policies 7.1.2.2.6 クロス認証下位CA証明書の証明書ポリシー CP拡張には、少なくとも 1 つの `PolicyInformation` が含まれていなければならない (MUST)。各 `PolicyInformation` は次のプロファイルと一致しなければならない (MUST)。 表: ポリシー制約なし（関連CA） | **フィールド** | **存在** | **説明** | | ------------------ | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `policyIdentifier` | MUST | 発行CAがポリシー制約がないことを表す場合および下位CA が発行 CA の関連会社である場合、発行 CA は anyPolicy ポリシー識別子を使用できる (MAY)。これは、唯一の `PolicyInformation` 値でなければならない (MUST)。 | | - `anyPolicy` | MUST | | | `policyQualifiers` | NOT RECOMMENDED | 存在する場合は、以下の表の許可された`policyQualifiers`のみを含めなければならない (MUST)。 | 表: ポリシー制約あり | **フィールド** | **存在** | **説明** | | ------------------------------------------------------------------------------------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `policyIdentifier` | MUST | 次のいずれかのポリシー識別子 | | - A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST | CAには、この証明書によって推移的に発行される特定の利用者証明書タイプ ([Section 7.1.2.7.1](#71271-subscriber-certificate-types) を参照) に関連付けられた予約済み証明書ポリシー識別子 ([Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers) を参照) が少なくとも 1 つ含まれていなければならない (MUST)。 | | - `anyPolicy` | MUST NOT | `anyPolicy` ポリシー識別子は存在してはならない (MUST NOT)。 | | - その他の識別子 | MAY | 存在する場合、CAによって定義され、CAのCP/CPSに文書化されなければならない (MUST)。 | | `policyQualifiers` | NOT RECOMMENDED | 存在する場合は、以下の表の許可された`policyQualifiers`のみを含めなければならない (MUST)。 | このプロファイルでは、証明書ポリシー拡張内の最初の`PolicyInformation`値に予約済み証明書ポリシー識別子 ([7.1.6.1](#7161-reserved-certificate-policy-identifiers)を参照) [^first_policy_note] を含めることを推奨する (RECOMMENDS)。`PolicyInformation`値の順序に関係なく、証明書ポリシー拡張には少なくとも 1 つの予約済み証明書ポリシー識別子を含めなければならない (MUST)。利用者証明書がこの証明書プロファイルに基づいて発行された証明書に直接連鎖する場合、このクロス認証された下位CA証明書には、正確に 1 つの予約済み証明書ポリシー識別子を含めなければならない (MUST)。 **注意**: policyQualifiers は、この証明書プロファイルに基づいて発行されるどの証明書にも存在することは推奨されない (NOT RECOMMENDED)。この情報は、通常の検証者に何の価値も提供せずに証明書のサイズを増加させ、必要に応じて他の手段で取得できるためである。 `policyQualifiers` が許可され、`PolicyInformation` フィールド内に存在する場合、次のようにフォーマットされなければならない (MUST)。 表: 許可された `policyQualifiers` | **修飾子 ID** | **存在** | **フィールドタイプ** | **内容** | | ------------------------------------ | -------- | -------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | 発行CAのCP、CPS、検証者契約、または発行CAによって提供されるオンラインポリシー情報へのその他のポインターの HTTP または HTTPS URL。 | | その他の修飾子 | MUST NOT | - | - | #### 7.1.2.3 Technically Constrained Non-TLS Subordinate CA Certificate Profile 7.1.2.3 技術的に制約された非TLS下位CA証明書プロファイル この証明書プロファイルは、技術的に制約があると見なされるCA証明書を発行する場合に使用できる (MAY)が、TLS証明書を直接または推移的に発行するためには使用されない。 | **フィールド** | **説明** | | ------------------------ | -------------------------------------------------------------------------------------------------------------------- | | `tbsCertificate` | | | - `version` | v3(2) | | - `serialNumber` | CSPRNGからの出力の少なくとも64ビットを含む、ゼロ (0) より大きく 2¹⁵⁹ 未満の非連続な数値でなければならない (MUST)。 | | - `signature` | 参照 [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | - `issuer` | 発行CAの`subject` フィールドとバイト単位で同一でなければならない (MUST)。参照 [Section 7.1.4.1](#7141-name-encoding) | | - `validity` | 参照 [Section 7.1.2.10.1](#712101-ca-certificate-validity) | | - `subject` | 参照 [Section 7.1.2.10.2](#712102-ca-certificate-naming) | | - `subjectPublicKeyInfo` | 参照 [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | - `issuerUniqueID` | 存在してはならない (MUST NOT) | | - `subjectUniqueID` | 存在してはならない (MUST NOT) | | - `extensions` | 参照 [Section 7.1.2.3.1](#71231-technically-constrained-non-tls-subordinate-ca-extensions) | | `signatureAlgorithm` | エンコードされた値は、`tbsCertificate.signature` とバイト単位で同一でなければならない (MUST)。 | | `signature` | - | ##### 7.1.2.3.1 Technically Constrained Non-TLS Subordinate CA Extensions 7.1.2.3.1 技術的に制約された非TLS下位CA拡張 | **拡張** | **存在** | **Critical** | **説明** | | -------------------------------------- | --------------- | --------------------- | ---------------------------------------------------------------------------------------------------- | | `authorityKeyIdentifier` | MUST | N | 参照 [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `basicConstraints` | MUST | Y | 参照 [Section 7.1.2.10.4](#712104-ca-certificate-basic-constraints) | | `crlDistributionPoints` | MUST | N | 参照 [Section 7.1.2.11.2](#712112-crl-distribution-points) | | `keyUsage` | MUST | Y | 参照 [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) | | `subjectKeyIdentifier` | MUST | N | 参照 [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `extKeyUsage` | MUST[^eku_ca] | N | 参照 [Section 7.1.2.3.3](#71233-technically-constrained-non-tls-subordinate-ca-extended-key-usage) | | `authorityInformationAccess` | SHOULD | N | 参照 [Section 7.1.2.10.3](#712103-ca-certificate-authority-information-access) | | `certificatePolicies` | MAY | N | 参照 [Section 7.1.2.3.2](#71232-technically-constrained-non-tls-subordinate-ca-certificate-policies) | | `nameConstraints` | MAY | \*[^name_constraints] | 参照 [Section 7.1.2.10.8](#712108-ca-certificate-name-constraints) | | 署名された証明書のタイムスタンプリスト | MAY | N | 参照 [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | その他の拡張 | NOT RECOMMENDED | - | 参照 [Section 7.1.2.11.5](#712115-other-extensions) | ##### 7.1.2.3.2 Technically Constrained Non-TLS Subordinate CA Certificate Policies 7.1.2.3.2 技術的に制約された非TLS下位CAのCP 存在する場合、CP拡張機能は、以下の 2 つの表のいずれかとしてフォーマットされなければならない (MUST)。 表: ポリシー制約なし（関連CA） | **フィールド** | **存在** | **内容** | | ------------------ | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `policyIdentifier` | MUST | 発行CAがポリシー制限がないことを表明する場合、下位CAは発行CAの関連会社でなければならない (MUST)。CP拡張には、単一の `PolicyInformation` 値のみを含なければならず (MUST)、この値には `anyPolicy` ポリシー識別子が含まれていなければならない (MUST)。 | | - `anyPolicy` | MUST | | | `policyQualifiers` | NOT RECOMMENDED | 存在する場合、以下の表から許可された`policyQualifiers`のみを含なければならない (MUST)。 | 表: ポリシー制約あり | **フィールド** | **存在** | **内容** | | ------------------------------------------------------------------------------------------- | --------------- | ------------------------------------------------------------------------------------------ | | `policyIdentifier` | MUST | 次のいずれかのポリシー識別子 | | - A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST NOT | | | - `anyPolicy` | MUST NOT | `anyPolicy` ポリシー識別子は存在してはならない (MUST NOT)。 | | - その他の識別子 | MAY | 存在する場合、CAによってCP/CPSに文書化されなければならない (MUST)。 | | `policyQualifiers` | NOT RECOMMENDED | 存在する場合は、以下の表の許可された`policyQualifiers` のみを含めなければならない (MUST)。 | 表: 許可された `policyQualifiers` | **修飾子 ID** | **存在** | **フィールドタイプ** | **内容** | | ------------------------------------ | -------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | 発行CAのCP、CPS、検証者契約、または発行CAによって提供されるオンラインポリシー情報へのその他のポインターのHTTPまたはHTTPS URL。 | | その他の修飾子 | MUST NOT | - | - | ##### 7.1.2.3.3 Technically Constrained Non-TLS Subordinate CA Extended Key Usage 7.1.2.3.3 技術的に制約された非TLS下位CA拡張鍵使用法 発行CAは、下位CA証明書が、含まれる各拡張鍵の使用目的に対して証明書を発行する権限を持っていることを確認しなければならない (MUST)。複数の独立した鍵目的 (例: `id-kp-timeStamping` および `id-kp-codeSigning`) は推奨されない (NOT RECOMMENDED)。 | **鍵の目的** | **OID** | **存在** | | -------------------------- | ----------------------- | -------- | | `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST NOT | | `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST NOT | | `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT | | 事前証明書サイニング証明書 | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT | | その他の値 | - | MAY | #### 7.1.2.4 Technically Constrained Precertificate Signing CA Certificate Profile 7.1.2.4 技術的に制約された事前証明書サイニングCA証明書プロファイル この証明書プロファイルは、[RFC 6962, Section 3.1](https://tools.ietf.org/html/rfc6962#section-3.1) で説明されているように、事前証明書サイニングCAとして使用されるCA証明書を発行するときに使用しなければならない (MUST)。CA証明書がこのプロファイルに準拠している場合、技術的に制約があると見なされる。 事前証明書サイニングCAは、[Section 7.1.2.9](#7129-precertificate-profile) で定義されているように、事前証明書に署名するためにのみ使用しなければならない (MUST)。事前証明書サイニングCAが事前証明書を発行する場合、事前証明書サイニングCAの発行CAが、[RFC 6962, Section 3.2](https://tools.ietf.org/html/rfc6962#section-3.2) で指定された変更を適用した後、事前証明書に一致する `tbsCertificate` を含む証明書を発行したと解釈される。 RFC 6962 のSection 3.2 に記載されているように、事前証明書の`signature`フィールドは、これらの変更の一部として変更されない。そのため、事前証明書サイニングCAは、事前証明書を発行するときに発行CAと同じ署名アルゴリズムを使用しなければならない (MUST)。また、それに応じて、発行CAと同じ公開鍵アルゴリズムの公開鍵を使用しなければならない (MUST)が、異なるCA鍵ペアを使用することもできる (MAY)。 | **フィールド** | **説明** | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `tbsCertificate` | | | - `version` | v3(2) | | - `serialNumber` | CSPRNGからの出力の少なくとも64ビットを含む、ゼロ (0) より大きく 2¹⁵⁹ 未満の非連続な数値でなければならない (MUST)。 | | - `signature` | 参照 [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | - `issuer` | 発行CAの`subject`フィールドとバイト単位で同一でなければならない (MUST)。 参照 [Section 7.1.4.1](#7141-name-encoding) | | - `validity` | 参照 [Section 7.1.2.10.1](#712101-ca-certificate-validity) | | - `subject` | 参照 [Section 7.1.2.10.2](#712102-ca-certificate-naming) | | - `subjectPublicKeyInfo` | アルゴリズム識別子は、発行CAの `subjectPublicKeyInfo` フィールドのアルゴリズム識別子とバイト単位で同一でなければならない (MUST)。 参照 [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | - `issuerUniqueID` | 存在してはならない (MUST NOT) | | - `subjectUniqueID` | 存在してはならない (MUST NOT) | | - `extensions` | 参照 [Section 7.1.2.4.1](#71241-technically-constrained-precertificate-signing-ca-extensions) | | `signatureAlgorithm` | エンコードされた値は、`tbsCertificate.signature` とバイト単位で同一でなければならない (MUST)。 | | `signature` | - | ##### 7.1.2.4.1 Technically Constrained Precertificate Signing CA Extensions 7.1.2.4.1 技術的に制約された事前証明書サイニングCA拡張 | **拡張** | **存在** | **Critical** | **説明** | | ------------------------------------ | --------------- | --------------------- | ----------------------------------------------------------------------------------------------------- | | `authorityKeyIdentifier` | MUST | N | 参照 [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `basicConstraints` | MUST | Y | 参照 [Section 7.1.2.10.4](#712104-ca-certificate-basic-constraints) | | `certificatePolicies` | MUST | N | 参照 [Section 7.1.2.10.5](#712105-ca-certificate-certificate-policies) | | `crlDistributionPoints` | MUST | N | 参照 [Section 7.1.2.11.2](#712112-crl-distribution-points) | | `keyUsage` | MUST | Y | 参照 [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) | | `subjectKeyIdentifier` | MUST | N | 参照 [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `extKeyUsage` | MUST[^eku_ca] | N | 参照 [Section 7.1.2.4.2](#71242-technically-constrained-precertificate-signing-ca-extended-key-usage) | | `authorityInformationAccess` | SHOULD | N | 参照 [Section 7.1.2.10.3](#712103-ca-certificate-authority-information-access) | | `nameConstraints` | MAY | \*[^name_constraints] | 参照 [Section 7.1.2.10.8](#712108-ca-certificate-name-constraints) | | 署名済み証明書のタイムスタンプリスト | MAY | N | 参照 [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | その他の拡張子 | NOT RECOMMENDED | - | 参照 [Section 7.1.2.11.5](#712115-other-extensions) | ##### 7.1.2.4.2 Technically Constrained Precertificate Signing CA Extended Key Usage 7.1.2.4.2 技術的に制約された事前証明書サイニングCA拡張鍵使用法 | **鍵の目的** | **OID** | **存在** | | -------------------------- | ----------------------- | -------- | | 事前証明書サイニング証明書 | 1.3.6.1.4.1.11129.2.4.4 | MUST | | その他の値 | - | MUST NOT | #### 7.1.2.5 Technically Constrained TLS Subordinate CA Certificate Profile 7.1.2.5 技術的に制約されたTLS下位CA証明書プロファイル この証明書プロファイルは、技術的に制約があると見なされ、TLS証明書を直接または推移的に発行するために使用されるCA証明書を発行するときに使用できる (MAY)。 | **フィールド** | **説明** | | ------------------------ | --------------------------------------------------------------------------------------------------------------------- | | `tbsCertificate` | | | - `version` | be v3(2) | | - `serialNumber` | CSPRNGからの出力の少なくとも64ビットを含む、ゼロ (0) より大きく 2¹⁵⁹ 未満の非連続な数値でなければならない (MUST)。 | | - `signature` | 参照 [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | - `issuer` | 発行CAの`subject` フィールドとバイト単位で同一でなければならない (MUST)。 参照 [Section 7.1.4.1](#7141-name-encoding) | | - `validity` | 参照 [Section 7.1.2.10.1](#712101-ca-certificate-validity) | | - `subject` | 参照 [Section 7.1.2.10.2](#712102-ca-certificate-naming) | | - `subjectPublicKeyInfo` | 参照 [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | - `issuerUniqueID` | 存在してはならない (MUST NOT) | | - `subjectUniqueID` | 存在してはならない (MUST NOT) | | - `extensions` | 参照 [Section 7.1.2.5.1](#71251-technically-constrained-tls-subordinate-ca-extensions) | | `signatureAlgorithm` | エンコードされた値は、`tbsCertificate.signature` とバイト単位で同一でなければならない (MUST)。 | | `signature` | - | ##### 7.1.2.5.1 Technically Constrained TLS Subordinate CA Extensions 7.1.2.5.1 技術的に制約されたTLS下位CA拡張 | **拡張** | **存在** | **Critical** | **説明** | | -------------------------------------- | --------------- | --------------------- | -------------------------------------------------------------------------------------------- | | `authorityKeyIdentifier` | MUST | N | 参照 [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `basicConstraints` | MUST | Y | 参照 [Section 7.1.2.10.4](#712104-ca-certificate-basic-constraints) | | `certificatePolicies` | MUST | N | 参照 [Section 7.1.2.10.5](#712105-ca-certificate-certificate-policies) | | `crlDistributionPoints` | MUST | N | 参照 [Section 7.1.2.11.2](#712112-crl-distribution-points) | | `keyUsage` | MUST | Y | 参照 [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) | | `subjectKeyIdentifier` | MUST | N | 参照 [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `extKeyUsage` | MUST [^eku_ca] | N | 参照 [Section 7.1.2.10.6](#712106-ca-certificate-extended-key-usage) | | `nameConstraints` | MUST | \*[^name_constraints] | 参照 [Section 7.1.2.5.2](#71252-technically-constrained-tls-subordinate-ca-name-constraints) | | `authorityInformationAccess` | SHOULD | N | 参照 [Section 7.1.2.10.3](#712103-ca-certificate-authority-information-access) | | 署名された証明書のタイムスタンプリスト | MAY | N | 参照 [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | その他の拡張 | NOT RECOMMENDED | - | 参照 [Section 7.1.2.11.5](#712115-other-extensions) | ##### 7.1.2.5.2 Technically Constrained TLS Subordinate CA Name Constraints 7.1.2.5.2 技術的に制約されたTLS下位CA名前制約 TLS下位CAが技術的に制約されるには、次のように名前の制約拡張機能をエンコードしなければならない (MUST)。 RFC 5280の明示的な例外として、この拡張機能はクリティカルであるとマークする必要がある (SHOULD)が、名前の制約をサポートしない特定のレガシーアプリケーションとの互換性が必要な場合は、非クリティカルにマークされる場合がある (MAY)。 表: `nameConstraints` 要件 | **フィールド** | **説明** | | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `permittedSubtrees` | `permittedSubtrees`には、指定された`GeneralName`名前のタイプが`excludedSubtrees`内に表示されて、その名前タイプのすべての名前を除外しない限り、`dNSName`および`iPAddress` `GeneralName`の両方に少なくとも1つの`GeneralSubtree`を含めるなければならない (MUST)。さらに、`permittedSubtrees`には、`directoryName` `GeneralName`名タイプの少なくとも1つの`GeneralSubtree`が含まれていなければならない (MUST)。 | | - `GeneralSubtree` | `permittedSubtrees`内に表示される`GeneralSubtree`の要件。 | | -- `base` | 次の表を参照。 | | -- `minimum` | 存在してはならない (MUST NOT)。 | | -- `maximum` | 存在してはならない (MUST NOT)。 | | `excludedSubtrees` | expluedSubtreeには、`permittedSubtrees`にその名前タイプのインスタンスが表示されない限り、`dNSName`および`iPAddress` `GeneralName`の各名前タイプに少なくとも 1つの`GeneralSubtree`を含めなければならない (MUST)。 DirectoryNameの名前タイプは推奨されない (NOT RECOMMENDED)。 | | - `GeneralSubtree` | `permittedSubtrees`内に表示される`GeneralSubtree`の要件。 | | -- `base` | 次の表を参照。 | | -- `minimum` | 存在してはならない (MUST NOT)。 | | -- `maximum` | 存在してはならない (MUST NOT)。 | 次の表には、`permittedSubtrees`または`excludedSubtrees`のいずれかの`GeneralSubtree`の`base`内に表示される`GeneralName`の要件が含まれている。 表: `base`フィールドの `GeneralName` の要件 | **名前タイプ** | **存在** | **許可された Subtrees** | **除外された Subtrees** | **全体の Namespace 除外** | | --------------- | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `dNSName` | MUST | CAは、申請者が`dNSName`を登録したことを確認するか、ドメイン登録者によって登録者に代わって行動することを許可されていることを確認しなければならない (MUST)。 参照 [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | `permittedSubtrees`に少なくとも 1つの `dNSName` インスタンスが存在する場合、CAは除外される 1つまたは複数の下位ドメインを示す場合がある (MAY)。 | `permittedSubtrees` に `dNSName` インスタンスが存在しない場合は、CAはドメイン名が許可されていないことを示すために長さがゼロの `dNSName` を含めなければならない (MUST)。 | | `iPAddress` | MUST NOT | セコムトラストシステムズズは、IPv4 または IPv6 アドレスを含むTLSサーバー利用者（エンドエンティティ）証明書を発行しない。 | 少なくとも 1つの `iPAddress` インスタンスが `permittedSubtrees` に存在する場合、CAは除外される範囲の 1つ以上の下位区分を示している可能性がある(MAY)。 | `permittedSubtrees`に IPv4 `iPAddress` が存在しない場合、CAには 8ゼロオクテットの`iPAddress`を含めなければならず (MUST)、0.0.0.0/0 の IPv4 範囲が除外されていることを示している。`permittedSubtrees` に IPv6 `iPAddress`が存在しない場合、CAには 32ゼロオクテットの `iPAddress`を含めるなければならない (MUST)。 | | `directoryName` | MUST | CAは、発行されたすべての証明書が、名前フォーム（[Section 7.1.4](#714-name-forms)を参照）を含む関連証明書プロファイル（[Section 7.1.2](#712-certificate-content-and-extensions) を参照）に準拠するように、申請者/子会社の名前属性を確認しなければならない (MUST)。 | `excludedSubtrees` に値を含めることは推奨しない (NOT RECOMMENDED)。 | CAには、`permittedSubtrees` 内に値を含めなければならない (MUST) ため、これは適用されない。詳細については、除外された Subtrees の要件を参照のこと。 | | `otherName` | NOT RECOMMENDED | 下記参照 | 下記参照 | 下記参照 | | その他の値 | MUST NOT | - | - | - | 他の `otherName`, 存在した場合は以下を参照。 1. 次の場合を除き、パブリックインターネットのコンテキストで適用しなければならない (MUST)。 a. `type-id` は、申請者が所有権を示すOID範囲内に収まる。 b. それ以外の場合、申請者は、公開の文脈でデータを主張する権利を示すことができる。 2. CAによって検証された証明書情報について、頼っている検証者を誤解させるセマンティクスを含めてはならない (MUST NOT)。 3. `otherName` `type-id`と`value`を定義する関連する ASN.1 モジュールに従ってDERエンコードしなければならない (MUST)。 CAが証明書にデータを含める理由をCAが認識していない限り、CASは追加の名前を含めてはならない (MUST NOT)。 #### 7.1.2.6 TLS Subordinate CA Certificate Profile 7.1.2.6 TLS下位CA証明書プロファイル | **フィールド** | **説明** | | ------------------------ | --------------------------------------------------------------------------------------------------------------------- | | `tbsCertificate` | | | - `version` | v3(2) | | - `serialNumber` | CSPRNGからの出力の少なくとも64ビットを含む、ゼロ (0) より大きく 2¹⁵⁹ 未満の非連続な数値でなければならない (MUST)。 | | - `signature` | 参照 [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | - `issuer` | 発行CAの`subject` フィールドとバイト単位で同一でなければならない (MUST)。 参照 [Section 7.1.4.1](#7141-name-encoding) | | - `validity` | 参照 [Section 7.1.2.10.1](#712101-ca-certificate-validity) | | - `subject` | 参照 [Section 7.1.2.10.2](#712102-ca-certificate-naming) | | - `subjectPublicKeyInfo` | 参照 [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | - `issuerUniqueID` | 存在してはならない (MUST NOT) | | - `subjectUniqueID` | 存在してはならない (MUST NOT) | | - `extensions` | 参照 [Section 7.1.2.6.1](#71261-tls-subordinate-ca-extensions) | | `signatureAlgorithm` | エンコードされた値は、`tbsCertificate.signature`とバイト単位で同一でなければならない (MUST)。 | | `signature` | - | ##### 7.1.2.6.1 TLS Subordinate CA Extensions 7.1.2.6.1 TLS下位CA拡張 | **拡張** | **存在** | **Critical** | **説明** | | -------------------------------------- | --------------- | --------------------- | ------------------------------------------------------------------------------ | | `authorityKeyIdentifier` | MUST | N | 参照 [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `basicConstraints` | MUST | Y | 参照 [Section 7.1.2.10.4](#712104-ca-certificate-basic-constraints) | | `certificatePolicies` | MUST | N | 参照 [Section 7.1.2.10.5](#712105-ca-certificate-certificate-policies) | | `crlDistributionPoints` | MUST | N | 参照 [Section 7.1.2.11.2](#712112-crl-distribution-points) | | `keyUsage` | MUST | Y | 参照 [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) | | `subjectKeyIdentifier` | MUST | N | 参照 [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `extKeyUsage` | MUST[^eku_ca] | N | 参照 [Section 7.1.2.10.6](#712106-ca-certificate-extended-key-usage) | | `authorityInformationAccess` | SHOULD | N | 参照 [Section 7.1.2.10.3](#712103-ca-certificate-authority-information-access) | | `nameConstraints` | MAY | \*[^name_constraints] | 参照 [Section 7.1.2.10.8](#712108-ca-certificate-name-constraints) | | 署名された証明書のタイムスタンプリスト | MAY | N | 参照 [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | 他の拡張子 | NOT RECOMMENDED | - | 参照 [Section 7.1.2.11.5](#712115-other-extensions) | #### 7.1.2.7 Subscriber (Server) Certificate Profile 7.1.2.7 利用者（サーバー）証明書プロファイル | **フィールド** | **説明** | | ------------------------ | --------------------------------------------------------------------------------------------------------------------- | | `tbsCertificate` | | | - `version` | v3(2) | | - `serialNumber` | CSPRNGからの出力の少なくとも64ビットを含む、ゼロ (0) より大きく 2¹⁵⁹ 未満の非連続な数値でなければならない (MUST)。 | | - `signature` | 参照 [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | - `issuer` | 発行CAの`subject` フィールドとバイト単位で同一でなければならない (MUST)。 参照 [Section 7.1.4.1](#7141-name-encoding) | | - `validity` | | | -- `notBefore` | 証明書署名操作から48時間以内の値。 | | -- `notAfter` | 参照 [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) | | - `subject` | 参照 [Section 7.1.2.7.1](#71271-subscriber-certificate-types) | | - `subjectPublicKeyInfo` | 参照 [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | - `issuerUniqueID` | 存在してはならない (MUST NOT) | | - `subjectUniqueID` | 存在してはならない (MUST NOT) | | - `extensions` | 参照 [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) | | `signatureAlgorithm` | エンコードされた値は、`tbsCertificate.signature`とバイト単位で同一でなければならない (MUST)。 | | `signature` | - | ##### 7.1.2.7.1 Subscriber Certificate Types 7.1.2.7.1 利用者証明書のタイプ 発行される可能性のある利用者証明書には4つのタイプがある。これは、含まれる主体者識別名情報の量に基づいて異なる。これらの各証明書タイプは、3つの例外を除いて共通のプロファイルを共有している。発生する可能性のある`subject`名フィールド、それらのフィールドの検証方法および`certificatePolicies` 拡張の内容。 | **タイプ** | **説明** | | ----------------- | -------------------------------------------------------------------- | | ドメイン認証 (DV) | 参照 [Section 7.1.2.7.2](#71272-domain-validated) | | 個人認証 (IV) | セコムトラストシステムズでは、個人認証用の利用者証明書を発行しない。 | | 組織認証 (OV) | 参照 [Section 7.1.2.7.4](#71274-organization-validated) | | 拡張認証 (EV) | 参照 [Section 7.1.2.7.5](#71275-extended-validation) | **注意**: 各利用者証明書の種類によって主体者識別名情報は異なるが、すべての証明書はデバイス ID (ドメイン名や IP アドレス) について同じレベルの保証を提供する。 ##### 7.1.2.7.2 Domain Validated 7.1.2.7.2 ドメイン認証（DV） 利用者証明書がドメイン認証されるためには、次のプロファイルを満たしていなければならない (MUST)。 | **フィールド** | **要件** | | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `subject` | 次の表を参照。 | | `certificatePolicies` | 存在していなければならない (MUST)。`policyIdentifier`として、`2.23.140.1.2.1` の [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) を使用しなければならない (MUST)。参照 [Section 7.1.2.7.9](#71279-subscriber-certificate-certificate-policies). | | その他のすべての拡張 | 参照 [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) | すべての`subject`名は [Section 7.1.4](#714-name-forms) で指定されているとおりにエンコードされなければならない (MUST)。 次の表は、`AttributeTypeAndValue` の `type` フィールド内に表示される可能性のある許容される `AttributeType` と、`value` フィールド内で許可される内容の詳細を示している。 表: ドメイン認証済みの`subject`属性 | **属性名** | **存在** | **値** | **検証** | | ------------- | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | | `countryName` | MUST NOT | セコムトラストシステムズ にはこの属性は含まれない。 | - | | `commonName` | NOT RECOMMENDED | 存在する場合は、[Section 7.1.4.3](#7143-subscriber-certificate-common-name-attribute) に従って `subjectAltName` 拡張から派生した値を含めなければならない (MUST)。 | | | その他の属性 | MUST NOT | - | - | ##### 7.1.2.7.3 Individual Validated 7.1.2.7.3 個人認証（IV） セコムトラストシステムズでは、個人認証用の利用者証明書を発行していない。 ##### 7.1.2.7.4 Organization Validated 7.1.2.7.4 組織認証（OV） 利用者証明書が組織によって認証されるためには、次のプロファイルを満たさなければならない (MUST)。 | **フィールド** | **要件** | | --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `subject` | 次の表を参照。 | | `certificatePolicies` | 存在しなければならない (MUST)。`2.23.140.1.2.2`の [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) を`policyIdentifier`として使用しなければならない (MUST)。参照 [Section 7.1.2.7.9](#71279-subscriber-certificate-certificate-policies). | | その他のすべての拡張 | 参照 [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) | すべての`subject`名は[Section 7.1.4](#714-name-forms) で指定されているとおりにエンコードされなければならない (MUST)。 次の表は、`AttributeTypeAndValue` の `type` フィールド内に表示される可能性のある許容される `AttributeType` と、`value` フィールド内で許可される内容の詳細を示している。 表: 組織認証済みの `subject` 属性 | **属性名** | **存在** | **値** | **検証** | | ------------------------ | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------ | | `domainComponent` | MUST NOT | セコムトラストシステムズ はこの属性を含まない。 | - | | `countryName` | MUST | 主体者識別名に関連付けられた国の 2 文字の ISO 3166-1 国コード。国が公式の ISO 3166-1 国コードで表されていない場合、CAは、公式の ISO 3166-1 alpha-2 コードが割り当てられていないことを示す、`XX` の ISO 3166-1 ユーザー割り当てコードを指定しなければならない (MUST)。 | [Section 3.2.2.1](#3221-identity) | | `stateOrProvinceName` | MUST / MAY | `localityName` がない場合は存在しなければならない (MUST)。それ以外の場合は存在してもよい (MAY)。存在する場合は、主体者識別名の州または県の情報を含めなければならない (MUST)。 | [Section 3.2.2.1](#3221-identity) | | `localityName` | MUST / MAY | `stateOrProvinceName` がない場合は存在しなければならない (MUST)。それ以外の場合は存在してもよい (MAY)。存在する場合は、主体者識別名の地域情報を含めなければならない (MUST)。 | [Section 3.2.2.1](#3221-identity) | | `postalCode` | MUST NOT | セコムトラストシステムズ はこの属性を含まない。 | - | | `streetAddress` | MUST NOT | セコムトラストシステムズ はこの属性を含まない。 | - | | `organizationName` | MUST | 主体者識別名の名前/DBA/トレードネーム。CAは、一般的なバリエーションや略語など、検証済み名称とわずかに異なる情報をこのフィールドに含めることができる (MAY)。ただし、CAがその違いを文書化し、使用される略語がローカルで受け入れられている略語である場合に限る。たとえば、公式記録に「Company Name Incorporated」と記載されている場合、CAは「Company Name Inc.」または「Company Name」を使用できる (MAY)。両方が含まれる場合、DBA/トレードネームが最初に表示され、その後に括弧で囲まれた主体者識別名の名前が続く (SHALL)。 | [Section 3.2.2.2](#3222-dbatradename) | | `surname` | MUST NOT | - | - | | `givenName` | MUST NOT | - | - | | `organizationalUnitName` | MUST NOT | - | - | | `commonName` | NOT RECOMMENDED | 存在する場合は、[Section 7.1.4.3](#7143-subscriber-certificate-common-name-attribute) に従って `subjectAltName` 拡張から派生した値を含めなければならない (MUST)。 | | | その他すべての属性 | NOT RECOMMENDED | - | 参照 [Section 7.1.4.4](#7144-other-subject-attributes) | さらに、`subject`属性には、「.」、「-」、「」(つまりスペース) 文字などのメタデータのみ/値が存在しない、不完全である、または該当しないことを示すその他の情報のみを含めてはならない (MUST NOT)。 ##### 7.1.2.7.5 Extended Validation 7.1.2.7.5 拡張認証（EV） 利用者証明書が拡張認証であるためには、拡張認証証明書の発行および管理に関するEV Guidelinesのその時点の最新バージョンで指定されている証明書プロファイルに準拠していなければならない (MUST)。 さらに、次のプロファイルを満たさなければならない (MUST)。 | **フィールド** | **要件** | | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `subject` | 拡張認証証明書の発行および管理に関するガイドラインのSection 7.1.4.2 を参照のこと。 | | `certificatePolicies` | 存在しなければならない (MUST)。ポリシー識別子として、`2.23.140.1.1`の [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) を使用しなければならない (MUST)。 参照 [Section 7.1.2.7.9](#71279-subscriber-certificate-certificate-policies). | | その他すべての拡張子 | [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) および EV 拡張認証証明書の発行と管理に関するガイドラインを参照のこと。 | さらに、`subject`属性には、「.」、「-」、「」(つまりスペース) 文字などのメタデータのみ/値が存在しない、不完全である、または該当しないことを示すその他の情報のみを含めてはならない (MUST NOT)。 ##### 7.1.2.7.6 Subscriber Certificate Extensions 7.1.2.7.6 利用者証明書の拡張 | **拡張** | **存在** | **Critical** | **説明** | | --------------------------------- | --------------- | ------------ | ------------------------------------------------------------------------------------ | | `authorityInformationAccess` | MUST | N | 参照 [Section 7.1.2.7.7](#71277-subscriber-certificate-authority-information-access) | | `authorityKeyIdentifier` | MUST | N | 参照 [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `certificatePolicies` | MUST | N | 参照 [Section 7.1.2.7.9](#71279-subscriber-certificate-certificate-policies) | | `extKeyUsage` | MUST | N | 参照 [Section 7.1.2.7.10](#712710-subscriber-certificate-extended-key-usage) | | `subjectAltName` | MUST | * | 参照 [Section 7.1.2.7.12](#712712-subscriber-certificate-subject-alternative-name) | | `nameConstraints` | MUST NOT | - | - | | `keyUsage` | SHOULD | Y | 参照 [Section 7.1.2.7.11](#712711-subscriber-certificate-key-usage) | | `basicConstraints` | MAY | Y | 参照 [Section 7.1.2.7.8](#71278-subscriber-certificate-basic-constraints) | | `crlDistributionPoints` | * | N | 参照 [Section 7.1.2.11.2](#712112-crl-distribution-points) | | Signed Certificate Timestamp List | MAY | N | 参照 [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | `subjectKeyIdentifier` | NOT RECOMMENDED | N | 参照 [Section 7.1.2.11.4](#712114-subject-key-identifier) | | 他のすべての拡張 | NOT RECOMMENDED | - | 参照 [Section 7.1.2.11.5](#712115-other-extensions) | **注意**: - `subjectAltName` 拡張を Critical としてマークするかどうかは、[Section 7.1.2.7.12](#712712-subscriber-certificate-subject-alternative-name) で詳述されているように、証明書の `subject` フィールドの内容によって異なる。 - CRL配布ポイント拡張が存在しなければならないかどうかは、1) 証明書に id-ad-ocsp accessMethod を持つ authorityInformationAccess 拡張が含まれているかどうかおよび 2) [Section 7.1.2.11.2](#712112-crl-distribution-points) で詳述されている証明書の有効期間によって決まる。 ##### 7.1.2.7.7 Subscriber Certificate Authority Information Access 7.1.2.7.7 利用者証明書の権限情報アクセス `AuthorityInfoAccessSyntax` には、1 つ以上の `AccessDescription` が含まれていなければならない (MUST)。各 `AccessDescription` には、以下に詳述するように、許可された `accessMethod` のみが含まれていなければならず (MUST)、各 `accessLocation` は、指定された `GeneralName` タイプとしてエンコードされていなければならない (MUST)。 `AuthorityInfoAccessSyntax` には、その `accessMethod` に対して許可されている場合、同じ `accessMethod` を持つ複数の `AccessDescription` を含めることができる (MAY)。同じ `accessMethod` を持つ複数の `AccessDescription` が存在する場合、各 `accessLocation` は一意でなければならず (MUST)、各 `AccessDescription` はその `accessMethod` に対して優先順位に従って順序付けされなければならず (MUST)、最も優先される `accessLocation` が最初の `AccessDescription` になる。前の要件が満たされている限り、異なる `accessMethod` を含む `AccessDescription` には順序付けの要件はない。 | **アクセス方法** | **OID** | **アクセス場所** | **存在** | **最大** | **説明** | | ----------------- | ------------------ | --------------------------- | -------- | -------- | ------------------------------------ | | `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | MAY | \* | 発行CAのOCSPレスポンダーのHTTP URL | | `id-ad-caIssuers` | 1.3.6.1.5.5.7.48.2 | `uniformResourceIdentifier` | SHOULD | \* | 発行CAの証明書のHTTP URL | | その他の値 | - | - | MUST NOT | - | 他の `accessMethod` は使用できない。 | ##### 7.1.2.7.8 Subscriber Certificate Basic Constraints 7.1.2.7.8 利用者証明書の基本制約 | **フィールド** | **説明** | | ------------------- | ------------------------------- | | `cA` | FALSE でなければならない (MUST) | | `pathLenConstraint` | 存在してはならない (MUST NOT) | ##### 7.1.2.7.9 Subscriber Certificate Certificate Policies 7.1.2.7.9 利用者証明書の証明書ポリシー 存在する場合、証明書ポリシー拡張には少なくとも 1 つの `PolicyInformation` が含まれていなければならない (MUST)。各 `PolicyInformation` は次のプロファイルと一致しなければならない (MUST)。 | **フィールド** | **存在** | **内容** | | ------------------------------------------------------------------------------------------- | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `policyIdentifier` | MUST | 次のいずれかのポリシー識別子 | | - A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST | 指定された利用者証明書タイプ（[Section 7.1.2.7.1](#71271-subscriber-certificate-types) を参照）に関連付けられた予約済み証明書ポリシー識別子（[Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers) を参照） | | - `anyPolicy` | MUST NOT | `anyPolicy` ポリシー識別子は存在してはならない (MUST NOT)。 | | - 他の識別子 | MAY | 存在する場合は、CAのCP/CPSで定義および文書化しなければならない (MUST)。 | | `policyQualifiers` | NOT RECOMMENDED | 存在する場合は、以下の表の許可された　`policyQualifiers`　のみを含めなければならない (MUST)。 | このプロファイルでは、証明書ポリシー拡張内の最初の `PolicyInformation` 値に予約済み証明書ポリシー識別子 ([7.1.6.1](#7161-reserved-certificate-policy-identifiers) を参照) [^first_policy_note] を含めることを推奨する (RECOMMEND)。`PolicyInformation` 値の順序に関係なく、証明書ポリシー拡張には予約済み証明書ポリシー識別子が 1 つだけ含まれていなければならない (MUST)。 表: 許可された `policyQualifiers` | **修飾子 ID** | **存在** | **フィールドタイプ** | **内容** | | ------------------------------------ | -------- | -------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | 発行CAのCP、CPS、検証者契約、または発行CAによって提供されるオンラインポリシー情報へのその他のポインターの HTTPまたはHTTPS URL | | 他の修飾子 | MUST NOT | - | - | [^first_policy_note]: RFC 5280 では、`PolicyInformation` が任意の順序で出現することを許可しているが、いくつかのクライアント実装では、特定のフィルターに一致する `policyIdentifier` を考慮するロジックが実装されている。そのため、予約済み証明書ポリシー識別子が最初の `PolicyInformation` であることを保証することで、相互運用性の問題のリスクが軽減される。 ##### 7.1.2.7.10 Subscriber Certificate Extended Key Usage 7.1.2.7.10 利用者証明書の拡張鍵使用法 | **鍵の目的** | **OID** | **存在** | | -------------------------- | ----------------------- | --------------- | | `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST | | `id-kp-clientAuth` | 1.3.6.1.5.5.7.3.2 | MAY | | `id-kp-codeSigning` | 1.3.6.1.5.5.7.3.3 | MUST NOT | | `id-kp-emailProtection` | 1.3.6.1.5.5.7.3.4 | MUST NOT | | `id-kp-timeStamping` | 1.3.6.1.5.5.7.3.8 | MUST NOT | | `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST NOT | | `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT | | 事前証明書サイニング証明書 | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT | | その他の値 | - | NOT RECOMMENDED | ##### 7.1.2.7.11 Subscriber Certificate Key Usage 7.1.2.7.11 利用者証明書の鍵使用法 許容される鍵使用法の値は、証明書の `subjectPublicKeyInfo` がRSA公開鍵を識別するか、ECC公開鍵を識別するかによって異なる。CAは、鍵使用法が証明書の公開鍵に適切であることを確認しなければならない (MUST)。 表: RSA公開鍵の鍵使用法 | **鍵使用法** | **許可** | **必要度** | | ------------------ | -------- | --------------- | | `digitalSignature` | Y | SHOULD | | `nonRepudiation` | N | -- | | `keyEncipherment` | Y | MAY | | `dataEncipherment` | Y | NOT RECOMMENDED | | `keyAgreement` | N | -- | | `keyCertSign` | N | -- | | `cRLSign` | N | -- | | `encipherOnly` | N | -- | | `decipherOnly` | N | -- | **注意**: RSA公開鍵には、少なくとも 1 つの鍵使用法を設定しなければならない (MUST)。`digitalSignature` ビットは、TLS 1.3 などの最新のプロトコルや安全な暗号スイートで使用するために必須だが、`keyEncipherment` ビットは、安全でない暗号スイートを使用する場合に、TLS 1.2 などの古いプロトコルをサポートするために使用される場合がある (MAY)。利用者は、このようなレガシープロトコルによるリスクを制限するために鍵の分離を確実にすることを望む場合があり (MAY)、そのためCAは、`keyEncipherment` ビットのみを使用する利用者証明書を発行する場合がある (MAY)。ほとんどの利用者にとって、`digitalSignature` ビットで十分だが、同じアルゴリズムで安全でない暗号スイートと安全な暗号スイートを混在させたい加入者は、同じ証明書内で `digitalSignature` と `keyEncipherment` の両方を使用することを選択できるが、これは推奨されない (NOT RECOMMENDED)。 `dataEncipherment` ビットは現在許可されているが、保留中の禁止事項であるため、設定することは推奨されない (NOT RECOMMENDED) ( 表: ECC公開鍵の鍵使用法 | **鍵使用法** | **許可** | **必要度** | | ------------------ | -------- | --------------- | | `digitalSignature` | Y | MUST | | `nonRepudiation` | N | -- | | `keyEncipherment` | N | -- | | `dataEncipherment` | N | -- | | `keyAgreement` | Y | NOT RECOMMENDED | | `keyCertSign` | N | -- | | `cRLSign` | N | -- | | `encipherOnly` | N | -- | | `decipherOnly` | N | -- | **注意**: `keyAgreement` ビットは現在許可されているが、保留中の禁止事項であるため、設定することは推奨されない (NOT RECOMMENDED) ( ##### 7.1.2.7.12 Subscriber Certificate Subject Alternative Name 7.1.2.7.12 利用者証明書の主体者識別名代替名 利用者証明書の場合、主体者識別代替名が存在し、少なくとも 1 つの `dNSName` または `iPAddress` `GeneralName` が含まれていなければならない (MUST)。許可されるフィールドとその検証要件に関する詳細な要件については、以下を参照のこと。 証明書の`subject` フィールドが空のシーケンスである場合、この拡張は、[RFC 5280, Section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6) で指定されているように、クリティカルとしてマークしなければならない (MUST)。それ以外の場合、この拡張はクリティカルとしてマークしてはならない (MUST NOT)。 表: `subjectAltName` 拡張内の `GeneralName` | **名前タイプ** | **許可** | **認証** | | --------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `otherName` | N | - | | `rfc822Name` | N | - | | `dNSName` | Y | エントリーには、CAが [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) に従って検証したFQDNまたはワイルドカード ドメイン名のいずれかが含まれていなければならない (MUST)。ワイルドカードドメイン名は、[Section 3.2.2.6](#3226-wildcard-domain-validation) との整合性について検証されていなければならない (MUST)。エントリーには内部名を含めることはできない (MUST NOT)。エントリーに含まれるFQDNまたはワイルドカードドメイン名のFQDN部分は、U+002E ピリオド (「.」) 文字で結合された P ラベルまたは非予約 LDH ラベルのみで構成されていなければならない (MUST)。インターネットドメインネームシステムのルートゾーンを表す長さゼロのドメインラベルを含めてはならない (MUST NOT) (例: 「example.com」は「example.com」としてエンコードされなければならず (MUST)、「example.com.」としてエンコードすることはできない (MUST NOT))。 | | `x400Address` | N | - | | `directoryName` | N | - | | `ediPartyName` | N | - | | `uniformResourceIdentifier` | N | - | | `iPAddress` | N | セコムトラストシステムズは、IPv4 または IPv6 アドレスを含む TLS サーバー利用者 (エンドエンティティ) 証明書を発行しない。 | | `registeredID` | N | - | **注意**: RFC 5280 からの明示的な例外として、P ラベルは IDNA 2003 に準拠しないことが許可されている。[Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) により、さまざまな IDNA 標準に対するその他の改善点とともに、Unicode 文字レパートリーの新しいバージョンをサポートするために、IDNA 2003 に準拠しない P ラベルを含めることが許可される。 #### 7.1.2.8 OCSP Responder Certificate Profile 7.1.2.8 OCSPレスポンダー証明書プロファイル 発行CAがOCSP応答に直接署名しない場合は、[RFC 6960](https://tools.ietf.org/html/RFC6960#section-4.2.2.2) で定義されているOCSP認定レスポンダーを使用することができる (MAY)。レスポンダーの発行CAは、応答を提供する証明書の発行CAと同じでなければならない (MUST)。 | **フィールド** | **説明** | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------ | | `tbsCertificate` | | | - `version` | v3(2) | | - `serialNumber` | CSPRNGからの出力の少なくとも64ビットを含む、ゼロ (0) より大きく 2¹⁵⁹ 未満の非連続な数値でなければならない (MUST)。 | | - `signature` | 参照 [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | - `issuer` | 発行CAの`subject` フィールドとバイト単位で同一でなければならない (MUST)。[Section 7.1.4.1](#7141-name-encoding) を参照。 | | - `validity` | 参照 [Section 7.1.2.8.1](#71281-ocsp-responder-validity) | | - `subject` | 参照 [Section 7.1.2.10.2](#712102-ca-certificate-naming) | | - `subjectPublicKeyInfo` | 参照 [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | - `issuerUniqueID` | 存在してはならない (MUST NOT) | | - `subjectUniqueID` | 存在してはならない (MUST NOT) | | - `extensions` | 参照 [Section 7.1.2.8.2](#71282-ocsp-responder-extensions) | | `signatureAlgorithm` | エンコードされた値は、`tbsCertificate.signature` とバイト単位で同一でなければならない (MUST)。 | | `signature` | - | ##### 7.1.2.8.1 OCSP Responder Validity 7.1.2.8.1 OCSPレスポンダーの有効期限 | **フィールド** | **最小** | **最大** | | -------------- | ------------- | -------- | | `notBefore` | 署名日の1日前 | 署名日 | | `notAfter` | 署名日 | 未指定 | ##### 7.1.2.8.2 OCSP Responder Extensions 7.1.2.8.2 OCSP レスポンダーの拡張 | **拡張** | **存在** | **Critical** | **説明** | | -------------------------------------- | --------------- | ------------ | ---------------------------------------------------------------------------- | | `authorityKeyIdentifier` | MUST | N | 参照 [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `extKeyUsage` | MUST | - | 参照 [Section 7.1.2.8.5](#71285-ocsp-responder-extended-key-usage) | | `id-pkix-ocsp-nocheck` | MUST | N | 参照 [Section 7.1.2.8.6](#71286-ocsp-responder-id-pkix-ocsp-nocheck) | | `keyUsage` | MUST | Y | 参照 [Section 7.1.2.8.7](#71287-ocsp-responder-key-usage) | | `basicConstraints` | MAY | Y | 参照 [Section 7.1.2.8.4](#71284-ocsp-responder-basic-constraints) | | `nameConstraints` | MUST NOT | - | - | | `subjectAltName` | MUST NOT | - | - | | `subjectKeyIdentifier` | SHOULD | N | 参照 [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `authorityInformationAccess` | NOT RECOMMENDED | N | 参照 [Section 7.1.2.8.3](#71283-ocsp-responder-authority-information-access) | | `certificatePolicies` | MUST NOT | N | 参照 [Section 7.1.2.8.8](#71288-ocsp-responder-certificate-policies) | | `crlDistributionPoints` | MUST NOT | N | 参照 [Section 7.1.2.11.2](#712112-crl-distribution-points) | | 署名された証明書のタイムスタンプリスト | MAY | N | 参照 [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | その他の拡張 | NOT RECOMMENDED | - | 参照 [Section 7.1.2.11.5](#712115-other-extensions) | ##### 7.1.2.8.3 OCSP Responder Authority Information Access 7.1.2.8.3 OCSPレスポンダーの機関情報アクセス OCSPレスポンダー証明書の場合、検証者が既に必要な情報を所有しているはずなので、この拡張は推奨されない (NOT RECOMMENDED)。指定されたレスポンダー証明書を検証するには、検証者が発行CAの証明書にアクセスしなければならず、`id-ad-caIssuers` を提供する必要はない。同様に、OCSPレスポンダー証明書には `id-pkix-ocsp-nocheck` 拡張を含める必要があるため、このような応答は検証者によってチェックされないため、`id-ad-ocsp` を提供する必要はない。 存在する場合、`AuthorityInfoAccessSyntax` には 1 つ以上の `AccessDescription` が含まれていなければならない (MUST)。各 `AccessDescription` には、以下に詳述するように、許可された `accessMethod` のみが含まれていなければならず (MUST)、各 `AuthorityInfoAccessSyntax` には、必要なすべての `AccessDescription` が含まれていなければならない (MUST)。 | **アクセス方法** | **OID** | **アクセス場所** | **存在** | **最大** | **説明** | | ---------------- | ------------------ | --------------------------- | --------------- | -------- | ------------------------------------ | | `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | NOT RECOMMENDED | \* | 発行CAのOCSPレスポンダーのHTTP URL | | その他の値 | - | - | MUST NOT | - | 他の `accessMethod` は使用できない。 | ##### 7.1.2.8.4 OCSP Responder Basic Constraints 7.1.2.8.4 OCSPレスポンダー基本制約 OCSPレスポンダー証明書はCA証明書であってはならない (MUST NOT)。発行CAは、`basicConstraints` 拡張を省略するか、`cA` ブール値を FALSE に設定する `basicConstraints` 拡張を含めるかのいずれかの方法でこれを示す。 | **フィールド** | **説明** | | ------------------- | ------------------------------- | | `cA` | FALSE でなければならない (MUST) | | `pathLenConstraint` | 存在してはならない (MUST NOT) | **注意**: OPTIONAL フィールド内の DEFAULT 値のエンコードに関する DER エンコードルールにより、`cA` ブール値を FALSE に設定する `basicConstraints` 拡張には、空の ASN.1 `SEQUENCE` 値のエンコードされた表現である 16 進エンコードされたバイト `3000` と同じ `extnValue` `OCTET STRING` が必要になる (MUST)。 ##### 7.1.2.8.5 OCSP Responder Extended Key Usage 7.1.2.8.5 OCSPレスポンダー拡張鍵使用法 | **鍵の目的** | **OID** | **存在** | | ------------------- | ----------------- | -------- | | `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST | | その他の値 | - | MUST NOT | ##### 7.1.2.8.6 OCSP Responder id-pkix-ocsp-nocheck 7.1.2.8.6 OCSPレスポンダー id-pkix-ocsp-nocheck CAには、`id-pkix-ocsp-nocheck` 拡張 (OID: 1.3.6.1.5.5.7.48.1.5) が含まれていなければならない (MUST)。 この拡張には、[RFC 6960, Section 4.2.2.2.1](https://tools.ietf.org/html/RFC6960#section-4.2.2.2.1) で指定されているように、ASN.1 NULL 値のエンコードされた表現である 16 進エンコードされたバイト `0500` と同じ `extnValue` `OCTET STRING` が含まれていなければならない (MUST)。 ##### 7.1.2.8.7 OCSP Responder Key Usage 7.1.2.8.7 OCSPレスポンダー鍵の使用法 | **鍵の使用法** | **許可** | **必要度** | | ------------------ | -------- | ---------- | | `digitalSignature` | Y | Y | | `nonRepudiation` | N | -- | | `keyEncipherment` | N | -- | | `dataEncipherment` | N | -- | | `keyAgreement` | N | -- | | `keyCertSign` | N | -- | | `cRLSign` | N | -- | | `encipherOnly` | N | -- | | `decipherOnly` | N | -- | ##### 7.1.2.8.8 OCSP Responder Certificate Policies 7.1.2.8.8 OCSPレスポンダー証明書ポリシー セコムトラストシステムズはこの拡張を含まない。 #### 7.1.2.9 Precertificate Profile 7.1.2.9 事前証明書プロファイル 事前証明書は、[RFC 6962](https://tools.ietf.org/doc/html/rfc6962) で定義されているように、証明書の透明性ログに送信できる署名されたデータ構造である。事前証明書は、`extensions`フィールドの OID が `1.3.6.1.4.1.11129.2.4.3` である特別な重大なポイズン拡張を除き、構造的には証明書と同一である。この拡張により、事前証明書は [RFC 5280](https://tools.ietf.org/doc/html/rfc5280) に準拠するクライアントによって証明書として受け入れられないことが保証される。署名された事前証明書の存在は、対応する証明書も存在する証拠として扱うことができる。署名は、CAによるそのような証明書を発行できるという拘束力のあるコミットメントを表すためである。 事前証明書は、CAが証明書の発行を決定した後、証明書に実際に署名する前に作成される。CAは、証明書の透明性ログに送信する目的で、証明書に対応する事前証明書を作成して署名することができる (MAY)。CAは、返された署名済み証明書のタイムスタンプを使用して、証明書に署名する前に、[Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) で定義され、関連するプロファイルで許可されているように、署名済み証明書のタイムスタンプリストを追加して、証明書の`extensions`フィールドを変更することができる (MAY)。 事前証明書が署名されると、検証者はこれを、対応する証明書を発行する意図、またはより一般的には、対応する証明書が存在するというCAからの拘束力のあるコミットメントとして扱うことが許可される。証明書は、[RFC 6962, Section 3.2](https://tools.ietf.org/doc/html/rfc6962#section-3.2) で定義されたプロセスによって変換された `tbsCertificate` コンテンツの値に基づいて、事前証明書に対応していると見なされる。 このプロファイルは、証明書から事前証明書を作成するために許可される変換について説明している。CAは、対応する証明書を発行する意思がない限り、すでに発行したかどうかに関係なく、事前証明書を発行してはならない (MUST NOT)。同様に、CAは、対応する証明書が Baseline Requirements に準拠しない限り、CAが対応する証明書に署名したかどうかに関係なく、事前証明書を発行してはならない (MUST NOT)。 事前証明書は、発行CAによって直接発行されるか、または [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile) で定義されている技術的に制約のある事前証明書サイニングCAによって発行される。事前証明書サイニングCAによって発行される場合、事前証明書ポイズンおよび署名済み証明書タイムスタンプリスト拡張に加えて、事前証明書`issuer`フィールドおよび (存在する場合は) `authorityKeyIdentifier` 拡張が、以下に説明するように証明書と異なる場合がある。 表: 事前証明書が発行CAによって直接発行される場合 | **フィールド** | **説明** | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | `tbsCertificate` | | | - `version` | エンコードされた値は、証明書の `version` フィールドとバイト単位で同一でなければならない (MUST)。 | | - `serialNumber` | エンコードされた値は、証明書の `serialNumber` フィールドとバイト単位で同一でなければならない (MUST)。 | | - `signature` | エンコードされた値は、証明書の `signature` フィールドとバイト単位で同一でなければならない (MUST)。 | | - `issuer` | エンコードされた値は、証明書の `issuer` フィールドとバイト単位で同一でなければならない (MUST)。 | | - `validity` | エンコードされた値は、証明書の `validity` フィールドとバイト単位で同一でなければならない (MUST)。 | | - `subject` | エンコードされた値は、証明書の `subject` フィールドとバイト単位で同一でなければならない (MUST)。 | | - `subjectPublicKeyInfo` | エンコードされた値は、証明書の `subjectPublicKeyInfo` フィールドとバイト単位で同一でなければならない (MUST)。 | | - `issuerUniqueID` | エンコードされた値は、証明書の `issuerUniqueID`フィールドとバイト単位で同一でなければならず (MUST)、もしくは証明書で省略されている場合は省略される。 | | - `subjectUniqueID` | エンコードされた値は、証明書の `subjectUniqueID` フィールドとバイト単位で同一でなければならず (MUST)、もしくは証明書で省略されている場合は省略される。 | | - `extensions` | 参照 [Section 7.1.2.9.1](#71291-precertificate-profile-extensions---directly-issued) | | `signatureAlgorithm` | エンコードされた値は、`tbsCertificate.signature` とバイト単位で同一でなければならない (MUST)。 | | `signature` | - | 表: 事前証明書が発行CAに代わって事前証明書サイニングCAによって発行される場合 | **フィールド** | **説明** | | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `tbsCertificate` | | | `version` | エンコードされた値は、証明書の `version` フィールドとバイト単位で同一でなければならない (MUST)。 | | - `serialNumber` | エンコードされた値は、証明書の `serialNumber` フィールドとバイト単位で同一でなければならない (MUST)。 | | - `signature` | エンコードされた値は、証明書の `signature` フィールドとバイト単位で同一でなければならない (MUST)。 | | - `issuer` | エンコードされた値は、[Precertificate Signing CA Certificate](#7124-technically-constrained-precertificate-signing-ca-certificate-profile) の `subject` フィールドとバイト単位で同一でなければならない (MUST)。 | | - `validity` | エンコードされた値は、証明書の `validity` フィールドとバイト単位で同一でなければならない (MUST)。 | | - `subject` | エンコードされた値は、証明書の subjectPublicKeyInfo フィールドとバイト単位で同一でなければなりません。エンコードされた値は、証明書の `subject` フィールドとバイト単位で同一でなければならない (MUST)。 | | - `subjectPublicKeyInfo` | エンコードされた値は、証明書の `subjectPublicKeyInfo` フィールドとバイト単位で同一でなければならない (MUST)。 | | - `issuerUniqueID` | エンコードされた値は、証明書の `issuerUniqueID`フィールドとバイト単位で同一でなければならず (MUST)、もしくは証明書で省略されている場合は省略される。 | | - `subjectUniqueID` | エンコードされた値は、証明書の `subjectUniqueID` フィールドとバイト単位で同一でなければならず (MUST)、もしくは証明書で省略されている場合は省略される。 | | - `extensions` | 参照 [Section 7.1.2.9.2](#71292-precertificate-profile-extensions---precertificate-ca-issued) | | `signatureAlgorithm` | エンコードされた値は、`tbsCertificate.signature` とバイト単位で同一でなければならない (MUST)。 | | `signature` | - | **注意**: このプロファイルでは、事前証明書の `serialNumber` フィールドが対応する証明書の `serialNumber` フィールドと同一でなければならない (MUST)。[RFC 5280, Section 4.1.2.2](https://tools.ietf.org/doc/html/rfc5280#section-4.1.2.2) では、証明書の `serialNumber` が一意である必要がある。このドキュメントの目的上、事前証明書はその要件に従う「証明書」とは見なされないため、対応する証明書と同じ `serialNumber` を持つことができる。ただし、2 つの事前証明書が同じ証明書に対応していない限り、同じ `serialNumber` を共有することは許可されない。そうしないと、同じ `serialNumber` を共有する 2 つの対応する証明書があることを示すことになるからである。 ##### 7.1.2.9.1 Precertificate Profile Extensions - Directly Issued 7.1.2.9.1 事前証明書プロファイル拡張 - 直接発行 これらの拡張は、[Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile) で定義されているように、事前証明書サイニングCA証明書からではなく、CAから直接発行された事前証明書のコンテキストに適用される。 | **拡張** | **存在** | **Critical** | **説明** | | ------------------------------------------------- | -------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------- | | 事前証明書ポイズン (OID: 1.3.6.1.4.1.11129.2.4.3) | MUST | Y | 参照 [Section 7.1.2.9.3](#71293-precertificate-poison) | | 署名された証明書のタイムスタンプリスト | MUST NOT | - | | | その他の拡張 | \* | \* | 他のすべての拡張の順序、重要度およびエンコードされた値は、証明書の`extensions`フィールドとバイト単位で同一でなければならない (MUST)。 | **注意**: この要件は、事前証明書から事前証明書ポイズン拡張が削除され、署名済み証明書タイムスタンプリストが証明書から削除された場合、`extensions` フィールドの内容は証明書とバイト単位で同一でなければならない (MUST) ことを示している。 ##### 7.1.2.9.2 Precertificate Profile Extensions - Precertificate CA Issued 7.1.2.9.2 事前証明書プロファイル拡張 - CA発行の事前証明書 これらの拡張は、[Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile) で定義されているように、事前証明書サイニングCA証明書からの事前証明書のコンテキストで適用される。このような事前証明書の場合、証明書に`authorityKeyIdentifier` が存在する場合は、[RFC 6962, Section 3.2](https://tools.ietf.org/doc/html/rfc6962#section-3.2) で説明されているように、事前証明書で変更される。 | **拡張** | **存在** | **Critical** | **説明** | | ------------------------------------------------- | -------- | ------------ | --------------------------------------------------------------------------------------------------------------------------------------- | | 事前証明書ポイズン (OID: 1.3.6.1.4.1.11129.2.4.3) | MUST | Y | 参照 [Section 7.1.2.9.3](#71293-precertificate-poison) | | `authorityKeyIdentifier` | \* | \* | 参照 [Section 7.1.2.9.4](#71294-precertificate-authority-key-identifier) | | 署名された証明書のタイムスタンプリスト | MUST NOT | - | | | その他の拡張 | \* | \* | 他のすべての拡張の順序、重要度およびエンコードされた値は、証明書の `extensions` フィールドとバイト単位で同一でなければならない (MUST)。 | ##### 7.1.2.9.3 Precertificate Poison 7.1.2.9.3 事前証明書ポイズン 事前証明書には、事前証明書ポイズン拡張 (OID: 1.3.6.1.4.1.11129.2.4.3) が含まれていなければならない (MUST)。 この拡張には、[RFC 6962, Section 3.1](https://tools.ietf.org/doc/html/rfc6962#section-3.1) で指定されているように、ASN.1 NULL 値のエンコードされた表現である 16 進エンコードされたバイト `0500` と同じ `extnValue` `OCTET STRING` が含まれていなければならない (MUST)。 ##### 7.1.2.9.4 Precertificate Authority Key Identifier 7.1.2.9.4 事前証明書局鍵識別子 事前証明書サイニングCAによって発行された事前証明書の場合、`authorityKeyIdentifier` 拡張の内容は次のいずれかでなければならない。 1. 以下のプロファイルで定義されているとおりである必要がある (SHOULD) 2. 対応する証明書の `authorityKeyIdentifier` 拡張の内容とバイト単位で同一である場合がある (MAY)。 | **フィールド** | **説明** | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `keyIdentifier` | 存在しなければならない (MUST)。[Precertificate Signing CA Certificate](#7124-technically-constrained-precertificate-signing-ca-certificate-profile) の `subjectKeyIdentifier` フィールドと同一でなければならない (MUST)。 | | `authorityCertIssuer` | 存在してはならない (MUST NOT) | | `authorityCertSerialNumber` | 存在してはならない (MUST NOT) | **注意**: [RFC 6962](https://datatracker.ietf.org/doc/html/rfc6962) では、事前証明書に存在する `authorityKeyIdentifier` が、事前証明書サイニングCAの`authorityKeyIdentifier` 拡張の値 (つまり、実際の発行者証明書の `keyIdentifier` を反映) を含むように変換され、クライアントによって検証されたときに対応する証明書と一致する方法について説明している。Baseline Requirements では、チェーン内のすべての証明書の `subjectKeyIdentifier` と`authorityKeyIdentifier` の一貫性を確保するために、事前証明書サイニングCAの `keyIdentifier` をそのCAが発行する事前証明書で使用することを推奨している (RECOMMEND)。[RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280) ではこのような一貫性は厳密には要求されていないが、多くのクライアント実装では証明書に対してこのような一貫性が強制されており、これにより証明書の透明性ログがこのようなチェックを誤って実装することによるリスクを回避している。 #### 7.1.2.10 Common CA Fields 7.1.2.10 共通CAフィールド このSectionには、複数のCA証明書プロファイルに共通するいくつかのフィールドが含まれている。ただし、これらのフィールドはすべてのCA証明書プロファイルに共通であるとは限らない。証明書を発行する前に、CAは、各フィールドの内容を含む証明書の内容が、[Section 7.1.2](#712-certificate-content-and-extensions) に記載されている少なくとも 1 つの証明書プロファイルのすべての要件に全体的に準拠していることを確認しなければならない (MUST)。 ##### 7.1.2.10.1 CA Certificate Validity 7.1.2.10.1 CA証明書の有効期限 | **フィールド** | **最小** | **最大** | | -------------- | ------------- | -------- | | `notBefore` | 署名日の1日前 | 署名日 | | `notAfter` | 署名日 | 未指定 | ##### 7.1.2.10.2 CA Certificate Naming 7.1.2.10.2 CA証明書の識別名 すべての `subject` 名は [Section 7.1.4](#714-name-forms) で指定されているとおりにエンコードされなければならない (MUST)。 次の表は、`AttributeTypeAndValue` の `type` フィールド内に表示される可能性のある許容される `AttributeType` と、`value` フィールド内で許可される内容の詳細を示している。 | **属性名** | **存在** | **値** | **検証** | | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------ | | `countryName` | MUST | CAの事業所が所在する国の 2 文字の ISO 3166-1 国コード。 | [Section 3.2.2.3](#3223-verification-of-country) | | `stateOrProvinceName` | MAY | 存在する場合は、CAの州または県の情報。 | [Section 3.2.2.1](#3221-identity) | | `localityName` | MAY | 存在する場合は、CAの所在地。 | [Section 3.2.2.1](#3221-identity) | | `postalCode` | MUST NOT | セコムトラストシステムズはこの属性名を含む証明書は発行しない。 | [Section 3.2.2.1](#3221-identity) | | `streetAddress` | MUST NOT | セコムトラストシステムズはこの属性名を含む証明書は発行しない | [Section 3.2.2.1](#3221-identity) | | `organizationName` | MUST | CAの名前またはDBA。CAは、一般的なバリエーションや略語など、検証済み名称とわずかに異なる情報をこのフィールドに含めることができる (MAY)。ただし、CAがその違いを文書化し、使用される略語がローカルで受け入れられている略語である場合に限る。たとえば、公式記録に「Company Name Incorporated」と記載されている場合、CAは「Company Name Inc.」または「Company Name」を使用できる (MAY)。 | [Section 3.2.2.2](#3222-dbatradename) | | `organizationalUnitName` | この属性は、[Section 7.1.2.1](#7121-root-ca-certificate-profile) で定義されているルートCA証明書、[Section 7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile) で定義されているTLS下位CA証明書、または [Section 7.1.2.6](#7126-tls-subordinate-ca-certificate-profile) で定義されている技術的に制約のあるTLS下位CA証明書に含めてはならない (MUST NOT)。この属性は、他の種類のCA証明書に含めるべきではない (SHOULD NOT)。 | - | - | | `commonName` | MUST | 内容は証明書の識別子である必要があり (SHOULD)、証明書の名前は発行証明書によって発行されたすべての証明書間で一意になる。 | | | その他の属性 | NOT RECOMMENDED | - | 参照 [Section 7.1.4.4](#7144-other-subject-attributes) | ##### 7.1.2.10.3 CA Certificate Authority Information Access 7.1.2.10.3 CA証明書の機関情報アクセス 存在する場合、`AuthorityInfoAccessSyntax` には 1 つ以上の `AccessDescription` が含まれていなければならない (MUST)。各 `AccessDescription` には、以下に詳述するように、許可された `accessMethod` のみが含まれていなければならず (MUST)、各 `accessLocation` は指定された `GeneralName` タイプとしてエンコードされていなければならない (MUST)。 `AuthorityInfoAccessSyntax` には、その `accessMethod` に対して許可されている場合、同じ `accessMethod` を持つ複数の `AccessDescription` を含めることができる(MAY)。同じ `AccessDescription` を持つ複数の `AccessDescription` が存在する場合、各 `accessLocation` は一意でなければならず (MUST)、各 `AccessDescription` はその `accessMethod` に対して優先順位に従って順序付けされなければならず (MUST)、最も優先される `accessLocation` が最初の `AccessDescription` になる。前の要件が満たされている限り、異なる `accessMethod` を含む `AccessDescription` には順序付けの要件はない。 | **アクセス方法** | **OID** | **アクセス場所** | **存在** | **最大** | **説明** | | ----------------- | ------------------ | --------------------------- | -------- | -------- | ------------------------------------ | | `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | MAY | \* | 発行CAのOCSPレスポンダーのHTTP URL | | `id-ad-caIssuers` | 1.3.6.1.5.5.7.48.2 | `uniformResourceIdentifier` | MAY | \* | 発行CAの証明書のHTTP URL | | その他の値 | - | - | MUST NOT | - | 他の `accessMethod` は使用できない。 | ##### 7.1.2.10.4 CA Certificate Basic Constraints 7.1.2.10.4 CA証明書の基本制約 | **フィールド** | **説明** | | ------------------- | ----------------------------------- | | `cA` | TRUEに設定しなければならない (MUST) | | `pathLenConstraint` | 存在する場合がある (MAY) | ##### 7.1.2.10.5 CA Certificate Certificate Policies 7.1.2.10.5 CA証明書の証明書ポリシー 存在する場合、証明書ポリシー拡張機能には少なくとも 1 つの `PolicyInformation` が含まれていなければならない (MUST)。各 `PolicyInformation` は次のプロファイルと一致しなければならない (MUST)。 表: ポリシー制約なし（関連CA） | **フィールド** | **存在** | **内容** | | ------------------ | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `policyIdentifier` | MUST | 発行CAがポリシー制約がないことを表す場合および下位CAが発行CAの関連会社である場合、発行CAは `anyPolicy` ポリシー識別子を使用できる (MAY)。これは、唯一の `PolicyInformation` 値でなければならない (MUST)。 | | - `anyPolicy` | MUST | | | `policyQualifiers` | NOT RECOMMENDED | 存在する場合は、以下の表の許可された`policyQualifiers` のみを含めなければならない (MUST)。 | 表: ポリシー制約あり | **フィールド** | **存在** | **内容** | | ----------------------------------------------------------------------------------------- | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `policyIdentifier` | MUST | 次のいずれかのポリシー識別子 | | A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST | CAには、この証明書によって直接または間接的に発行された特定の利用者証明書タイプ ([Section 7.1.2.7.1](#71271-subscriber-certificate-types) を参照) に関連付けられた予約済み証明書ポリシー識別子 ([Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers) を参照) が 1 つだけ含まれていなければならない (MUST)。 | | `anyPolicy` | MUST NOT | anyPolicy ポリシー識別子は存在してはならない(MUST NOT)。 | | その他の識別子 | MAY | 存在する場合、CAによって定義され、CAのCP/CPSに文書化されていなければならない (MUST)。 | | `policyQualifiers` | NOT RECOMMENDED | 存在する場合は、以下の表の許可された`policyQualifiers`のみを含めなければならない (MUST)。 | ポリシー制約プロファイルでは、証明書ポリシー拡張内の最初の`PolicyInformation`値に予約済み証明書ポリシー識別子 ([7.1.6.1](#7161-reserved-certificate-policy-identifiers))[^first_policy_note] を含めることが推奨される (RECOMMEND)。`PolicyInformation`値の順序に関係なく、証明書ポリシー拡張には予約済み証明書ポリシー識別子が 1 つだけ含まれていなければならない (MUST)。 **注意**: policyQualifiers は、この証明書プロファイルに基づいて発行されるどの証明書にも存在することは推奨されない (NOT RECOMMENDED)。この情報は、通常の検証者に何の価値も提供せずに証明書のサイズを増加させ、必要に応じて他の手段で取得できるからである。 `policyQualifiers` が許可され、`PolicyInformation` フィールド内に存在する場合、次のようにフォーマットされなければならない (MUST)。 表: 許可された `policyQualifiers` | **修飾子 ID** | **存在** | **フィールドタイプ** | **内容** | | ------------------------------------ | -------- | -------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | 発行CAのCP、CPS、検証者契約、または発行CAによって提供されるオンラインポリシー情報へのその他のポインターのHTTPまたはHTTPS URL | | その他の修飾子 | MUST NOT | - | - | ##### 7.1.2.10.6 CA Certificate Extended Key Usage 7.1.2.16 CA証明書の拡張鍵使用法 | **鍵の目的** | **OID** | **存在** | | ---------------------------------- | ----------------------- | --------------- | | `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST | | `id-kp-clientAuth` | 1.3.6.1.5.5.7.3.2 | MAY | | `id-kp-codeSigning` | 1.3.6.1.5.5.7.3.3 | MUST NOT | | `id-kp-emailProtection` | 1.3.6.1.5.5.7.3.4 | MUST NOT | | `id-kp-timeStamping` | 1.3.6.1.5.5.7.3.8 | MUST NOT | | `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST NOT | | `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT | | Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT | | その他の値 | - | NOT RECOMMENDED | ##### 7.1.2.10.7 CA Certificate Key Usage 7.1.2.10.7 CA証明書鍵の使用法 | **鍵使用法** | **許可** | **必要度** | | ------------------ | -------- | ---------------- | | `digitalSignature` | Y | N[^ocsp_signing] | | `nonRepudiation` | N | -- | | `keyEncipherment` | N | -- | | `dataEncipherment` | N | -- | | `keyAgreement` | N | -- | | `keyCertSign` | Y | Y | | `cRLSign` | Y | Y | | `encipherOnly` | N | -- | | `decipherOnly` | N | -- | [^ocsp_signing]: CA証明書が `digitalSignature` ビットを使用しない場合は、CA私有鍵をOCSP応答の署名に使用してはならない (MUST NOT)。詳細については、[Section 7.3](#73-ocsp-profile) を参照のこと。 ##### 7.1.2.10.8 CA Certificate Name Constraints 7.1.2.10.8 CA証明書の名前制約 存在する場合、名前制約拡張は次のようにエンコードされなければならない (MUST)。RFC 5280 からの明示的な例外として、この拡張はクリティカルとしてマークする必要がある(MAY)が、名前制約をサポートしない特定のレガシーアプリケーションとの互換性が必要な場合は、非クリティカルとしてマークすることができる (MAY)。 表: `nameConstraints` の要件 | **フィールド** | **説明** | | ------------------- | ------------------------------------------------------------ | | `permittedSubtrees` | | | - `GeneralSubtree` | `permittedSubtrees` 内に表示される `GeneralSubtree` の要件。 | | -- `base` | 次の表を参照。 | | -- `minimum` | 存在してはならない (MUST NOT) | | -- `maximum` | 存在してはならない (MUST NOT) | | `excludedSubtrees` | | | - `GeneralSubtree` | `permittedSubtrees` 内に表示される `GeneralSubtree` の要件。 | | -- `base` | 次の表を参照。 | | -- `minimum` | 存在してはならない (MUST NOT) | | -- `maximum` | 存在してはならない (MUST NOT) | 次の表には、`permittedSubtrees` または `excludedSubtrees` のいずれかの `GeneralSubtree` の `base` 内に表示される `GeneralName` の要件が含まれている。 表: `base` フィールドの `GeneralName` 要件 | **名前タイプ** | **存在** | **許可されたサブツリー** | **除外されたサブツリー** | | --------------- | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `dNSName` | MAY | CAは、申請者が `dNSName` を登録したか、またはドメイン登録者から登録者に代わって行動する権限を付与されていることを確認しなければならない (MUST)。[Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) を参照。 | `permittedSubtrees` に少なくとも 1 つの `dNSName` インスタンスが存在する場合、CAは除外する 1 つ以上の下位ドメインを示す場合がある (MAY)。 | | `iPAddress` | MUST NOT | セコムトラストシステムズは、IPv4 または IPv6 アドレスを含むTLSサーバー利用者 (エンドエンティティ) 証明書を発行しない。 | `permittedSubtrees` に少なくとも 1 つの `iPAddress` インスタンスが存在する場合、CAは除外する範囲の 1 つ以上のサブディビジョンを示す場合がある (MAY)。 | | `directoryName` | MAY | CAは、発行されるすべての証明書が名前フォーム ( [Section 7.1.4](#714-name-forms) を参照) を含む関連する証明書プロファイル ([Section 7.1.2](#712-certificate-content-and-extensions) を参照) に準拠するように、申請者/子会社の名前属性を確認しなければならない (MUST)。 | `excludedSubtrees` 内に値を含めることは推奨されない (NOT RECOMMENDED)。 | | `rfc822Name` | NOT RECOMMENDED | CAは、[RFC 5280, Section 4.2.1.10](https://tools.ietf.org/html/rfc5280#section-4.2.1.10) で指定されているように、メールボックス、特定のホスト、またはドメイン内の任意のアドレスに制限することができる (MAY)。メールボックスの各ホスト、ドメイン、またはドメイン部分 ([RFC 5280, Section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6) で指定されているように) について、CAは申請者がドメインを登録したこと、またはドメイン登録者から登録者に代わって行動することを承認されていることを確認しなければならない (MUST)。[Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) を参照。 | `permittedSubtrees` に少なくとも 1 つの `rfc822Name` インスタンスが存在する場合、CA は除外する 1 つ以上のメールボックス、ホスト、またはドメインを示すことができる (MAY)。`permittedSubtrees` に `rfc822Name` インスタンスが存在しない場合、CAはメールボックスが許可されていないことを示すために長さがゼロの `rfc822Name` を含めることができる (MAY)。 | | `otherName` | NOT RECOMMENDED | 下記参照 | 下記参照 | | その他の値 | NOT RECOMMENDED | - | - | 何らかの `otherName`が, もし存在する場合は下記のようにする。 1. 以下の場合を除き、パブリックインターネットのコンテキストに適用しなければならない (MUST)。 a. `type-id` は、申請者が所有権を証明したOID範囲内にある。 b. 申請者は、それ以外の場合には、公的な文脈でデータを主張する権利を実証することができる。 2. CAによって検証された証明書情報について、検証者を誤解させるようなセマンティクスを含めてはならない (MUST NOT)。 3. `otherName` `type-id` と `value` を定義する関連する ASN.1 モジュールに従って DER エンコードされなければならない (MUST)。 CAは、証明書にデータを含める理由を認識していない限り、追加の名前を含めてはならない (SHALL NOT)。 #### 7.1.2.11 Common Certificate Fields 7.1.2.11 共通証明書フィールド このSectionには、複数の証明書プロファイルに共通するフィールドがいくつか含まれている。ただし、これらのフィールドはすべての証明書プロファイルに共通であるとは限らない。証明書を発行する前に、CAは、各フィールドの内容を含む証明書の内容が、[Section 7.1.2](#712-certificate-content-and-extensions) に記載されている少なくとも 1 つの証明書プロファイルのすべての要件に全体的に準拠していることを確認しなければならない (MUST)。 ##### 7.1.2.11.1 Authority Key Identifier 7.1.2.11.1 認証局鍵識別子 | **フィールド** | **説明** | | --------------------------- | ---------------------------------------------------------------------------------------------------------- | | `keyIdentifier` | 存在しなければならない (MUST)。発行CAの `subjectKeyIdentifier` フィールドと同一でなければならない (MUST)。 | | `authorityCertIssuer` | 存在してはならない (MUST NOT) | | `authorityCertSerialNumber` | 存在してはならない (MUST NOT) | ##### 7.1.2.11.2 CRL Distribution Points 7.1.2.11.2 CRL配布ポイント CRL配布ポイント拡張は、次の場所に存在しなければならない (MUST)。 - 下位CA証明書 - 1)「ショートリブド利用者証明書」として適格ではなく、2) id-ad-ocsp accessMethod を持つ authorityInformationAccess 拡張を含まない利用者証明書。 CRL配布ポイント拡張は、次の場所には存在すべきではない (SHOULD NOT)。 - Root CA証明書 CRL 配布ポイント拡張は、次の場合にはオプションになる。 - ショートリブド利用者証明書 CRL配布ポイント拡張は、以下の場所に存在してはならない (MUST NOT)。 - OCSPレスポンダー証明書 CRL配布ポイント拡張が存在する場合、少なくとも 1 つの `DistributionPoint` を含めなければならない (MUST)。複数を含めることは推奨されない (NOT RECOMMENDED)。すべての `DistributionPoint` 項目は、次のようにフォーマットされなければならない。 表: `DistributionPoint` プロファイル | **フィールド** | **存在** | **説明** | | ------------------- | -------- | --------------------------------------------------------------------------------------------------------- | | `distributionPoint` | MUST | `DistributionPointName` は、以下に説明するようにフォーマットされた `fullName` でなければならない (MUST)。 | | `reasons` | MUST NOT | | | `cRLIssuer` | MUST NOT | | `fullName` には少なくとも 1 つの `GeneralName` が含まれていなければならない (MUST)。複数が含まれている場合もある (MAY)。すべての `GeneralName` は、`uniformResourceIdentifier` タイプでなければならず (MUST)、それぞれのスキームは "http" でなければならない (MUST)。最初の `GeneralName` には、この証明書の発行CAのCRLサービスのHTTP URLが含まれていなければならない。 ##### 7.1.2.11.3 Signed Certificate Timestamp List 7.1.2.11.3 署名された証明書のタイムスタンプリスト 存在する場合、署名済み証明書タイムスタンプリスト拡張内容は、[RFC 6962, Section 3.3](https://tools.ietf.org/html/rfc6962#section-3.3) で指定されているように、エンコードされた `SignedCertificateTimestampList` を含む`OCTET STRING`でなければならない (MUST)。 `SignedCertificateTimestampList` 内に含まれる各 `SignedCertificateTimestamp` は、現在の証明書に対応する `PreCert` `LogEntryType` でなければならない (MUST)。 ##### 7.1.2.11.4 Subject Key Identifier 7.1.2.11.4 主体者識別名鍵識別子 `subjectKeyIdentifier` が存在する場合、[RFC 5280, Section 4.2.1.2](https://tools.ietf.org/html/rfc5280#section-4.2.1.2) で定義されているとおりに設定されなければならない (MUST)。CAは、発行したすべての証明書の範囲内で、一意の公開鍵ごとに一意の `subjectKeyIdentifier` を生成しなければならない (MUST) (`tbsCertificate` の `subjectPublicKeyInfo` フィールド)。たとえば、CAは、公開鍵から派生したアルゴリズムを使用してサブジェクト キー識別子を生成することも、CSPRNG などを使用して十分に大きい一意の番号を生成することもできる。 ##### 7.1.2.11.5 Other Extensions 7.1.2.11.5 その他の拡張 適用可能な証明書プロファイルによって直接アドレス指定されないすべての拡張と拡張の値は下記のとおりとなる。 1. 以下の場合を除き、パブリックインターネットのコンテキストに適用しなければならない (MUST)。 a. 拡張OIDが、申請者が所有権を証明したOID範囲内にある。 b. 申請者が、それ以外の場合には、公的な文脈でデータを主張する権利を実証することができる。 2. CAによって検証された証明書情報について、検証者を誤解させるようなセマンティクスを含めてはならない (MUST NOT) (たとえば、リモート発行のため、対応する私有鍵がそのようなハードウェアに限定されていることをCAが検証できない場合に、私有鍵がスマートカードに保存されていることを示す拡張を含めるなど)。 3. 拡張と拡張値を定義する関連する ASN.1 モジュールに従って DER エンコードされなければならない (MUST)。 CAは、証明書にデータを含める理由を認識していない限り、追加の拡張または値を含めてはなならない (SHALL NOT)。 ### 7.1.3 Algorithm object identifiers 7.1.3 アルゴリズムオブジェクト識別子 #### 7.1.3.1 SubjectPublicKeyInfo 7.1.3.1 主体者公開鍵情報 証明書または事前証明書内の `subjectPublicKeyInfo` フィールドには次の要件が適用される。その他のエンコードは許可されていない。 ##### 7.1.3.1.1 RSA 7.1.3.1.1 RSA CAは、rsaEncryption (OID: 1.2.840.113549.1.1.1) アルゴリズム識別子を使用してRSA鍵を示す (SHALL)。パラメータは必ず存在し、明示的にNULLにしなければならない (MUST)。 CAは、RSA鍵を示すために、id-RSASSA-PSS (OID: 1.2.840.113549.1.1.10) アルゴリズム識別子などの異なるアルゴリズムを使用しない (SHALL NOT)。 エンコードされた場合、RSA鍵の `AlgorithmIdentifier` は、次の16進エンコードされたバイトとバイト単位で同一でなければならない (MUST): `300d06092a864886f70d0101010500` ##### 7.1.3.1.2 ECDSA 7.1.3.1.2 ECDSA CAは、id-ecPublicKey (OID: 1.2.840.10045.2.1) アルゴリズム識別子を使用してECDSA鍵を示す (SHALL)。パラメータは `namedCurve` エンコーディングを使用しなければならない (MUST)。 - P-256鍵の場合、`namedCurve` は secp256r1 (OID: 1.2.840.10045.3.1.7) でなければならない (MUST)。 - P-384鍵の場合、`namedCurve` は secp384r1 (OID: 1.3.132.0.34) でなければならない (MUST)。 - P-521鍵の場合、`namedCurve` は secp521r1 (OID: 1.3.132.0.35) でなければならない (MUST)。 エンコードされると、ECDSA鍵の `AlgorithmIdentifier` は、次の16進エンコードされたバイトとバイト単位で同一でなければならない (MUST)。 - P-256鍵の場合、 `301306072a8648ce3d020106082a8648ce3d030107`. - P-384鍵の場合、 `301006072a8648ce3d020106052b81040022`. - P-521鍵の場合、 `301006072a8648ce3d020106052b81040023`. #### 7.1.3.2 Signature AlgorithmIdentifier 7.1.3.2 署名アルゴリズム識別子 CA私有鍵によって署名されたすべてのオブジェクトは、署名のコンテキストにおける `AlgorithmIdentifier` または `AlgorithmIdentifier` 派生型の使用に関する Baseline Requirementsに 準拠しなければならない (MUST)。 特に、以下のすべてのオブジェクトとフィールドに適用される。 - 証明書または事前証明書の `signatureAlgorithm` フィールド。 - TBSCertificate の `signature` フィールド (たとえば、証明書または事前証明書のいずれかで使用されるもの) - CertificateList の `signatureAlgorithm` フィールド - TBSCertListの `signature` フィールド - BasicOCSPResponse の `signatureAlgorithm` フィールド これらのフィールドには他のエンコードは許可されていない。 ##### 7.1.3.2.1 RSA 7.1.3.2.1 RSA CAは、以下の署名アルゴリズムとエンコーディングのいずれかを使用する (SHALL)。エンコードされると、`AlgorithmIdentifier` は指定された16進エンコードされたバイトとバイト単位で同一でなければならない (MUST)。 - SHA-256 を使用した RSASSA-PKCS1-v1_5: エンコーディング: `300d06092a864886f70d01010b0500`. - SHA-384 を使用した RSASSA-PKCS1-v1_5: エンコーディング: `300d06092a864886f70d01010c0500`. - SHA-512 を使用した RSASSA-PKCS1-v1_5: エンコーディング: `300d06092a864886f70d01010d0500`. - SHA-256 を使用した RSASSA-PSS、SHA-256 を使用した MGF-1、そしてソルト長 32 バイト: エンコーディング: ```hexdump 304106092a864886f70d01010a3034a00f300d0609608648016503040201 0500a11c301a06092a864886f70d010108300d0609608648016503040201 0500a203020120 ``` - SHA-384 を使用した RSASSA-PSS、SHA-384 を使用した MGF-1、そしてソルト長 48 バイト: エンコーディング: ```hexdump 304106092a864886f70d01010a3034a00f300d0609608648016503040202 0500a11c301a06092a864886f70d010108300d0609608648016503040202 0500a203020130 ``` - SHA-512 を使用した RSASSA-PSS、SHA-512 を使用した MGF-1、そしてソルト長 64 バイト: エンコーディング: ```hexdump 304106092a864886f70d01010a3034a00f300d0609608648016503040203 0500a11c301a06092a864886f70d010108300d0609608648016503040203 0500a203020140 ``` さらに、CAは、以下の条件がすべて満たされている場合、次の署名アルゴリズムとエンコーディングを使用する場合がある (MAY)。 - 証明書の `signatureAlgorithm` フィールドや TBSCertificate の `signature` フィールドなど、証明書内で使用される場合: - 新しい証明書は、クロス証明書であるルートCA証明書または下位CA証明書である。 - 同じ発行CA証明書によって発行された既存の証明書があり、署名アルゴリズムに次のエンコードを使用している。 - 既存の証明書には少なくとも64ビットの長さの `serialNumber` がある。 - 新しい証明書と既存の証明書の唯一の違いは、次のいずれかである。 - 同じアルゴリズムと鍵サイズを使用する、`subjectPublicKeyInfo` 内の新しい `subjectPublicKey` - 既存の証明書と同じエンコードされた長さの新しい`serialNumber` - 新しい証明書の `extKeyUsage` 拡張が存在し、少なくとも 1 つのキー目的が指定されており、指定されたキー目的のいずれも id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1) または anyExtendedKeyUsage (OID: 2.5.29.37.0) キー目的ではない。 - 新しい証明書の `basicConstraints` 拡張に、ゼロの pathLenConstraint がある。 - BasicOCSPResponseの `signatureAlgorithm` などのOCSPレスポンス内で使用される場合: - ResponseData の `producedAt` フィールド値は 2022-06-01 00:00:00 UTC より前でなければならない (MUST)。 - CA鍵ペアの公開鍵を含み、同じ主体者識別名を持つ、有効期限が切れておらず、失効されていないすべての証明書には、存在する鍵使用法が id-kp-ocspSigning (OID: 1.3.6.1.5.5.7.3.9) のみである `extKeyUsage` 拡張も含まれていなければならない (MUST)。 - CRL内で使用される場合 (CertificateList の `signatureAlgorithm` フィールドや TBSCertList の `signature` フィールドなど) は次のとおりである。 - CRLは1つ以上のルートCAまたは下位CA証明書によって参照される。 - ルートCAまたは下位CA証明書は、署名アルゴリズムに次のエンコーディングを使用して 1 つ以上の証明書を発行した。 **注意**: 上記の要件により、CAはこのエンコードを使用して事前証明書に署名することはできない。 - SHA-1を使用したRSASSA-PKCS1-v1_5: エンコーディング: `300d06092a864886f70d0101050500` ##### 7.1.3.2.2 ECDSA 7.1.3.2.2 ECDSA CAは、使用される署名鍵に基づいて適切な署名アルゴリズムとエンコーディングを使用する (SHALL)。 署名鍵が P-256 の場合、署名には SHA-256 を使用した ECDSA を使用しなければならない (MUST)。エンコードされると、`AlgorithmIdentifier` は次の16進エンコードされたバイトとバイト単位で同一でなければならない (MUST): `300a06082a8648ce3d040302` 署名鍵が P-384 の場合、署名には SHA-384 を使用した ECDSA を使用しなければならない (MUST)。エンコードされると、`AlgorithmIdentifier` は次の16進エンコードされたバイトとバイト単位で同一でなければならない (MUST): `300a06082a8648ce3d040303` 署名鍵が P-521 の場合、署名には SHA-512 を使用した ECDSA を使用しなければならない (MUST)。エンコードされると、`AlgorithmIdentifier` は次の16進エンコードされたバイトとバイト単位で同一でなければならない (MUST): `300a06082a8648ce3d040304` ### 7.1.4 Name Forms 7.1.4 名前形式 属性値は [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280) に従ってエンコードされる (SHALL)。 このSectionでは、CAによって発行されるすべての証明書に適用されるエンコードルールについて詳しく説明する。[Section 7.1.2](#712-certificate-content-and-extensions) でさらに制限が指定される場合があるが、これらの制限は Baseline Requirements に優先するものではない。 #### 7.1.4.1 Name Encoding 7.1.4.1 名前のエンコード 以下の要件は、[Section 7.1.2](#712-certificate-content-and-extensions) に記載されているすべての証明書に適用される。具体的には、[Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) で定義されている技術的に制約のある非TLS下位CA証明書が含まれるが、そのようなCA 証明書によって発行された証明書は、Baseline Requirements の範囲外であるため含まれない。 有効な認証パス（[RFC 5280, Section 6](https://tools.ietf.org/html/rfc5280#section-6) で定義）に関しては以下のとおり。 - 認証パス内の各証明書について、証明書の発行者識別名フィールドのエンコードされた内容は、発行CA証明書のサブジェクト識別名フィールドのエンコードされた形式とバイト単位で同一である (SHALL)。 - 認証パス内の各CA証明書について、証明書のサブジェクト識別名フィールドのエンコードされた内容は、期限切れの証明書や失効した証明書を含め、[RFC 5280, Section 7.1](https://tools.ietf.org/html/rfc5280#section-7.1) に従ってサブジェクト識別名が等しいと比較できるすべての証明書間でバイト単位で同一である (SHALL)。 `Name` をエンコードする際、CAは次の点を確認する (SHALL)。 - 各 `Name` には `RDNSequence` が含まれていなければならない (MUST)。 - 各 `RelativeDistinguishedName` には、`AttributeTypeAndValue` が 1 つのみ含まれていなければならない (MUST)。 - 各 `RelativeDistinguishedName` が存在する場合、[Section 7.1.4.2](#7142-subject-attribute-encoding) に現れる順序で `RDNSequence` 内にエンコードされる。 - たとえば、`countryName` `AttributeTypeAndValue` ペアを含む `RelativeDistinguishedName` は、`stateOrProvinceName` `AttributeTypeAndValue` を含む `RelativeDistinguishedName` の前に、`RDNSequence` 内でエンコードされなければならない (MUST)。 - Baseline Requirements で明示的に許可されていない限り、各 `Name` には、すべての `RelativeDistinguishedName` にわたって、特定の `AttributeTypeAndValue` のインスタンスが複数含まれていてはならない (MUST NOT)。 **注意**: [Section 7.1.2.2.2](#71222-cross-certified-subordinate-ca-naming) では、そのSectionで説明されているように、[Cross-Certified Subordinate CA Certificate](#7122-cross-certified-subordinate-ca-certificate-profile) を発行する場合の上記の名前エンコード要件に対する例外が規定されている。 #### 7.1.4.2 Subject Attribute Encoding 7.1.4.2 主体者識別名属性のエンコード このドキュメントでは、`tbsCertificate` の `subject` フィールド内に表示される可能性のある多数の属性の内容と検証の要件を定義している。CAは、[Section 7.1.2](#712-certificate-content-and-extensions) で指定された関連する証明書プロファイルで指定されているとおりに内容が検証されていない限り、またそのプロファイルで許可されている場合以外は、これらの属性を含めることができない (SHALL NOT)。 以下の表に記載されている属性を証明書の `subject` フィールドに含むCAは、それらの属性を表に表示されている相対順序でエンコードし、属性に指定されたエンコード要件に従う (SHALL)。 表: 選択した属性のエンコードと順序の要件 | **属性** | **OID** | **仕様** | **エンコード要件** | **最大長 [^maxlength]** | | ------------------------ | ---------------------------- | ----------------------------------------------- | --------------------------------------------------------------------- | ----------------------- | | `domainComponent` | `0.9.2342.19200300.100.1.25` | [RFC 4519](https://tools.ietf.org/html/rfc4519) | `IA5String` を使用しなければならない (MUST) | 63 | | `countryName` | `2.5.4.6` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | `PrintableString` を使用しなければならない (MUST) | 2 | | `stateOrProvinceName` | `2.5.4.8` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | `UTF8String` または `PrintableString` を使用しなければならない (MUST) | 128 | | `localityName` | `2.5.4.7` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | `UTF8String` または `PrintableString` を使用しなければならない (MUST) | 128 | | `organizationName` | `2.5.4.10` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | `UTF8String` または `PrintableString` を使用しなければならない (MUST) | 64 | | `organizationalUnitName` | `2.5.4.11` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | `UTF8String` または `PrintableString`を使用しなければならない (MUST) | 64 | | `commonName` | `2.5.4.3` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | `UTF8String` または `PrintableString` を使用しなければならない (MUST) | 64 | 以下の表に記載されている証明書の `subject` フィールドに属性を含むCAは、その属性に指定されたエンコード要件に従う (SHALL)。 表: 選択した属性のエンコード要件 | **属性** | **OID** | **仕様** | **エンコード要件** | **最大長 [^maxlength]** | | ------------------------ | -------------------------- | ----------------------------------------------- | ----------------------------------------------------------------------- | ----------------------- | | `businessCategory` | `2.5.4.15` | X.520 | `UTF8String` または `PrintableString` を使用しなければならない (MUST)。 | 128 | | `jurisdictionCountry` | `1.3.6.1.4.1.311.60.2.1.3` | EV Guidelines | `PrintableString` を使用しなければならない (MUST)。 | 2 | | `serialNumber` | `2.5.4.5` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | `PrintableString` を使用しなければならない (MUST)。 | 64 | | `organizationIdentifier` | `2.5.4.97` | X.520 | `UTF8String` または `PrintableString`を使用しなければならない (MUST)。 | 無し | [^maxlength]: **注意**: DirectoryString の ASN.1 の長さ制限は、バイト制限ではなく文字制限として表される。 #### 7.1.4.3 Subscriber Certificate Common Name Attribute 7.1.4.3 利用者証明書のコモンネーム属性 存在する場合、この属性には、証明書の `subjectAltName` 拡張に含まれる値の 1 つであるエントリーが 1 つのみ含まれていなければならない (MUST) ([Section 7.1.2.7.12](#712712-subscriber-certificate-subject-alternative-name) を参照)。フィールドの値は次のようにエンコードされなければならない (MUST)。 - 値がFQDNまたはワイルドカードドメイン名の場合、その値は `subjectAltName` 拡張の `dNSName` エントリー値の文字単位のコピーとしてエンコードされなければならない (MUST)。具体的には、FQDNのすべてのドメインラベルまたはワイルドカードドメイン名のFQDN部分はLDHラベルとしてエンコードされなければならず、Pラベルは Unicode 表現に変換してはならない (MUST NOT)。 #### 7.1.4.4 Other Subject Attributes 7.1.4.4 その他の主体者識別名属性 [Section 7.1.2](#712-certificate-content-and-extensions) で指定された関連する証明書プロファイルによって明示的に許可されている場合、CAは [Section 7.1.4.2](#7142-subject-attribute-encoding) で指定された属性以外に、`AttributeTypeAndValue` 内に追加の属性を含めることができる (MAY)。 ### 7.1.5 Name constraints 7.1.5 名前制約 規定しない。 ### 7.1.6 Certificate policy object identifier 7.1.6 証明書ポリシーオブジェクト識別子 #### 7.1.6.1 Reserved Certificate Policy Identifiers 7.1.6.1 予約済み証明書ポリシー識別子 次の証明書ポリシー識別子は、証明書が Baseline Requirements、EV Guidelines、Baseline Requirements for Code Signing Certificatesおよび S/MIME Baseline Requirements に準拠していることを示すオプションの手段としてCAが使用するために予約されている。 | 予約済み証明書ポリシー識別子 | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) domain-validated(1)} (2.23.140.1.2.1)` | | `{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)` | | `{joint‐iso‐itu‐t(2) international‐organizations(23) ca‐browser‐forum(140) certificate‐policies(1) ev-guidelines(1)} (2.23.140.1.1)` | | `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) code-signing-requirements(4) code signing(1)} (2.23.140.1.4.1)` | | `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) mailbox-validated (1) strict (3)} (2.23.140.1.5.1.3)` | | `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) organization-validated (2) legacy (1)} (2.23.140.1.5.2.1)` | | `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) organization-validated (2) strict (3)} (2.23.140.1.5.2.3)` | ### 7.1.7 Usage of Policy Constraints extension 7.1.7 ポリシー制約拡張の使用 規定しない。 ### 7.1.8 Policy qualifiers syntax and semantics 7.1.8 ポリシー修飾子の構文および意味 ポリシー修飾子については、このCP/CPSを公開する Web ページの URI を保存できる (MAY)。 ### 7.1.9 Processing semantics for the critical Certificate Policies extension 7.1.9 重要な証明書ポリシー拡張の意味 規定しない。 ## 7.2 CRL profile 7.2 CRLプロファイル **[TLSサーバー証明書]** 2024-03-15 以前はCAはBaseline Requirementsで指定されたプロファイル、またはBaseline Requirements のバージョン 1.8.7 で指定されたプロファイルに従ってCRLを発行する (SHALL)。2024-03-15 以降、CA は、Baseline Requirements で指定されたプロファイルに従ってCRLを発行する (SHALL)。 CAが Baseline Requirements への準拠を主張する場合、CAが発行するすべての CRLは、[RFC 5280](https://tools.ietf.org/html/rfc5280) を組み込んで派生した次の CRLプロファイルに準拠しなければならない (MUST)。明示的に記載されている場合を除き、このドキュメントで課される規範的要件に加えて、RFC 5280 で課されるすべての規範的要件が適用される。CAは、注意すべきその他の問題について [RFC 5280, Appendix B](https://tools.ietf.org/html/rfc5280#appendix-B) を調べる必要がある (SHOULD)。 full CRLとは、CAによって発行されたすべての証明書を範囲に含むCRLである。 分割CRLは、CAが一定期間内に発行したすべての証明書など、範囲が制限された CRLである。分割CRLに発行配布ポイント拡張 (OID 2.5.29.28) が存在することを除けば、このプロファイルの観点からは、両方のCRL形式は構文的に同じである。 最低限、CAは、最初の証明書を発行してから 7 日以内に、CAが発行した証明書の完全なセットをカバーする「完全」なCRLまたは「分割された」CRLセットのいずれかを発行しなければならない (MUST)。言い換えると、分割CRLのみを発行する場合、それらのCRLを組み合わせた範囲は、full CRLの範囲と同等でなければならない。 CAは間接的なCRLを発行してはならない (MUST NOT) (つまり、CRLの発行者は、CRLの範囲に含まれるすべての証明書の発行者ではない)。 **[すべての証明書に共通 ]** 表: CRLフィールド | **フィールド** | **存在** | **説明** | | ----------------------- | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `tbsCertList` | | | | - `version` | MUST | v2(1)でなければならない (MUST) 、 [Section 7.2.1](#721-version-numbers) を参照 | | - `signature` | MUST | [Section 7.1.3.2](#7132-signature-algorithmidentifier) を参照 | | - `issuer` | MUST | 発行CAの `subject` フィールドとバイト単位で同一でなければならない (MUST)。 | | - `thisUpdate` | MUST | CRLの発行日を示す。 | | - `nextUpdate` | MUST | 次のCRLが発行される日付を示す。利用者証明書を対象とするCRLの場合、`thisUpdate` から最長 10 日後である。その他のCRLの場合、`thisUpdate` から最長 12 か月後である。 | | - `revokedCertificates` | * | CAが失効した証明書を発行し、失効した証明書の有効期間を過ぎて少なくとも 1 つの定期的にスケジュールされたCRLに対応するエントリーがまだ表示されていない場合は、存在しなければならない (MUST)。CAは、失効した証明書の有効期間を過ぎて少なくとも 1 つの定期的にスケジュールされたCRLに対応するエントリーが表示された後、その証明書のエントリーを削除する必要がある (SHOULD)。追加の要件については、「revokedCertificates コンポーネント」テーブルを参照のこと。 | | - `extensions` | MUST | 追加の要件については、「CRL拡張」表を参照のこと。 | | `signatureAlgorithm` | MUST | エンコードされた値は、`tbsCertList.signature` とバイト単位で同一なければならない (MUST)。 | | `signature` | MUST | - | | その他の値 | NOT RECOMMENDED | - | ### 7.2.1 Version number(s) 7.2.1 バージョン番号 証明書失効リストは、X.509 v2 タイプでなければならない (MUST)。 ### 7.2.2 CRL and CRL entry extensions 7.2.2 CRLとCRLエントリー拡張 表: CRL拡張 | **拡張** | **存在** | **Critical** | **説明** | | -------------------------- | --------------- | ------------ | --------------------------------------------------------------------------------------------- | | `authorityKeyIdentifier` | MUST | N | [Section 7.1.2.11.1](#712111-authority-key-identifier) を参照 | | `CRLNumber` | MUST | N | ゼロ (0) 以上 2¹⁵⁹ 未満の整数を含み、厳密に増加するシーケンスを伝えなければならない (MUST)。 | | `IssuingDistributionPoint` | * | Y | [Section 7.2.2.1 CRL Issuing Distribution Point](#7221-crl-issuing-distribution-point) を参照 | | その他の拡張 | NOT RECOMMENDED | - | - | 表: revokedCertificates コンポーネント | **コンポーネント** | **存在** | **説明** | | -------------------- | -------- | ---------------------------------------------------------------------------------------------- | | `serialNumber` | MUST | 失効した証明書に含まれる serialNumber とバイト単位で同一でなければならない (MUST)。 | | `revocationDate` | MUST | 通常、失効が発生した日時である。遡及が許可される状況については、この表の後の脚注を参照のこと。 | | `crlEntryExtensions` | * | 追加の要件については、「crlEntryExtensions コンポーネント」表を参照しのこと。 | **注意:** **[TLSサーバー証明書]** 証明書のCRLエントリーに示されている失効日より前に証明書の私有鍵が危殆化されたと判断された場合、CAはCRLエントリーの失効日を更新する必要がある (SHOULD)。revocationDate フィールドの日付を遡ることは、RFC 5280 (Section 5.3.2) で説明されているベストプラクティスの例外であるが、Baseline Requirements では、証明書が危殆化されたと最初に判断された日付として revocationDate フィールドを処理するTLS実装をサポートするために revocationDate フィールドの使用を指定している。 表: crlEntryExtensions コンポーネント | **CRLエントリー拡張** | **存在** | **説明** | | --------------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `reasonCode` | * | 存在する場合 (OID 2.5.29.21)、critical としてマークしてはならず (MUST NOT)、証明書の失効の最も適切な理由を示さなければならない (MUST)。

CRLエントリーが、技術的に発行を実行できない証明書のものであり、1) CRLエントリーが 2023-07-15 より前に失効したベースライン要件の対象となる利用者証明書のものであるか、2) 失効の理由 (reasonCode) が指定されていない (0) 場合を除き、存在しなければならない (MUST)。

追加の要件については、「CRLReasons」表を参照のこと。 | | その他の値 | NOT RECOMMENDED | - | 表: CRLReasons | **RFC 5280 reasonCode** | **RFC 5280 reasonCode 値** | **説明** | | ----------------------- | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | unspecified | 0 | reasonCode の省略によって表される。CRLエントリーが、2023-07-15 より前に失効した Baseline Requirements の対象となる利用者証明書の場合を除き、技術的に発行を実行できない証明書のCRLエントリーの場合は省略する(MUST)。 | | keyCompromise | 1 | 利用者の私有鍵が危殆化、または疑われていることを示す。 | | affiliationChanged | 3 | 証明書内の主体者識別名またはその他の主体者識別名ID情報が変更されたが、証明書の私有鍵が危殆化されたと疑う理由がないことを示す。 | | superseded | 4 | 利用者が新しい証明書を要求した、証明書内のFQDNまたはIPアドレスのドメイン承認または制御の検証を信頼すべきではないという合理的な証拠をCAが持っている、または証明書が Baseline Requirements またはCAのCP/PSに準拠していないなどのコンプライアンス上の理由で CAが証明書を失効したために、証明書が置き換えられることを示す。 | | cessationOfOperation | 5 | 証明書の有効期限が切れる前に証明書を持つ Web サイトが閉鎖されたか、または証明書の有効期限が切れる前に利用者が証明書内のドメイン名を所有または管理しなくなったことを示す。 | | certificateHold | 6 | CRLエントリーが、1) Baseline Requirements の対象となる証明書、または 2) Baseline Requirements の対象ではない証明書で、A) 2020-09-30 以降に発行されたか、B) 2020-09-30 以降の `notBefore` を持つものである場合は、含めてはならない (MUST NOT)。 | | privilegeWithdrawn | 9 | 証明書利用者が証明書要求で誤解を招く情報を提供したり、利用者契約または利用規約に基づく重要な義務を遵守しなかったりするなど、keyCompromise に至らなかった利用者側の違反があったことを示す。 | 利用者契約書、またはその中で参照されるオンラインリソースでは、利用者に上記の失効理由オプションについて通知し、各オプションを選択するタイミングについて説明を提供しなければならない (MUST)。CAが利用者に提供するツールでは、利用者が証明書の失効を要求するときにこれらのオプションを簡単に指定できるようにしなければならない (MUST)。デフォルト値は失効理由が提供されないことである (つまり、デフォルトは CRLReason が「未指定 (0)」に相当し、CRLに reasonCode 拡張が提供されない)。 privilegeWithdrawn reasonCodeは、失効理由オプションとして利用者に提供しないようにする (SHOULD NOT)。この reasonCode の使用は利用者ではなくCAによって決定されるためである。 CAが、CRLエントリーに reasonCode 拡張が含まれていないか、または reasonCode 拡張に keyCompromise 以外の理由が含まれている証明書の鍵危殆化の検証可能な証拠を取得した場合、CAはCRLエントリーを更新して、reasonCode 拡張の CRLReason として keyCompromise を入力する必要がある (SHOULD)。 #### 7.2.2.1 CRL Issuing Distribution Point 7.2.2.1 CRL発行配布ポイント パーティション化されたCRLには、`distributionPoint` 拡張が含まれている必要がある。発行配布ポイント拡張の distributionPoint フィールドが存在しなければならない (MUST)。さらに、DistributionPointName 値の `fullName` フィールドが存在しなければならず (MUST)、その値は次の要件に準拠していなければならない (MUST)。 1. CRLの範囲内の証明書にCRL配布ポイント拡張が含まれている場合、CRL配布ポイントの `fullName` フィールドにある少なくとも 1 つの `uniformResourceIdentifiers` が、CRLの発行配布ポイント拡張の `fullName` フィールドに含まれていなければならない (MUST)。発行配布ポイント拡張の `uniformResourceIdentifier` 値のエンコードは、証明書のCRL配布ポイント拡張で使用されるエンコードとバイト単位で同一でなければならない (MUST)。 2. 他の`uniformResourceIdentifier` タイプの GeneralNames も含めることができる (MAY)。 3. 非`uniformResourceIdentifier` GeneralName タイプを含めることはできない (MUST NOT)。 `indirectCRL` および `onlyContainsAttributeCerts` フィールドは `FALSE` (つまり、使用されない) に設定されなければならない (MUST)。 CAは、CRLの範囲に応じて、`onlyContainsUserCerts` フィールドと `onlyContainsCACerts` フィールドのいずれかを `TRUE` に設定できる (MAY)。 CA は、`onlyContainsUserCerts` フィールドと `onlyContainsCACerts` フィールドの両方を使用してはならない (MUST NOT)。 `onlySomeReasons` フィールドは含めないようにする (SHOULD NOT)。含める場合、CAは理由コードに関係なくすべての失効を範囲とする別のCRLを提供しなければならない (MUST)。 この拡張は、full CRLには推奨されない (NOT RECOMMENDED)。 ## 7.3 OCSP profile 7.3 OCSPプロファイル OCSP応答が Root CAまたは下位CA証明書 (相互認証された下位CA証明書を含む) に対するものであり、その証明書が失効している場合は、`CertStatus` の `RevokedInfo` 内の `revocationReason` フィールドが存在すしなければならない (MUST)。 示された `CRLReason` には、[Section 7.2.2](#722-crl-and-crl-entry-extensions) で指定されているように、CRL に許可された値が含まれていなければならない (MUST)。 ### 7.3.1 Version number(s) 7.3.1 バージョン番号 CAはOCSPバージョン 1 を使用する。 ### 7.3.2 OCSP extensions 7.3.2 OCSP拡張 OCSP 応答の `singleExtensions` には、`reasonCode` (OID 2.5.29.21) CRL エントリ拡張を含めることはできない (MUST NOT)。 # 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS 8 準拠性監査とその他の監査基準 CAは常に次の事項を遵守する (SHALL)。 1. 事業を展開するすべての管轄区域において、その事業および発行する証明書に適用されるすべての法律に従って証明書を発行し、PKIを運用する。 2. [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) に準拠する。 3. CP/CPSに規定された監査要件に準拠する。 4. 証明書の発行に当該管轄区域の法律によりライセンスが必要な場合は、運営する各管轄区域でCAとしてライセンスを取得する必要がある。 ## 8.1 Frequency or circumstances of assessment 8.1 評価の頻度と要件 新しい証明書を発行するために使用できる証明書は、[Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile)、[Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile)、または [Section 7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile) に従って技術的に制約され、 [Section 8.7](#87-self-audits) のみに従って監査されるか、制約がなく、この Section の残りのすべての要件に従って完全に監査されなければならない (MUST)。証明書に X.509v3 `basicConstraints` 拡張が含まれており、`cA`ブール値が true に設定されている場合、新しい証明書を発行するために使用できるとみなされ、したがって定義上、Root CA 証明書または下位CA証明書になる。 CAが証明書を発行する期間は、連続した監査期間に分割される (SHALL)。監査期間は 1 年を超えてはならない (MUST NOT)。 CAが [Section 8.4](#84-topics-covered-by-assessment) に記載されている監査スキームのいずれかに準拠していることを示す現在有効な監査レポートを持っていない場合、CAは、パブリックトラスト証明書を発行する前に、[Section 8.4](#84-topics-covered-by-assessment) に記載されている監査スキームのいずれかの適用可能な標準に従って実行されるポイントインタイムの準備状況評価に合格する (SHALL)。ポイントインタイムの準備状況評価は、パブリックトラスト証明書を発行する 12 か月前までに完了するものとし (SHALL)、最初のパブリックトラスト証明書を発行してから 90 日以内に、そのようなスキームに基づく完全な監査が続く (SHALL)。 ## 8.2 Identity/qualifications of assessor 8.2 監査人の身元/資格 CAの監査は、公認監査人によって実行される (SHALL)。公認監査人とは、以下の資格およびスキルを総合的に有する自然人、法人、または自然人もしくは法人のグループを指す。 1. 監査の対象から独立している。 2. 適格な監査スキームで指定されている条件に対応する監査を実施できる能力（[Section 8.4](#84-topics-covered-by-assessment) を参照） 3. 公開鍵基盤技術、情報セキュリティツールと技術、情報技術とセキュリティ監査および第三者の認証機能の検査に精通した個人を雇用する。 4. (WebTrust規格に基づいて実施される監査の場合) WebTrustによる実施許可を受けている。 5. 法律、政府の規制、または職業倫理に準拠している。 6. 国内政府監査機関の場合を除き、少なくとも100万米ドルの補償を保険範囲とする業務上の過失および不備に対する責任保険に加入している。 ## 8.3 Assessor's relationship to assessed entity 8.3 監査人と被監査部門の関係 監査人は、監査関連の側面を除き、評価対象組織から業務上および組織的に独立している (SHALL)。監査を実施するにあたり、評価対象組織は監査活動に対して適切な支援を提供する (SHALL)。 ## 8.4 Topics covered by assessment 8.4 監査で扱われる事項 CAは以下のスキームに従って監査を受ける (SHALL)。 1. WebTrust (TLSサーバーCA): - "Principles and Criteria for Certification Authorities Version 2.2 以降" および次のいずれか - "WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security Version 2.7 以降" - "WebTrust Principles and Criteria for Certification Authorities – SSL Baseline" Version 2.8 以降" および "WebTrust Principles and Criteria for Certification Authorities – Network Security" Version 1.0 以降" 2. WebTrust (S/MIME CA): - Baseline Requirements の最初のバージョンの [Section 1.2.1](#121-revisions) で定義されている発効日より前に開始される監査期間については、"WebTrust for CAs v2.2.2以降" - Baseline Requirements の最初のバージョンの [Section 1.2.1](#121-revisions) で定義された発効日以降に開始する監査期間については、"WebTrust for CAs v2.2.2以降" および "WebTrust for S/MIME Baseline Requirements v1.0.0以降" - 2025-04-01 以降に開始する監査期間の場合、"WebTrust for CAs v2.2.2 以降" および "WebTrust for S/MIME Baseline Requirements v1.0.0以降" および "WebTrust for Network Security v2.0 以降" 3. WebTrust (コードサイニングCA): - “WebTrust for CAs v2.0" および "WebTrust for Certification Authorities – Code Signing Baseline Requirements v2.0以降" および “WebTrust for Certification Authorities – Network Security – Version 1.0 以降" 監査が制度の要件に従って継続的に実施されることを保証するために、定期的な監視/説明責任の手順を組み込まなければならない (MUST)。 監査は、[Section 8.2](#82-identityqualifications-of-assessor) に規定されているように、公認監査人によって実施されなければならない (MUST)。 エンタープライズRAではない外部委託先の場合、CAは、外部委託先のパフォーマンスが外部委託先の運用規定またはCAの CP/CPSのいずれかに準拠しているかどうかの意見を提供する、[Section 8.4](#84-topics-covered-by-assessment) に記載されている承認済み監査スキームの基礎となる監査基準に基づいて発行された監査レポートを取得する (SHALL)。外部委託先が準拠していないという意見の場合、CAは外部委託先が委任された機能を継続して実行することを許可しない (SHALL NOT)。 外部委託先の監査期間は 1 年を超えない (SHALL NOT) (理想的にはCAの監査と一致する)。 ## 8.5 Actions taken as a result of deficiency 8.5 不備に対する対応 セコムトラストシステムズは、監査報告書で指摘された不備に対してすみやかに是正措置を実施する。 ## 8.6 Communication of results 8.6 監査結果の公開 監査レポートには、 [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers) に記載されているポリシー識別子の 1 つ以上を主張するすべての証明書の発行に使用される関連システムとプロセスが対象となっていることが明示的に記載される (SHALL)。CAは監査レポートを公開する (SHALL)。 CAは、監査期間の終了後 3 か月以内に監査レポートを公開しなければならない (MUST)。3 か月を超える遅延が発生した場合、CAは公認監査人が署名した説明文書を提供する (SHALL)。 監査レポートには、少なくとも次の明確にラベル付けされた情報が含まれていなければならない (MUST)。 1. 監査対象の組織の名称 2. 監査を実施する組織の名称と住所 3. 監査の範囲内にあった、クロス認証された下位CA証明書を含む、すべての Root および下位CA証明書のSHA-256フィンガープリント 4. 各証明書（および関連する鍵）を監査するために使用された監査基準とバージョン番号 5. 監査中に参照されたCAポリシー文書のリスト（バージョン番号付き） 6. 監査が一定期間を評価したのか、それともある時点を評価したのか 7. 監査期間が一定期間にわたる場合、開始日と終了日 8. 監査期間がある時点のものである場合は、その時点の日付 9. レポートが発行された日付。これは必ず終了日または特定の時点より後の日付になる。 公に入手可能な監査情報の信頼できる英語版は、公認監査人によって提供されなければならず(MUST)、CAはそれが公に入手可能であることを保証する(SHALL)。 監査レポートはPDF形式で提供されなければならず (MUST)、必要なすべての情報についてテキスト検索可能である (SHALL)。監査レポート内の各SHA-256フィンガープリントは大文字でなければならず (MUST)、コロン、スペース、または改行を含んではならない (MUST NOT)。 ## 8.7 Self-Audits 8.7 自己監査 - TLSサーバーCA CAが証明書を発行する期間中、CAはCP、CPSおよび Baseline Requirements の遵守を監視し、少なくとも四半期ごとに、前回の自己監査サンプルが取得された直後から始まる期間中にCAが発行した証明書の 1つまたは少なくとも 3% のうち大きい方の証明書からランダムに選択されたサンプルに対して自己監査を実行することにより、サービス品質を厳密に管理する (SHALL)。 2025年3月15日以降、CAは、同じ証明書に対して以前に実行されたリンティングとは独立して、選択されたサンプルセット内の証明書の技術的な正確性を検証するためにリンティングプロセスを使用する必要がある (SHOULD)。 [Section 8.4](#84-topics-covered-by-assessment) で指定された基準を満たす年次監査を受ける外部委託先を除き、CAは、CAが雇用する検証スペシャリストに、最後のサンプルが採取された直後から始まる期間に外部委託先によって検証された証明書の 1つまたは 3% のいずれか大きい方の少なくともランダムに選択されたサンプルに対して四半期ごとに継続的な監査を実施させることにより、外部委託先によって発行された証明書または検証された情報を含む証明書のサービス品質を厳密に管理する (SHALL)。CAは、各外部委託先の慣行と手順を確認し、外部委託先が Baseline Requirements および関連するCP/CPSに準拠していることを確認する (SHALL)。 CAは、各外部委託先の Baseline Requirements への準拠状況を毎年内部監査する (SHALL)。 技術的に制約のある下位CAが証明書を発行する期間中、下位CAに署名したCAは、CAの証明書ポリシーおよび下位CAのCPSへの準拠を監視する (SHALL)。少なくとも四半期ごとに、前回の監査サンプルが取得された直後から始まる期間中、1つの証明書または下位CAによって発行された証明書の少なくとも 3% のうち大きい方のランダムに選択されたサンプルに対して、CAは該当するすべてのCPが満たされていることを確認する。 - EV TLSサーバーCA EV証明書を発行する期間中、CAは、最後のサンプルが採取された直後から始まる期間に発行したEV証明書の少なくとも 3% をランダムに選択したサンプルに対して継続的な自己監査を実行することにより、サービス品質を厳密に管理しなければならない (MUST)。[Section 3.2.2.2.12](#322212-final-cross-correlation-and-due-diligence-ev-tls-server-certificates) の最終的な相互照合と適切な精査の要件がRAによって実行されるすべてのEV証明書については、CAは、最後のサンプルが採取された直後から始まる期間に発行したEV証明書の少なくとも 6 % をランダムに選択したサンプルに対して継続的な自己監査を実行することにより、サービス品質を厳密に管理しなければならない (MUST)。 - S/MIME CA CAが証明書を発行する期間中、CAはCP/CPSおよび S/MIME Baseline Requirements への準拠を監視し、少なくとも四半期ごとに、前回の自己監査サンプルが取得された直後から始まる期間中にCAが発行した証明書の 3% または 30個のいずれか大きい方の証明書を含むランダムに選択されたサンプルに対して自己監査を実行することにより、サービス品質を管理する (SHALL)。 2025年3月15日以降、CAは、同じ証明書に対して以前に実行されたリンティングとは独立して、選択されたサンプルセット内の証明書の技術的な正確性を検証するためにリンティングプロセスを使用する必要がある (SHOULD)。 - コードサイニングCA CAは、Baseline Requirements for Code Signing Certificates の自己監査要件を遵守しなければならない。コードサイニング証明書を発行する期間中、CAは、最後のサンプルが採取された直後に始まる期間に発行した非EVコードサイニング証明書の少なくとも 3% とEVコードサイニング証明書の少なくとも 3% のランダムに選択されたサンプルに対して継続的な自己監査を実行することにより、サービス品質を厳密に管理しなければならない (MUST)。Baseline Requirements for Code Signing Certificates のSection 8 の最終的な相互照合と適切な精査の要件がRAによって実行されるすべてのコードサイニング証明書については、CAは、最後のサンプルが採取された直後に始まる期間に発行した非EVコードサイニング証明書の少なくとも 6% とEVコードサイニング証明書の少なくとも 6% のランダムに選択されたサンプルに対して継続的な自己監査を実行することにより、サービス品質を厳密に管理しなければならない (MUST)。 ## 8.8 Review of delegated parties 8.8 委託先のレビュー [Section 8.4](#84-topics-covered-by-assessment) で指定された基準を満たす年次監査を受ける外部委託先、Enterprise RAおよび技術的に制約のある下位CAを除き、CAは委任された当事者の慣行と手順が [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) および関連するCP/CPSに準拠していることを確認する (SHALL)。CAは委任された当事者の義務を文書化し、委任された当事者がそれらの義務を遵守しているかどうかを少なくとも毎年監視する (SHALL)。 # 9. OTHER BUSINESS AND LEGAL MATTERS 9 その他の業務上および法的事項 ## 9.1 Fees 9.1 料金 ### 9.1.1 Certificate issuance or renewal fees 9.1.1 証明書の発行/更新手数料 契約書に別途規定する。 ### 9.1.2 Certificate access fees 9.1.2 証明書アクセス料金 規定しない。 ### 9.1.3 Revocation or status information access fees 9.1.3 失効またはステータス情報アクセス料金 規定しない。 ### 9.1.4 Fees for other services 9.1.4 その他のサービス料金 規定しない。 ### 9.1.5 Refund policy 9.1.5 返金ポリシー 契約書に別途規定する。 ## 9.2 Financial responsibility 9.2 財務的責任 ### 9.2.1 Insurance coverage 9.2.1 保険適用範囲 **[EV TLSサーバー証明書]** CAは運営および保守のために十分な財源を維持する (SHALL)。 CAは、EV Guidelinesのそれぞれの履行および義務に関連して、以下の保険を維持する (SHALL)。 A. 保険限度額が少なくとも 200万米ドルの商業総合賠償責任保険（発生型）。 B. 専門職賠償責任保険/過失責任保険。補償限度額は少なくとも 500万米ドルで、以下の補償が含まれる。 - i. 行為、過失、不作為、意図しない契約違反、またはEV証明書の発行または維持における怠慢から生じる損害賠償請求 - ii. 第三者の所有権の侵害（著作権、商標権の侵害を除く）、プライバシーの侵害、広告の損害から生じる損害賠償請求。 このような保険は、Best の保険ガイドの最新版で保険契約者の格付けが A- 以上の会社 (または各メンバーがそのような格付けを受けている会社協会) と契約しなければならない。CAは、過去 12か月間の監査済み財務諸表に基づいて少なくとも 5億米ドルの流動資産があり、当座比率 (流動資産と流動負債の比率) が 1.0以上であることを条件に、これらのガイドラインに基づく当事者の履行および義務から生じる負債について自己保険をかけることができる (MAY)。 ### 9.2.2 Other assets 9.2.2 その他の資産 規定しない。 ### 9.2.3 Insurance or warranty coverage for end-entities 9.2.3 エンドエンティティに対する保険または保証範囲 規定しない。 ## 9.3 Confidentiality of business information 9.3 企業情報の機密保持 ### 9.3.1 Scope of confidential information 9.3.1 機密情報の範囲 セコムトラストシステムズが所有する個人および組織に関する情報は、証明書、CRL、本 CP/CPSの一部として明示的に公開されたものを除き、機密保持の対象となる。 セコムトラストシステムズは、法律で義務付けられている場合、または関連する利用者の事前の同意がある場合を除き、そのような情報を外部に開示しない。セコムトラストシステムズは、法律で義務付けられている法律、司法、行政またはその他の手続きに関連してアドバイスを提供する法律顧問または財務アドバイザーに機密情報を開示する場合がある。また、企業の合併、買収、または再編に関するアドバイスを提供する弁護士、会計士、法的機関、またはその他の専門家に機密情報を開示する場合がある。 利用者の私有鍵は、利用者自身の責任において秘密に保持されるべき情報とみなされる。いかなる場合も、本サービスはこれらの鍵へのアクセスを提供しない。監査ログおよび監査レポートに含まれる情報自体は機密保持の対象であり、機密情報の範囲内である。セコムトラストシステムズは、[Section 8.6](#86-communication-of-results) に規定されている場合、または法律で要求されている場合を除き、そのような情報を外部に開示しない。 ### 9.3.2 Information not within the scope of confidential information 9.3.2 機密情報の範囲外の情報 証明書およびCRLに入力された情報は機密情報とはみなされない。また、以下の情報は、本機密保持規定の対象にはならない。 - セコムトラストシステムズの責によらずに知り得た、または知った情報。 - セコムトラストシステムズ以外の当事者から機密保持義務なしにセコムトラストシステムズに知らされた、または知らされる情報。 - セコムトラストシステムズが独自に開発した情報 - 当該利用者により開示が承認された情報。 ### 9.3.3 Responsibility to protect confidential information 9.3.3 機密情報の保護責任 セコムトラストシステムズは、法令に基づき開示を求められた場合、または契約者の事前の同意がある場合には、秘密情報を開示することがある。この場合、情報を入手した当事者は、契約上または法律上の制約により、当該情報を第三者に開示することができない。 ## 9.4 Privacy of personal information 9.4 個人情報保護方針 ### 9.4.1 Privacy plan 9.4.1 個人情報保護プラン セコムトラストシステムズは、当社の認証サービス利用者から収集した個人情報を、申込内容の確認、必要書類等の送付、本人確認など、電子認証基盤上で運用する本CAの運営に必要な範囲で利用する。 セコムトラストシステムズのプライバシーポリシーは、セコムトラストシステムズのホームページ（）で公表する。 ### 9.4.2 Information treated as private 9.4.2 個人情報として扱われる情報 セコムトラストシステムズは、国内法令に基づき個人情報と定義される情報（セコム認証サービスの加入者から収集した情報等）を個人情報として取り扱い、適切に管理する。 ### 9.4.3 Information not deemed private 9.4.3 個人情報と見なされない情報 セコムトラストシステムズは、個人情報を [Section 9.4.2](#942-information-treated-as-private) に規定されているとおりに取り扱う。 ### 9.4.4 Responsibility to protect private information 9.4.4 個人情報の保護責任 セコムトラストシステムズは、契約の締結および終了にあたり知り得た相手方の個人情報を、契約期間中、契約終了後を問わず第三者に開示しない。また、個人情報保護管理者を置き、従業員に個人情報保護方針を遵守させる。 ### 9.4.5 Notice and consent to use private information 9.4.5 個人情報利用に関する通知と同意 セコムトラストシステムズは、法令に定める場合を除き、証明書利用者の同意を得る目的以外で個人情報を利用しない。個人番号および特定個人情報は、法令で認められた利用目的および証明書利用者の同意を得た利用目的のために利用されている。 ### 9.4.6 Disclosure pursuant to judicial or administrative process 9.4.6 司法または行政手続に沿った情報開示 法令、規則、裁判所の決定・命令、行政機関の命令・指示等により開示を求められた場合、証明書利用者の個人情報は開示されることがある。 ### 9.4.7 Other information disclosure circumstances 9.4.7 その他の情報開示要件 規定しない。 ## 9.5 Intellectual property rights 9.5 知的財産権 セコムトラストシステムズと利用者との間で別段の合意がない限り、本サービスに関する以下の情報資料およびデータは、以下に定める当事者に帰属する。 | 所有物 | 詳細 | | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 証明書 | セコムトラストシステムズが所有する資産 | | CRL | セコムトラストシステムズが所有する資産 | | 識別名 (DN) | 利用者証明書の料金が適切に支払われている限り、名前が割り当てられたエンティティに属する資産。 | | 利用者私有鍵 | 保存方法や保存媒体の所有者に関係なく、公開鍵と鍵ペアを完成させる私有鍵の所有者に属する資産。 | | 利用者公開鍵 | 保管方法や保管媒体の所有者に関係なく、鍵ペアを完成させる私有鍵の所有者に属する資産。 | | 本CP/CPS | セコムトラストシステムズに帰属する資産（著作権を含む）。本CP/CPS は、元の文書が適切に参照されている限り複製できる。これは、クリエイティブコモンズライセンス Attribution-NoDerivatives (CC-BY-ND) 4.0 に基づいて公開されている。 | ## 9.6 Representations and warranties 9.6 表明および保証 ### 9.6.1 CA representations and warranties 9.6.1 CAの表明および保証 証明書を発行することにより、CAは以下の証明書受益者に対してここに記載されている証明書保証を行う。 1. 利用者契約または証明書の使用条件の当事者である利用者。 2. Root CAが、そのアプリケーションソフトウェアサプライヤーが配布するソフトウェアにルート証明書を含める契約を締結したすべてのアプリケーションソフトウェアサプライヤー 3. 有効な証明書に合理的に依存するすべての検証者。CAは、証明書の有効期間中、証明書の発行および管理において Baseline Requirements およびCP/CPSに準拠していることを証明書受益者に表明し、保証する。 証明書保証には具体的には以下の内容が含まれるが、これらに限定されない。 1. **ドメイン名の使用権 [TLSサーバー証明書]**: 発行時にCAは、 i. 申請者が証明書の `subject` フィールドと `subjectAltName` 拡張に記載されているドメイン名を使用する権利または管理権を持っていることを確認する手順を実装した (または、ドメイン名の場合のみ、使用または管理権を持つ人物からそのような権利または管理権が委任された)。 ii. 証明書を発行する際の手順に従った。 iii. CAのCP/CPSに手順を正確に記載した。 2. **メールボックスアドレスの使用権 [S/MIME 証明書]**: 発行時にCAは、 i. 申請者が証明書の `subject` フィールドと `subjectAltName` 拡張に記載されているメールボックスアドレスを使用する権利、または管理権を持っていることを確認する手順を実装した（または、そのような使用権または管理権を持つ人物からそのような権利または管理権が委任された）。 ii. 証明書を発行する際にその手順に従った。 iii. CA の CP/CPS にその手順を正確に記載した。 3. **コンプライアンス**. CAは、各証明書の発行およびPKIまたは委任サービスの運用において、[Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) の標準、基準、規制に準拠している。 4. **証明書の承認**: 発行時にCAは、 i. 対象者が証明書の発行を承認したことおよび申請者代表が対象者に代わって証明書を要求する権限を持っていることを確認する手順を実装した。 ii. 証明書を発行する際の手順に従った。 iii. CAのCP/CPSに手順を正確に記載した。 5. **情報の正確性**: 発行時にCAは、 i. 証明書に含まれるすべての情報の正確性を検証するための手順を実施した。 ii. 証明書を発行する際の手順に従った。 iii. CAのCP/CPSに手順を正確に記載した。 6. **鍵の保護:** CAは、コードサイニング証明書およびAATLドキュメントサイニング証明書に関連付けられた私有鍵を安全に保管し、不正使用を防止する方法に関するドキュメントを発行時に利用者に提供したことを表明する。 7. **申請者の身元**: 証明書に主体者識別名識別情報が含まれている場合、CAは、 i. [Section 3.2](#32-initial-identity-validation) および [Section 7.1.2](#712-certificate-content-and-extensions)に従って申請者の身元を確認する手順を実施した。 ii. 証明書を発行する際の手順に従った。 iii. CAのCP/CPSに手順を正確に記載した。 8. **利用者契約**: CAと利用者が提携関係にない場合、利用者とCAは、[Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) を満たす法的に有効かつ強制力のある利用利用者契約の当事者である、またはCAと利用者が同じ組織であるか提携関係にある場合、申請者代表は利用規約を承認している。 9. **ステータス**: CAは、有効期限内のすべての証明書のステータス (有効または失効) に関する最新情報を24時間365日公開可能なリポジトリーに保持する。 10. **失効**: CAは、[Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations)に指定されたいずれかの理由により証明書を失効する。 Root CAは、Root CAが証明書を発行する下位CAであるかのように、下位CAの履行と保証、下位CAの [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations)への準拠および [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) に基づく下位CAのすべての責任と補償義務について責任を負う (SHALL)。 ### 9.6.2 RA representations and warranties 9.6.2 RAの表明および保証 本CP/CPS [Section 9.6.1](#961-ca-representations-and-warranties) と同様。 ### 9.6.3 Subscriber representations and warranties 9.6.3 利用者の表明および保証 CAは、利用者契約または利用規約の一部として、申請者がCAおよび証明書受益者の利益のためにこの section の約束と保証を行うことを要求する (SHALL)。 証明書を発行する前に、CAはCAと証明書受益者の明確な利益のために、次のいずれかを取得する (SHALL)。 1. CAとの利用者契約に対する申請者の合意 2. 利用規約に対する申請者の承認 CAは、各利用者契約または利用規約が申請者に対して法的に強制可能であることを保証するプロセスを実装する (SHALL)。いずれの場合も、契約は証明書要求に従って発行される証明書に適用されなければならない (MUST)。CAは、そのような契約が法的に強制可能であるとCAが判断した場合に限り、電子契約または「クリックスルー」契約を使用できる (MAY)。CAが申請者に発行する各証明書が利用者契約または利用規約によって明確にカバーされている限り、証明書要求ごとに個別の契約を使用することも、将来の複数の証明書要求とその結果の証明書をカバーするために単一の契約を使用することもできる (MAY)。 利用契約書または利用規約には、申請者自身（または下請業者もしくはホスティングサービス関係の下で申請者がその委託者または代理人に代わって行う）に課す以下の義務および保証に関する規定が含まれていなければならない (MUST)。 1. **情報の正確性**: 証明書要求内において、また証明書の発行に関連してCAから要求された場合において、常に正確で完全な情報をCAに提供する義務および保証。 2. **私有鍵の保護**: 申請者は、要求された証明書に含まれる公開鍵に対応する私有鍵（および関連するアクティベーションデータやデバイス、パスワードやトークンなど）を常に管理し、機密性を保ち、適切に保護するためにあらゆる合理的な措置を講じる義務と保証を負う。
**[コードサイニング証明書]**
署名サービス外で鍵が利用可能な場合、要求された証明書に含まれる公開鍵に対応する私有鍵（および関連するアクティベーションデータやデバイス、たとえばパスワードやトークン）を、[Section 6.2.7](#627-private-key-storage-on-cryptographic-module) に従って常に単独で管理し、機密性を保ち、適切に保護する。CAは、私有鍵を保護する方法に関するドキュメントを利用者に提供しなければならない (MUST)。CAは、このドキュメントをホワイトペーパーとして、または利用者契約の一部として提供できる (MAY)。利用者は、コードサイニングのベストプラクティスのドキュメントに記載されているように、私有鍵を格納するデバイスを安全な方法で生成および操作することを表明しなければならない (MUST)。このベストプラクティスは、CAが注文プロセス中に利用者に提供しなければならない (MUST)。CAは、私有鍵を転送するために、大文字、小文字、数字および記号を含む 16文字以上でランダムに生成されたパスワードを使用することを利用者に義務付けなければならない (MUST)。 3. **私有鍵の再利用 [コードサイニング証明書]**: 証明書内の公開鍵が非コードサイニング証明書で使用されている場合、または使用される予定がある場合は、コードサイニング証明書を申請しない。 4. **証明書の使用 [コードサイニング証明書]**: 証明書および関連する私有鍵は、許可された合法的な目的にのみ使用する。これには、証明書を使用して疑わしいコードに署名しないことおよび証明書と私有鍵をすべての適用法に準拠し、利用者契約または利用規約に従ってのみ使用することが含まれる。 5. **証明書の使用 [TLSサーバー証明書]**: 証明書に記載されている `subjectAltName` でアクセス可能なサーバーにのみ証明書をインストールし、適用されるすべての法律を遵守し、利用者契約または利用規約に従ってのみ証明書を使用する義務と保証。 6. **報告と失効**: 以下の義務および保証: a. 証明書に含まれる公開鍵に関連付けられた利用者の私有鍵の不正使用または危殆化が実際に発生しているか、またはその疑いがある場合は、すみやかに証明書の失効を要求し、証明書および関連する私有鍵の使用を中止する。 b. 証明書内の情報が間違いまたは不正確である場合、もしくは間違いまたは不正確になった場合は、直ちに証明書の失効を要求し、証明書の使用を中止する。 7. **業界標準への準拠**: [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) の変更に準拠するために、CAが必要に応じて利用者契約または利用規約を変更する場合があることを認識し、承諾する。 8. **不正使用の防止:** 私有鍵の不正使用を防ぐために適切なネットワークおよびその他のセキュリティ制御を提供し、私有鍵への不正アクセスがあった場合にはCAが事前の通知なしに証明書を失効する。 9. **証明書受領確認**: 利用者が証明書の内容を確認し、正確性を確認する義務と保証。 10. **情報の共有 [コードサイニング証明書]**: (a) 証明書または申請者が疑わしいコードのソースとして特定された場合、(b) 証明書を要求する権限が確認できない場合、または (c) 利用者の要求以外の理由 (私有鍵危殆化、マルウェアの発見など) で証明書が失効した場合、CAは申請者、署名済みアプリケーション、証明書および周囲の状況に関する情報を、CA/ブラウザフォーラムを含む他のCAまたは業界グループと共有することを許可されることを認め、承諾する。 11. **証明書の使用終了**: 鍵危殆化を理由に証明書が失効した場合、証明書に含まれる公開鍵に対応する私有鍵のすべての使用を直ちに停止する義務および保証。証明書の有効期限が切れた場合または失効した場合、証明書に記載されている公開鍵に対応する私有鍵の使用を直ちに停止すること。 12. **応答性**: 指定された期間内に、鍵危殆化または証明書の不正使用に関するCAの指示に応じる義務。 13. **承認と承諾**: 申請者が利用者契約または利用規約の条件に違反した場合、またはCP/CPSあるいは [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) によって失効が要求された場合、CA は証明書を直ちに失効する権利を有することを承認し、承諾する。 ### 9.6.4 Relying party representations and warranties 9.6.4 検証者の表明および保証 CAサービスの検証者には、以下の義務がある。 - CAによって発行された証明書を信頼し、本CP/CPSでこのCAによって指定された目的にのみ証明書を使用する。 - 証明書を信頼しようとするときは、リポジトリー内のCRLまたはOCSPレスポンダーによって証明書が失効されていないことを確認する。 - 証明書を信頼する場合は、証明書の有効期間を確認し、有効期間内であることを確認する。 - このCAによって発行された証明書を信頼する場合は、証明書がCAの証明書によって署名および検証できることを確認する。 - CAの証明書を信頼して使用する場合、本CP/CPSで指定されているように、検証者として責任を負うことに同意する。 ### 9.6.5 Representations and warranties of other participants 9.6.5 その他関係者の表明および保証 規定しない。 ## 9.7 Disclaimers of warranties 9.7 保証の免責 CAは、[Section 9.6.1](#961-ca-representations-and-warranties) および [Section 9.6.2](#962-ra-representations-and-warranties) に規定されている保証に関連して発生する直接的、特別、偶発的または結果的な損害、または逸失利益、データ損失、またはその他の間接的または結果的な損害について責任を負わない。 ## 9.8 Limitations of liability 9.8 責任の制限 本CP/CPSにおいて、CAは、以下の場合には、本CP/CPSの「9.6.1 CAの表明および保証」および「9.6.2 RAの表明および保証」の規定について責任を負わない。 - 違法行為、無許可使用、過失、またはCAに帰責事由のないその他の原因から生じた損害。 - 確認された情報の誤りが申請者の詐欺または故意の不正行為の結果である場合、いかなる場合でも一切の責任を負わない。 - 利用者が義務を履行しなかったことに起因する損害。 - 利用者または検証者のシステムに起因する損害。 - 利用者の環境（ハードウェアまたはソフトウェア）の欠陥、故障、またはその他の動作に起因する損害 - 利用者が契約書に定められた加入料の支払いを怠った期間中に生じた損害。 - CAに帰責事由のない理由により、証明書、CRL、またはOCSPレスポンダーに公開された情報によって生じた損害。 - CAの責任に帰責事由によらない理由により正常な通信が停止したことにより生じた損害。 - 取引債務を含む証明書の使用に関連して生じる損害。 - 委託先によるサービス提供義務の不履行（委託先によるサービス提供の終了など）により生じた損害。 - 現時点での予想を超えるハードウェアまたはソフトウェアの暗号アルゴリズムの解読技術の向上に起因する損害。 - 自然災害、地震、噴火、火災、津波、洪水、落雷、戦争、内乱、テロリズムなど、不可抗力によりCAの業務が停止したことに起因する損害。 ## 9.9 Indemnities 9.9 補償 利用者および検証者に対する責任の制限があっても、CAは、ルート認証局とルート証明書配布契約を締結しているアプリケーションソフトウェアサプライヤーが、 [Section 1.1.1 Standards, Criteria and Regulations](#111-standards-criteria-and-regulations) に基づく、あるいは証明書の発行・維持、またはそれに対する信頼によって発生する可能性のある認証局の義務や責任を一切負わないことを理解し、認める。 CAは、CAが発行した証明書に関連してアプリケーションソフトウェアサプライヤーが被ったすべての請求、損害および損失について、その請求原因や法的理論にかかわらず、アプリケーションソフトウェアサプライヤーを擁護し、補償・損害を負わせないものとする。 ただし、当該アプリケーションソフトウェアサプライヤーのソフトウェアが、以下のいずれかの方法で証明書を誤って表示したことにより直接引き起こされた請求、損害、または損失には適用されない。 1. 有効な証明書を信頼できないものとして表示した場合 2. 以下の証明書を信頼できるものとして表示した場合 - 有効期限が切れた証明書 - 失効済みの証明書（ただし、その失効ステータスがCAからオンラインで現在取得可能であり、かつアプリケーションソフトウェアがそのステータスを確認しなかった、または失効の表示を無視した場合に限る） ## 9.10 Term and termination 9.10 CP/CPSの効力開始と終了 ### 9.10.1 Term 9.10.1 CP/CPSの効力開始 本CP/CPSは、認証サービス改善委員会の承認を得て発効する。 本CP/CPSは、[Section 9.10.2](#9102-termination) に規定される終了までは、いかなる状況においても効力を失うことはない。 ## 9.10.2 Termination 9.10.2 CP/CPSの効力終了 本CP/CPSは、[Section 9.10.3](#9103-effect-of-termination-and-survival) に規定されている規定を除き、CAによる本CP/CPSの終了と同時に効力を失う。 ### 9.10.3 Effect of termination and survival 9.10.3 CP/CPSの効力継続 利用者による証明書の使用が終了した場合、または外部委託先が提供するサービスが終了した場合、もしくはCAが事業を停止した場合であっても、その性質上有効に存続すべき規定は、その理由にかかわらず、かかる終了後も存続し、加入者およびCAに関して完全に効力を維持する。 ## 9.11 Individual notices and communications with participants 9.11 関係者への個別通知および連絡 CAは外部委託先に必要な通知を提供し、外部委託先は、Web サイト、Email、またはその他の書面形式を通じて利用者および検証者に必要な通知を提供する。 ## 9.12 Amendments 9.12 改訂 ### 9.12.1 Procedure for amendment 9.12.1 改訂手続 1. 重要な改訂/修正 セコムは、本CP/CPSの改訂が利用者および検証者による証明書またはCRLの使用活動に明らかな影響を及ぼすと判断される場合、改訂後の本CP/CPS(バージョン履歴/説明/日付を含む) をリポジトリーに公開し、メジャーバージョン番号を更新することにより、利用者および検証者に本CP/CPSの改訂を通知する。 2. 重要でない改訂/修正 セコムは、本CP/CPSの改訂が利用者および検証者による証明書またはCRLの使用活動に影響を及ぼさないか、または影響が小さいと判断される場合、改訂後の本CP/CPS (バージョン履歴/説明/日付を含む) をリポジトリーに公開し、マイナーバージョン番号を更新することにより、利用者および検証者に本CP/CPSの改訂を通知する。 本CP/CPSは、CAによって適宜改訂され、認証サービス委員会の承認を得て発効される。 ### 9.12.2 Notification mechanism and period 9.12.2 通知方法および期間 本CP/CPSが改訂/修正された場合、改訂後の本CP/CPS (バージョン履歴/説明/日付を含む) がリポジトリーにすみやかに公開されることをもって、利用者および検証者への通知とみなす。利用者は、当該通知後 1 週間以内に請求を行うことができるが、当該期間内に請求が行われない場合、本CP/CPSの改訂後のバージョンは利用者により承認されたものとみなされる。本CP/CPSが変更された場合は、改訂後のCP/CPSがすみやかに公開されることをもって、関係者への通知とみなす。 ### 9.12.3 Circumstances under which OID must be changed 9.12.3 OIDが変更されなければならない要件 認証サービス向上委員会が必要と判断した場合、OID は変更されるものとする。 ## 9.13 Dispute resolution provisions 9.13 紛争解決手続 CAが発行した証明書に関する紛争の解決のため、CAに対して訴訟を提起し、仲裁を請求し、その他の法的措置を取ろうとする当事者は、事前にその旨をCAに通知するものとする。仲裁および裁判手続きの場所については、東京に所在する紛争解決機関が専属管轄権を有するものとする。 ## 9.14 Governing law 9.14 準拠法 CA、利用者、または検証者の所在地に関わらず、本CP/CPSの解釈または有効性に関する紛争については日本の法律が適用される。仲裁および裁判手続きの場所については、当事者は東京にある紛争解決機関の専属管轄権に従う。 ## 9.15 Compliance with applicable law 9.15 適用法の遵守 CAは、日本の関連輸出規制に従って暗号ハードウェアおよびソフトウェアを取り扱うものとする。 ## 9.16 Miscellaneous provisions 9.16 雑則 ### 9.16.1 Entire agreement 9.16.1 完全合意条項 セコムトラストシステムズは、本サービスの提供にあたり、利用者および検証者の義務およびその他の関連事項を本CP/CPSおよびサービス規約に包括的に規定する。口頭または書面によるその他の合意は、いかなる効力も有しないものとする。 ### 9.16.2 Assignment 9.16.2 権利譲渡条項 セコムトラストシステムズは、サービスを第三者に譲渡する場合、本CP/CPSおよびサービス規約に規定される責任およびその他の義務を譲渡することができる。 ### 9.16.3 Severability 9.16.3 分離条項 本CP/CPS、サービス規約のいずれかの規定が無効と判断された場合でも、そこに規定されているその他の規定はすべて完全に効力を維持する。 Baseline Requirements と、CAが運用または証明書を発行する法域の法律、規制、または政府命令 (以下、「法律」) との間に矛盾がある場合、CAは、その法域で要件を有効かつ合法にするために必要な最小限の範囲で、矛盾する Baseline Requirements を修正することができる (MAY)。これは、その法律の対象となる運用または証明書の発行にのみ適用される。このような場合、CAは、修正された要件に基づいて証明書を発行する前に、CAのCP/CPSの [Section 9.16.3](#9163-severability) に、この section に基づいてBaseline Requirements の修正を要求する法律への詳細な参照およびCAによって実装された Baseline Requirements への具体的な修正を直ちに盛り込むものとする (SHALL)。 また、CAは (修正された要件に基づいて証明書を発行する前に)、CP/CPSに新しく追加された関連情報をCA/ブラウザフォーラムに通知しなければならない (MUST)。通知するには、`questions [at] cabforum [dot] org` にメッセージを送信し、その情報がパブリックメーリングリストに投稿され、 (またはフォーラムが指定するその他のEmailアドレスとリンク) で利用可能なパブリックメールアーカイブにインデックス登録されたことの確認を受け取る。これにより、CA/ブラウザフォーラムは、それに応じて Baseline Requirements の可能な改訂を検討できる。 この section に基づいて可能になったCAの慣行に対する変更は、法律が適用されなくなった場合、または Baseline Requirements が修正されて Baseline Requirements と法律の両方に同時に準拠できるようになった場合には、中止しなければならない (MUST)。適切な慣行の変更、CAのCP/CPSの修正および CA/ブラウザフォーラムへの通知は、上記で概説したように、90 日以内に行わなければならない (MUST)。 ### 9.16.4 Enforcement (attorneys' fees and waiver of rights) 9.16.4 強制執行条項 本サービスに関する紛争は東京地方裁判所を管轄裁判所とするものとし、セコムトラストシステムズは、各規制文書の契約条項から生じる紛争、当事者の行為に関連する損害、損失、費用について、当事者に対し、賠償金および弁護士費用を請求できるものとする。 ### 9.16.5 Force Majeure 9.16.5 不可抗力条項 セコムトラストシステムズは、予見可能か否かを問わず、自然災害、地震、噴火、火災、津波、洪水、落雷、騒乱、テロ行為、その他不可抗力により生じた損害について一切責任を負わないものとする。本CAの提供が不可能となった場合、セコムトラストシステムズは、その事態が収束するまで本CAの提供を停止することがある。 ## 9.17 Other provisions 9.17 その他条項 規定しない。 # APPENDIX A – CAA Contact Tag 付録 A – CAA連絡先タグ これらの方法により、ドメイン所有者はドメイン制御を検証する目的で DNS に連絡先情報を公開できる。 ## A.1. CAA Methods A.1 CAAメソッド ### A.1.1. CAA contactemail Property A.1.1 contactemail プロパティ SYNTAX: `contactemail ` CAA contactemail プロパティは、Emailアドレスをパラメーターとして受け取る。パラメーター値全体は、RFC 6532 のSection 3.2 で定義されている有効なEmailアドレスでなければならず (MUST)、追加のパディングや構造は含まれない。そうでない場合、使用できない。 以下は、ドメインの所有者がEmailアドレスを使用して連絡先プロパティを指定した例である。 ```DNS Zone $ORIGIN example.com. CAA 0 contactemail "domainowner@example.com" ``` ドメイン所有者が、contactemail プロパティを理解していないCAがドメインの証明書を発行することを望まない場合、contactemail プロパティは重要になる可能性がある (MAY)。 ### A.1.2. CAA contactphone Property A.1.2 CAA contactphone プロパティ SYNTAX: `contactphone ` CAA contactphone プロパティは、電話番号をパラメーターとして受け取る。パラメーター値全体は、RFC 3966 のSection 5.1.4 で定義されている有効なグローバル番号でなければならない (MUST)。そうでない場合は使用できない。グローバル番号の前には + と国コードがなければならず (MUST)、視覚的な区切り文字を含めることができる (MAY)。 以下は、ドメインの所有者が電話番号を使用して連絡先プロパティを指定した例である。 ```DNS Zone $ORIGIN example.com. CAA 0 contactphone "+81 (3) 1234-5678" ``` ドメイン所有者が、contactphone プロパティを理解していないCAがドメインの証明書を発行することを望まない場合、contactphone プロパティは重要になる可能性がある(MAY)。 ## A.2. DNS TXT Methods A.2 DNS TXT メソッド ### A.2.1. DNS TXT Record Email Contact A.2.1 DNS TXT Record Email連絡先 DNS TXT レコードは、検証対象のドメインの「`_validation-contactemail`」サブドメインに配置しなければならない (MUST)。この TXT レコードの RDATA 値全体は、RFC 6532 のSection 3.2 で定義されている有効なEmailアドレスでなければならず (MUST)、追加のパディングや構造は含まれない。そうでない場合、使用できない。 ### A.2.2. DNS TXT Record Phone Contact A.2.2 DNS TXT Record 電話連絡先 DNS TXT レコードは、検証対象のドメインの「`_validation-contactphone`」サブドメインに配置しなければならない (MUST)。この TXT レコードの RDATA 値全体は、RFC 3966 のSection 5.1.4 で定義されている有効なグローバル番号でなければならず(MUST)、そうでない場合は使用できない。 # APPENDIX B – Certificate profile 付録 B – 証明書プロファイル ## Table : "Security Communication RootCA2" and Subordinate CAs Root CA 証明書 SHA256 フィンガープリント: 513B2CECB810D4CDE5DD85391ADFC6C2DD60D87BB736D2B521484AA47A0EBEF6 | 基本フィールド | 説明 | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | version | 3 (0x2) | | serialNumber | Root CAの場合
0

下位 CA の場合
CA内での一意な値 | | signature | sha256WithRSAEncryption | | issuer | C = JP
O = SECOM Trust Systems CO.,LTD.
OU = Security Communication RootCA2 | | validity | Root CAの場合
開始: 2009年5月29日 05:00:39 GMT
終了: 2029年5月29日 05:00:39 GMT

下位 CA の場合
開始: 証明書発行日
終了: [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) に規定されているとおりに設定 | | subject | Root CAの場合
C = JP
O = SECOM Trust Systems CO.,LTD.
OU = Security Communication RootCA2

下位 CA の場合
下位CA利用者情報を設定 | | subjectPublicKeyInfo | Root CAの場合
公開鍵アルゴリズム: rsaEncryption
Public-Key: 2048 bit

下位 CA の場合
公開鍵アルゴリズム識別子と下位CA利用者の公開鍵データ | | 拡張フィールド | 説明 | critical | | -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | | authorityKeyIdentifier | SHA-1を使用しCA公開鍵をハッシュして得られた160ビットの値 | N | | subjectKeyIdentifier | SHA-1を使用し利用者の公開鍵をハッシュして得られた160ビットの値 | N | | keyUsage | keyCertSign, cRLSign（利用者公開鍵の使用目的） | Y | | extendedKeyUsage | 2019-01-01 以降は必ず設定。ただし、anyExtendedKeyUsage は設定しない。
id-kp-serverAuth と id-kp-emailProtection を同時に設定しない。
id-kp-codeSigning を個別に設定。
クロス証明書の場合は、必要に応じて設定。 | N | | certificatePolicies | policyIdentifier
- certPolicyId=1.2.392.200091.100.901.4、CA/ブラウザフォーラム予約済み証明書ポリシー識別子（これが含まれていて2023-09-15以降に発行された場合は、最初に設定することを推奨）、1.2.392.200091.100.721.1 またはany Policy \*1
policyQualifiers
- policyQualifierID=id-qt-cps
- qualifier=CPS=`http(s)://repository.secomtrust.net/SC-Root2/`
\* （）はオプション
policyQualifier は TLS DV/OV CA の場合、非推奨 | N | | basicConstraints | Subject Type=CA
pathLenConstraints（必要に応じてCAで設定） | Y | | nameConstraints | 存在する場合は、Critical に設定する必要あり。 | Y | | cRLDistributionPoints | URI: `http://repository.secomtrust.net/SC-Root2/SCRoot2CRL.crl` | N | | authorityInformationAccess | accessMethod
OCSP (1.3.6.1.5.5.7.48.1)
accessLocation
URI :`http://scrootca2.ocsp.secomtrust.net`
accessMethod
CA Issuers (1.3.6.1.5.5.7.48.2)
accessLocation
URI: `http://repository.secomtrust.net/SC-Root2/SCRoot2ca.cer`
\* 必要に応じてOCSP、CA Issuersを設定 | N | \*1 EV証明書を発行する場合は、OID（1.2.392.200091.100.721.1）またはEV証明書のany Policyを設定できる。2023年9月15日以降に発行する場合は、「CA/ブラウザフォーラム予約済み証明書ポリシー識別子とEV証明書OID（1.2.392.200091.100.721.1）」または「any Policy」（CAが下位CAのCAキーを管理する場合）を設定できる。 --- ## Table : "Security Communication RootCA3" and Subordinate CAs Root CA 証明書 SHA256 フィンガープリント: 24A55C2AB051442D0617766541239A4AD032D7C55175AA34FFDE2FBC4F5C5294 | 基本フィールド | 説明 | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | version | 3 (0x2) | | serialNumber | Root CAの場合
E17C3740FD1BFE67

下位CAの場合
CA内の一意な値 | | signature | sha384WithRSAEncryption | | issuer | C = JP
O = SECOM Trust Systems CO.,LTD.
CN = Security Communication RootCA3 | | validity | Root CAの場合
開始: 2016年6月16日 06:17:16 GMT
終了: 2038年1月18日 06:17:16 GMT

下位CAの場合
開始: 証明書発行日
終了: [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) に規定されているとおりに設定 | | subject | Root CAの場合
C = JP
O = SECOM Trust Systems CO.,LTD.
CN = Security Communication RootCA3

下位CAの場合
下位CA利用者情報を設定 | | subjectPublicKeyInfo | Root CAの場合
公開鍵アルゴリズム: rsaEncryption
Public-Key: 4096 bit

下位CAの場合
公開鍵アルゴリズム識別子と下位CA利用者の公開鍵データ | | 拡張フィールド | 説明 | critical | | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | | authorityKeyIdentifier | SHA-1を使用してCA公開鍵をハッシュして得られた160ビットの値 | N | | subjectKeyIdentifier | SHA-1を使用して利用者の公開鍵をハッシュして得られた160ビットの値 | N | | keyUsage | keyCertSign, cRLSign（利用者公開鍵の利用目的） | Y | | extendedKeyUsage | 2019-01-01 以降は必ずこれを設定するが、anyExtendedKeyUsage は設定しない。
次のいずれかを設定 :
(1) id-kp-serverAuth
(2) id-kp-serverAuth and id-kp-clientAuth
(3)Adobe Authentic Documents Trust (1.2.840.113583.1.1.5)
(4) Microsoft Signer of documents (1.3.6.1.4.1.311.10.3.12）
(5) id-kp-codeSigning
(6) id-kp-timeStamping
クロス証明書の場合は、必要に応じて設定。
(3)と(4)は同時に設定することも可能。 | N | | certificatePolicies | policyIdentifier
- certPolicyId=1.2.392.200091.100.901.6,
CA/ブラウザフォーラム予約済み証明書ポリシー識別子 (これが含まれていて 2023-09-15 以降に発行された場合は、最初に設定することを推奨)
policyQualifiers
- policyQualifierID=id-qt-cps
- qualifier=CPS=`http(s)://repository.secomtrust.net/SC-Root3/`
\* ()はオプション
policyQualifier は TLS DV/OV CA の場合、非推奨 | N | | basicConstraints | Subject Type=CA
pathLenConstraints（必要に応じてCAで設定） | Y | | nameConstraints | 存在する場合は、Critical に設定する必要あり。 | Y | | cRLDistributionPoints | URI: `http://repository.secomtrust.net/SC-Root3/SCRoot3CRL.crl` | N | | authorityInformationAccess | accessmethod
OCSP (1.3.6.1.5.5.7.48.1)
accessLocation
URI: `http://scrootca3.ocsp.secomtrust.net`
accessMethod
CA Issuers (1.3.6.1.5.5.7.48.2)
accessLocation
URI: `http://repository.secomtrust.net/SC-Root3/SCRoot3ca.cer`
\* 必要に応じてOCSP、CA Issuersを設定。 | N | --- ## Table : "Security Communication ECC RootCA1" and Subordinate CAs Root CA 証明書 SHA256 フィンガープリント: E74FBDA55BD564C473A36B441AA799C8A68E077440E8288B9FA1E50E4BBACA11 | 基本フィールド | 説明 | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | version | 3 (0x2) | | serialNumber | Root CAの場合
D65D9BB378812EEB

下位CAの場合
CA内での一意な値 | | signature | ecdsa-with-SHA384 | | issuer | C = JP
O = SECOM Trust Systems CO.,LTD.
CN = Security Communication ECC Root CA1 | | validity | Root CAの場合
開始: 2016年6月16日 05:15:28 GMT
終了: 2038年1月18日 05:15:28 GMT

下位CAの場合
開始: 証明書発行日
終了: [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) に規定されているとおりに設定。 | | subject | Root CAの場合
C = JP
O = SECOM Trust Systems CO.,LTD.
CN = Security Communication ECC Root CA1

下位CAの場合
下位CA利用者情報を設定 | | subjectPublicKeyInfo | Root CAの場合
公開鍵アルゴリズム: id-ecPublicKey
Public-Key: 384 bit

下位CAの場合
公開鍵アルゴリズム識別子と下位CA利用者の公開鍵データ | | 拡張フィールド | 説明 | critical | | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | | authorityKeyIdentifier | SHA-1を使用してCA公開鍵をハッシュして得られた160ビットの値 | N | | subjectKeyIdentifier | SHA-1を使用して利用者の公開鍵をハッシュして得られた60ビットの値 | N | | keyUsage | keyCertSign, cRLSign（利用者公開鍵の利用目的） | Y | | extendedKeyUsage | 次のいずれかを設定
(1) id-kp-serverAuth
(2) id-kp-serverAuth and id-kp-clientAuth
クロス証明書の場合は、必要に応じて設定。 | N | | certificatePolicies | policyIdentifier
- CA/ブラウザフォーラム予約済み証明書ポリシー識別子 (これが含まれていて 2023-09-15 以降に発行された場合は、最初に設定することを推奨)、 certPolicyId=1.2.392.200091.100.902.1
policyQualifiers
- policyQualifierID=id-qt-cps
- qualifier=CPS=`http(s)://repository.secomtrust.net/SC-ECC-Root1`/
\* () はオプション
policyQualifier は TLS DV/OV CA の場合、非推奨 | N | | basicConstraints | Subject Type=CA
pathLenConstraints（必要に応じて設定） | Y | | nameConstraints | 存在する場合は、Critical に設定する必要あり。 | Y | | cRLDistributionPoints | URI: `http://repository.secomtrust.net/SC-ECC-Root1/SCECCRoot1CRL.crl` | N | | authorityInformationAccess | accessMethod
OCSP (1.3.6.1.5.5.7.48.1)
accessLocation
URI: `http://sceccrootca1.ocsp.secomtrust.net`
accessMethod
CA Issuers (1.3.6.1.5.5.7.48.2)
accessLocation
URI: `http://repository.secomtrust.net/SC-ECC-Root1/SCECCRoot1ca.cer`
\* 必要に応じてOCSP、CA Issuersを設定する | N | --- ## Table : "SECOM RSA Root CA 2023" and Subordinate CAs Root CA 証明書 SHA256 フィンガープリント: 2C154235528D701790B675AFF6E1970827B10ED665E913835BF46E3460FD5C84 | 基本フィールド | 説明 | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | version | 3 (0x2) | | serialNumber | Root CAの場合
99B8098D4418DDDB

下位 CAの場合
CA内で一意の値 | | signature | sha384WithRSAEncryption | | issuer | C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM RSA Root CA 2023 | | validity | Root CAの場合
開始: 2023年1月25日 08:03:37 GMT
終了: 2048年1月1日 08:03:37 GMT

下位CAの場合
開始: 証明書発行日
終了: [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) に規定されているとおりに設定 | | subject | Root CAの場合
C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM RSA Root CA 2023

下位 CAの場合
下位CA利用者情報を設定 | | subjectPublicKeyInfo | Root CAの場合
公開鍵アルゴリズム: rsaEncryption
Public-Key: 4096 bit

下位 CAの場合
公開鍵アルゴリズム識別子と下位CA利用者の公開鍵データ | | 拡張フィールド | 説明 | critical | | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | | authorityKeyIdentifier | SHA-1を使用してCA公開鍵をハッシュして得られた160ビットの値 | N | | subjectKeyIdentifier | SHA-1を使用して利用者の公開鍵をハッシュして得られた160ビットの値 | N | | keyUsage | keyCertSign, cRLSign（利用者公開鍵の利用目的） | Y | | extendedKeyUsage | 次のいずれかを設定
(1) Microsoft Signer of documents (1.3.6.1.4.1.311.10.3.12)
(2) id-kp-documentSigning (1.3.6.1.5.5.7.3.36)
(1)と(2)は同時に設定することも可能。
クロス証明書の場合は、必要に応じて設定。 | N | | certificatePolicies | policyIdentifier
- certPolicyId=1.2.392.200091.100.901.9
policyQualifiers
- policyQualifierID=id-qt-cps
- qualifier=CPS= `http://repo1.secomtrust.net/root/rsa/` | N | | basicConstraints | Subject Type=CA
pathLenConstraints（必要に応じて設定） | Y | | nameConstraints | 存在しない | - | | cRLDistributionPoints | URI: `http://repo1.secomtrust.net/root/rsa/rsarootca2023.crl` | N | | authorityInformationAccess | accessMethod
OCSP (1.3.6.1.5.5.7.48.1)
accessLocation
URI: `http://rsarootca2023.ocsp.secom-cert.jp`
accessMethod
CA Issuers (1.3.6.1.5.5.7.48.2)
accessLocation
URI: `http://repo2.secomtrust.net/root/rsa/rsarootca2023.cer`
\* 必要に応じてOCSP、CA Issuersを設定 | N | --- ## Table : "SECOM Document Signing RSA Root CA 2023" and Subordinate CAs Root CA 証明書 SHA256 フィンガープリント: 46219BBF9148F00E8B7A4C619B57CF7602701FF81348400718870FABD31FC5BE | 基本フィールド | 説明 | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | version | 3 (0x2) | | serialNumber | Root CAの場合
E3A2A1C4FE81A10D

下位CAの場合
CA内で一意の値 | | signature | sha384WithRSAEncryption | | issuer | C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM Document Signing RSA Root CA 2023
OrganizationIdentifier (2.5.4.97) = NTRJP-4011001040781 | | validity | Root CAの場合
開始: 2023年1月25日 08:33:59 GMT
終了: 2048年1月1日 08:33:59 GMT

下位CAの場合
開始: 証明書発行日
終了: [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) に規定されているとおりに設定 | | subject | Root CAの場合
C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM Document Signing RSA Root CA 2023
OrganizationIdentifier (2.5.4.97) = NTRJP-4011001040781

下位CAの場合
下位CA利用者情報を設定する | | subjectPublicKeyInfo | Root CAの場合
公開鍵アルゴリズム: rsaEncryption
Public-Key: 4096 bit

下位CAの場合
公開鍵アルゴリズム識別子と下位CA利用者の公開鍵データ | | 拡張フィールド | 説明 | critical | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------- | | authorityKeyIdentifier | SHA-1を使用しCA公開鍵をハッシュして得られた160ビットの値 | N | | subjectKeyIdentifier | SHA-1を使用し利用者の公開鍵をハッシュして得られた160ビットの値 | N | | keyUsage | keyCertSign, cRLSign（利用者公開鍵の利用目的） | Y | | extendedKeyUsage | 次のいずれかを設定
(1) Adobe Authentic Documents Trust (1.2.840.113583.1.1.5)
(2) id-kp-timeStamping
クロス証明書の場合は、必要に応じて設定。 | N | | certificatePolicies | policyIdentifier
- certPolicyId=1.2.392.200091.100.901.10
policyQualifiers
- policyQualifierID=id-qt-cps
- qualifier=CPS= `http://repo1.secomtrust.net/root/docrsa/` | N | | basicConstraints | Subject Type=CA
pathLenConstraints（必要に応じて設定） | Y | | nameConstraints | 存在しない | - | | cRLDistributionPoints | URI: `http://repo1.secomtrust.net/root/docrsa/docrsarootca2023.crl`
| N | | authorityInformationAccess | accessMethod
OCSP (1.3.6.1.5.5.7.48.1)
accessLocation
URI: `http://docrsarootca2023.ocsp.secom-cert.jp`
accessMethod
CA Issuers (1.3.6.1.5.5.7.48.2)
accessLocation
URI: `http://repo2.secomtrust.net/root/docrsa/docrsarootca2023.cer`
\* 必要に応じてOCSP、CA Issuersを設定 | N | --- ## Table : "SECOM TLS RSA Root CA 2024" and Subordinate CA Root CA 証明書 SHA256 フィンガープリント: 1435F225C5D252D7A21948CC3CE62AECFA88001E3DD72D1CC3555100EB372F93 | 基本フィールド | 説明 | | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | version | 3 (0x2) | | serialNumber | Root CAの場合
EE8934D0CB80E0B2

下位CAの場合CA
CA内で一意の値 | | signature | sha384WithRSAEncryption | | issuer | C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM TLS RSA Root CA 2024 | | validity | Root CAの場合
開始日：2024年1月31日 05:11:55 GMT
終了日：2049年1月14日 05:11:55 GMT

下位CAの場合
開始日：証明書発行日
終了日：[Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) で指定されたとおりに設定 | | subject | Root CAの場合
C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM TLS RSA Root CA 2024

下位CAの場合
下位CAの利用者情報を設定 | | subjectPublicKeyInfo | Root CAの場合
公開鍵アルゴリズム: rsaEncryption
Public-Key: 4096 bit

下位CAの場合
下位CA利用者の公開鍵アルゴリズム識別子と公開鍵データ | | 拡張フィールド | 説明 | critical | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | | authorityKeyIdentifier | SHA-1を使用しCA公開鍵をハッシュして得られた160ビットの値 | N | | subjectKeyIdentifier | SHA-1を使用し利用者の公開鍵をハッシュして得られた160ビットの値 | N | | keyUsage | keyCertSign, cRLSign（利用者公開鍵の利用目的） | Y | | extendedKeyUsage | 次のいずれかを設定
(1) id-kp-serverAuth
(2) id-kp-serverAuth and id-kp-clientAuth
クロス証明書の場合は、必要に応じて設定 | N | | certificatePolicies | policyIdentifier
- CA/ブラウザフォーラム予約証明書ポリシー識別子（最初に設定することを推奨）、 certPolicyId=1.2.392.200091.100.901.11, 1.2.392.200091.100.721.1 or any Policy \*1
policyQualifiers
- policyQualifierID=id-qt-cps
- qualifier=CPS= `http://repo1.secomtrust.net/root/tlsrsa/`
policyQualifier は TLS DV/OV CA の場合、非推奨 | N | | basicConstraints | Subject Type=CA
pathLenConstraints（必要に応じて設定） | Y | | nameConstraints | 存在する場合は、Critical に設定する必要あり | Y | | cRLDistributionPoints | URI: `http://repo1.secomtrust.net/root/tlsrsa/tlsrsarootca2024.crl` | N | | authorityInformationAccess | accessMethod
OCSP (1.3.6.1.5.5.7.48.1)
accessLocation
URI: `http://tlsrsarootca2024.ocsp.secom-cert.jp`
accessMethod
CA Issuers (1.3.6.1.5.5.7.48.2)
accessLocation
URI: `http://repo2.secomtrust.net/root/tlsrsa/tlsrsarootca2024.cer`
\* 必要に応じてOCSP、CA Issuersを設定 | N | \*1 EV 証明書を発行する場合は、「CA/ブラウザフォーラムで予約済みの証明書ポリシー識別子と EV 証明書 OID (1.2.392.200091.100.721.1)」または「any Policy」(CAが下位CAのCA鍵を管理する場合) を設定できる。 --- ## Table : "SECOM TLS ECC Root CA 2024" and Subordinate CA Root CA 証明書 SHA256 フィンガープリント: 6AB2AB75F51CB4F4F0156203FBF6F646232F514BE059F62833308B82B4D72DB1 | 基本フィールド | 説明 | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | version | 3 (0x2) | | serialNumber | Root CAの場合
817A2CEF8F237A44

下位CAの場合
CA内で一意の値 | | signature | ecdsa-with-SHA384 | | issuer | C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM TLS ECC Root CA 2024 | | validity | Root CAの場合
開始日：2024年1月31日 05:52:34 GMT
終了日：2049年1月14日 05:52:34 GMT

下位CAの場合
開始日：証明書発行日
終了日：[Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) で指定されたとおりに設定 | | subject | Root CAの場合
C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM TLS ECC Root CA 2024

下位CAの場合
下位CAの利用者情報を設定 | | subjectPublicKeyInfo | Root CAの場合
公開鍵アルゴリズム: id-ecPublicKey
Public-Key: 384bit

下位CAの場合
下位 CA 利用者の公開鍵アルゴリズム識別子と公開鍵データ | | 拡張フィールド | 説明 | critical | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | | authorityKeyIdentifier | SHA-1を使用しCA公開鍵をハッシュして得られた160ビットの値 | N | | subjectKeyIdentifier | SHA-1を使用し利用者の公開鍵をハッシュして得られた160ビットの値 | N | | keyUsage | keyCertSign, cRLSign（利用者公開鍵の利用目的） | Y | | extendedKeyUsage | 次のいずれかを設定
(1) id-kp-serverAuth
(2) id-kp-serverAuth and id-kp-clientAuth
クロス証明書の場合は、必要に応じて設定 | N | | certificatePolicies | policyIdentifier
- CA/ブラウザフォーラム予約証明書ポリシー識別子（最初に設定することを奨励）、 certPolicyId= 1.2.392.200091.100.902.3, 1.2.392.200091.100.721.1 またはany Policy \*1
policyQualifiers
- policyQualifierID=id-qt-cps
- qualifier=CPS= `http://repo1.secomtrust.net/root/tlsecc/`
policyQualifier は TLS DV/OV CA の場合、非推奨 | N | | basicConstraints | Subject Type=CA
pathLenConstraints（必要に応じて設定） | Y | | nameConstraints | 存在する場合は、Critical に設定する必要あり | Y | | cRLDistributionPoints | URI: `http://repo1.secomtrust.net/root/tlsecc/tlseccrootca2024.crl` | N | | authorityInformationAccess | accessMethod
OCSP (1.3.6.1.5.5.7.48.1)
accessLocation
URI: `http://tlseccrootca2024.ocsp.secom-cert.jp`
accessMethod
CA Issuers (1.3.6.1.5.5.7.48.2)
accessLocation
URI: `http://repo2.secomtrust.net/root/tlsecc/tlseccrootca2024.cer`
\* 必要に応じてOCSP、CA Issuersを設定 | N | \*1 EV 証明書を発行する場合は、「CA/ブラウザフォーラムで予約済みの証明書ポリシー識別子と EV 証明書 OID (1.2.392.200091.100.721.1)」または「any Policy」(CA が下位 CA の CA 鍵を管理する場合) を設定できる。 ## Table : "SECOM SMIME RSA Root CA 2024" and Subordinate CA Root CA 証明書 SHA256 フィンガープリント: 3629E7188E00A7CB3232C4426BC84912F1218B1A9AE676C0B0ABE1DBFE2182B5 | 基本フィールド | 説明 | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | version | 3 (0x2) | | serialNumber | Root CAの場合
DDA9DB9E7EBCD46D

下位CAの場合
CA内で一意の値 | | signature | sha384WithRSAEncryption | | issuer | C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM SMIME RSA Root CA 2024 | | validity | Root CAの場合
開始日：2024年1月31日 06:23:06 GMT
終了日：2049年1月14日 06:23:06 GMT

下位CAの場合
開始日：証明書発行日
終了日：[Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) で指定されたとおりに設定 | | subject | Root CAの場合
C = JP
O = SECOM Trust Systems Co., Ltd.
CN = SECOM SMIME RSA Root CA 2024

下位CAの場合
下位CAの利用者情報を設定 | | subjectPublicKeyInfo | Root CAの場合
公開鍵アルゴリズム: rsaEncryption
Public-Key: 4096 bit

下位CAの場合
下位CA利用者の公開鍵アルゴリズム識別子と公開鍵データ | | 拡張フィールド | 説明 | critical | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | | authorityKeyIdentifier | SHA-1を使用しCA公開鍵をハッシュして得られた160ビットの値 | N | | subjectKeyIdentifier | SHA-1を使用し利用者の公開鍵をハッシュして得られた160ビットの値 | N | | keyUsage | keyCertSign, cRLSign（利用者公開鍵の利用目的） | Y | | extendedKeyUsage | 以下を設定
id-kp-emailProtection
クロス証明書の場合は、必要に応じて設定 | N | | certificatePolicies | policyIdentifier
- CA/ブラウザフォーラム予約証明書ポリシー識別子（最初に設定することを推奨）、 certPolicyId= 1.2.392.200091.100.901.12
policyQualifiers
- policyQualifierID=id-qt-cps
- qualifier=CPS=`http://repo1.secomtrust.net/root/smimersa/` | N | | basicConstraints | Subject Type=CA
pathLenConstraints（必要に応じて設定） | Y | | nameConstraints | 存在する場合は、Critical に設定する必要あり | Y | | cRLDistributionPoints | URI: `http://repo1.secomtrust.net/root/smimersa/smimersarootca2024.crl` | N | | authorityInformationAccess | accessMethod
OCSP (1.3.6.1.5.5.7.48.1)
accessLocation
URI: `http://smimersarootca2024.ocsp.secom-cert.jp`
accessMethod
CA Issuers (1.3.6.1.5.5.7.48.2)
accessLocation
URI: `http://repo2.secomtrust.net/root/smimersa/smimersarootca2024.cer`
\* 必要に応じてOCSP、CA Issuersを設定 | N | --- ## Table : Subscriber Certificates (Client Authentication Certificate and Document Signing Certificates) 表：利用者証明書（クライアント認証証明書およびドキュメントサイニング証明書） | 基本フィールド | 設定 | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | version | 3 (0x2) | | serialNumber | CA内で一意の値 | | signature | sha256WithRSAEncryption | | issuer | countryName = JP
organizationName = CAの組織を設定
organizationalUnitName = CAの部門名等を設定可能
commonName = CAのコモンネームを設定 | | validity | notBefore = 証明書署名前の48時間以内の値
notAfter = [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) に規定 | | subject | countryName = JP
stateOrProvinceName = 都道府県名（オプション）
localityName = 市区町村名（オプション）
organizationName = 組織名
organizationalUnitName = 部門名等（オプション）
commonName = 利用者名
serialNumber = シリアルナンバー（オプション） | | subjectPublicKeyInfo | 主体者識別名の公開鍵データ | | 拡張フィールド | 設定 | critical | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | | authorityKeyIdentifier | 認証局公開鍵識別子
SHA-1を使用しCA公開鍵をハッシュして得られた160ビットの値 | N | | subjectKeyIdentifier | 主体者識別名公開鍵識別子
SHA-1を使用し利用者の公開鍵をハッシュして得られた160ビットの値 | N | | keyUsage | 下記が設定可能：
digitalSignature
Non Repudiation
keyEncipherment
dataEncipherment | Y | | certificatePolicies | 下記が設定可能：
Policy: 1.2.392.200091.100.381.4 (クライアント認証証明書)
Policy: 1.2.392.200091.100.381.5 (ドキュメントサイニング証明書)
CPS: Repository URL | N | | subjectAltName | 下記が設定可能：
OtherName: UPN=「ユーザープリンシパル名」
OtherName: "OID"=「任意の文字列」
Rfc822Name: 「メールアドレス」（2023-08-31まで設定可能） | N | | extendedKeyUsage | 下記が設定可能：
id-kp-clientAuth
id-kp-emailProtection (2023-08-31まで設定可能)
スマートカードログオン
Adobe Authentic Documents Trust = 1.2.840.113583.1.1.5
Microsoft Signer of documents = 1.3.6.1.4.1.311.10.3.12
\* スマートカードログオンを選択した場合は、id-kp-clientAuthも選択のこと。 | N | | cRLDistributionPoints | CA の CRL サービスの HTTP URL
ldap://repo1.secomtrust.net/"IssuerDN"?certificateRevocationList
\* ldapは必要に応じて設定される。 | N | | authorityInformationAccess | accessMethod
ocsp (1.3.6.1.5.5.7.48.1)
accessLocation
OCSP レスポンダー URL
accessMethod
caIssuers (1.3.6.1.5.5.7.48.2)
accessLocation
下位 CA 証明書の URL
\* 必要に応じてOCSP、CA Issuersを設定 | N | | Netscape Certificate Type | 下記が設定可能：
SSL Client
S/MIME Client (2023-08-31まで設定可能) | N | --- ## Table : Subscriber Certificates (Code Signing Certificates, Not be issued after 2024-05-01) 表：利用者証明書（コードサイニング証明書：2024年5月1日以降発行しない） | 基本フィールド | 設定 | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | version | 3 (0x2) | | serialNumber | CA内で一意の値 | | signature | sha256WithRSAEncryption | | issuer | countryName = JP
organizationName = CAの組織を設定
commonName = CAのコモンネームを設定 | | validity | notBefore = 証明書署名前の48時間以内の値
notAfter = [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) に規定 | | subject | countryName = JP
stateOrProvinceName = 都道府県名
localityName = 市区町村名
organizationName = 組織名
organizationalUnitName = 部門名等（オプション）
commonName = 利用者名 | | subjectPublicKeyInfo | 主体者識別名のRSA公開鍵データ（3072bitまたは4096bit） | | 拡張フィールド | 設定 | critical | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | | authorityKeyIdentifier | 認証局公開鍵識別子
認証局公開鍵の160ビットSHA-1ハッシュ値 | N | | subjectKeyIdentifier | 主体者識別名公開鍵識別子
主体者識別名公開鍵の160ビットSHA-1ハッシュ値 | N | | keyUsage | digitalSignature | Y | | certificatePolicies | Policy: 1.2.392.200091.100.381.8
CPS: リポジトリー URL
Policy: 2.23.140.1.4.1（コードサイニング証明書ポリシー） | N | | subjectAltName | - | - | | extKeyUsage | id-kp-codeSigning | N | | crlDistributionPoints | CA の CRL サービスの HTTP URL | N | | authorityInformationAccess | accessMethod
ocsp (1.3.6.1.5.5.7.48.1)
accessLocation
OCSP レスポンダー URL
accessMethod
caIssuers (1.3.6.1.5.5.7.48.2)
accessLocation
下位 CA 証明書の URL | N | --- ## Table: Subscriber Certificates (AATL Document Signing Certificates) 表：利用者証明書（AATLドキュメントサイニング証明書） | 基本フィールド | 設定 | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | version | 3 (0x2) | | serialNumber | CA内の一意の値 | | signature | 以下のいずれかを設定
sha256WithRSAEncryption
sha384WithRSAEncryption | | issuer | countryName = JP
organizationName = SECOM Trust Systems Co., Ltd.
commonName = CAのコモンネームを設定
organizationIdentifier(2.5.4.97) = NTRJP-4011001040781
(NTRJP-CAの法人番号) | | validity | notBefore = 証明書署名前の48時間以内の値
notAfter = [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) に規定 | | subject | countryName = JP
stateOrProvinceName = 都道府県名（オプション）
localityName = 市区町村名（オプション）
organizationName = 組織名（個人使用の場合は設定しない）
organizationalUnitName = 部門名等（オプション）
commonName = 利用者名
serialNumber = シリアルナンバー（オプション）
organizationIdentifier(2.5.4.97) = NTRJP-法人番号（オプション） | | subjectPublicKeyInfo | 主体者識別名の公開鍵データ | | 拡張フィールド | 設定 | critical | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | | authorityKeyIdentifier | 認証局公開鍵識別子
認証局公開鍵の160ビットSHA-1ハッシュ値 | N | | subjectKeyIdentifier | 主体者識別名公開鍵識別子
主体者識別名公開鍵の160ビットSHA-1ハッシュ値 | N | | keyUsage | digitalSignature
Non Repudiation | Y | | certificatePolicies | Policy: 1.2.392.200091.100.382.1
CPS: リポジトリーURL | N | | subjectAltName | - | - | | extKeyUsage | Adobe Authentic Documents Trust = 1.2.840.113583.1.1.5 | N | | crlDistributionPoints | CA の CRL サービスの HTTP URL | N | | authorityInformationAccess | accessMethod
ocsp (1.3.6.1.5.5.7.48.1)
accessLocation
OCSP レスポンダー URL
accessMethod
caIssuers (1.3.6.1.5.5.7.48.2)
accessLocation
下位 CA 証明書の URL
\* 必要に応じてOCSP、CA Issuersを設定 | N | --- ## Table: Subscriber Certificates (S/MIME Certificates) 表：利用者証明書（S/MIME証明書） | 基本フィールド | 設定 | | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | version | 3 (0x2) | | serialNumber | CA内で一意の値 | | signature | 以下のいずれかを設定
sha256WithRSAEncryption
sha384WithRSAEncryption | | issuer | countryName = JP
organizationName = CAの組織を設定
commonName = CAのコモンネームを設定 | | validity | notBefore = 証明書署名前の48時間以内の値
notAfter = [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) に規定 | | subject | commonName = メールアドレス | | subjectPublicKeyInfo | 主体者識別名の公開鍵データ | | 拡張フィールド | Settings | critical | | -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | | authorityKeyIdentifier | 認証局公開鍵識別子
認証局公開鍵の160ビットSHA-1ハッシュ値 | N | | subjectKeyIdentifier | 主体者識別名公開鍵識別子
主体者識別名公開鍵の160ビットSHA-1ハッシュ値 | N | | keyUsage | digitalSignature
keyEncipherment | Y | | certificatePolicies | CA/ブラウザフォーラム予約済み証明書ポリシー識別子 (最初に設定することを推奨) 1.2.392.200091.100.383.1 (オプション)
CPS: リポジトリー URL (オプション) | N | | subjectAltName | Rfc822Name:メールアドレス | N | | extKeyUsage | id-kp-emailProtection | N | | crlDistributionPoints | CA の CRL サービスの HTTP URL | N | | authorityInformationAccess | accessMethod
ocsp (1.3.6.1.5.5.7.48.1)
accessLocation
OCSP レスポンダー の URL
accessMethod
caIssuers (1.3.6.1.5.5.7.48.2)
accessLocation
下位 CA 証明書の URL
\* 必要に応じてOCSP、CA Issuersを設定 | N | --- ## Table: Security Communication RootCA2 TSA, TA Certificates (Issued before 2018-09-26) 表： Security Communication RootCA2 から発行する TSA・TA証明書（2018年9月26日以前） | 基本フィールド | 設定 | | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | version | 3 (0x2) | | serialNumber | CA内で一意の値 | | signature | sha256WithRSAEncryption | | issuer | 発行者に関する情報（CA により指定） | | validity | notBefore = 証明書署名前の24時間以内の値
notAfter = [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) に規定 | | subject | 利用者情報 | | subjectPublicKeyInfo | 主体者識別名の公開鍵データ | | 拡張フィールド | 設定 | critical | | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | | authorityKeyIdentifier | CA公開鍵の160ビットSHA-1ハッシュ | N | | subjectKeyIdenrifier | 利用者公開鍵の160ビットSHA-1ハッシュ | N | | keyUsage | digitalSignature
\* keyCertSign および cRLSign 以外の使用法は、必要に応じて CA によって指定される場合がある。 | Y | | certificatePolicies | policyIdentifier
certPolicyId=1.2.392.200091.100.901.5
policyQualifiers
policyQualifierID=id-qt-cps
qualifier=CPS=`https://repository.secomtrust.net/SC-Root2/` | N | | subjectAltName | - | - | | extKeyUsage | id-kp-timeStamping | N | | cRLDistributionPoints | URI:`http://repository.secomtrust.net/SC-Root2/SCRoot2CRL.crl` | N | | authorityInformationAccess | accessMethod
id-ad-ocsp（1.3.6.1.5.5.7.48.1)
accessLocation
URI:`http://scrootca2.ocsp.secomtrust.net` (cRLDistributionPointsが存在する場合はオプション) | N | --- ## Table: Security Communication RootCA3 TSA, TA Certificates (Issued before 2018-09-26) 表： Security Communication RootCA3 から発行する TSA・TA証明書（2018年9月26日以降） | 基本フィールド | 設定 | | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | version | 3 (0x2) | | serialNumber | CA内で一意の値 | | signature | 以下のいずれかを設定
sha256WithRSAEncryption
sha384WithRSAEncryption | | issuer | 発行者に関する情報（CA により指定） | | validity | notBefore = 証明書署名前の24時間以内の値
notAfter = [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) に規定 | | subject | 利用者情報 | | subjectPublicKeyInfo | 主体者識別名の RSA 公開鍵データ (少なくとも 2048 ビット) | | 拡張フィールド | 設定 | critical | | -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | | authorityKeyIdentifier | CA公開鍵の160ビットSHA-1ハッシュ | N | | subjectKeyIdenrifier | 利用者公開鍵の160ビットSHA-1ハッシュ | N | | keyUsage | digitalSignature
\* keyCertSign および cRLSign 以外の使用法は、必要に応じて CA によって指定される場合がある。 | Y | | certificatePolicies | policyIdentifier
certPolicyId=1.2.392.200091.100.901.7
policyQualifiers
policyQualifierID=id-qt-cps
qualifier=CPS=`https://repository.secomtrust.net/SC-Root3/` | N | | subjectAltName | - | - | | extKeyUsage | id-kp-timeStamping | N | | cRLDistributionPoints | URI:`http://repository.secomtrust.net/SC-Root3/SCRoot3CRL.crl`
\* id-ad-ocsp accessMethod がauthorityInformationAccess 拡張に存在する場合はオプション。 | N | | authorityInformationAccess | accessMethod
id-ad-ocsp（1.3.6.1.5.5.7.48.1)
accessLocation
URI:`http://scrootca3.ocsp.secomtrust.net` (cRLDistributionPointsが存在する場合はオプション) | N | --- ## Table: Security Communication RootCA3 TimeStamping Subordinate CA Certificates (Issued after 2018-06-07) 表： Security Communication RootCA3 から発行する タイムスタンプ下位CA証明書（2018年6月7日以降） | 基本フィールド | 設定 | | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | version | 3 (0x2) | | serialNumber | CA内で一意の値 | | signature | 以下のいずれかを設定
sha256WithRSAEncryption
sha384WithRSAEncryption | | issuer | 発行者に関する情報（CA により指定） | | validity | notBefore = 証明書署名前の24時間以内の値
notAfter = [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) に規定 | | subject | 利用者情報 | | subjectPublicKeyInfo | 主体者識別名の公開鍵データ | | 拡張フィールド | Settins | critical | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | | authorityKeyIdentifier | CA公開鍵の160ビットSHA-1ハッシュ | N | | subjectKeyIdenrifier | 利用者公開鍵の160ビットSHA-1ハッシュ | N | | keyUsage | keyCertSign, cRLSign | Y | | basicConstraints | Subject Type=CA
pathLenConstraints（CAが必要に応じて設定） | Y | | certificatePolicies | policyIdentifier
certPolicyId=1.2.392.200091.100.901.7
policyQualifiers
policyQualifierID=id-qt-cps
qualifier=CPS=`http(s)://repository.secomtrust.net/SC-Root3/`
\* ( ) is optional | N | | subjectAltName | - | - | | extKeyUsage | id-kp-timeStamping | N | | cRLDistributionPoints | URI:`http://repository.secomtrust.net/SC-Root3/SCRoot3CRL.crl`
\* id-ad-ocsp accessMethod がauthorityInformationAccess 拡張に存在する場合はオプション。 | N | | authorityInformationAccess | accessMethod
id-ad-ocsp（1.3.6.1.5.5.7.48.1)
accessLocation
URI:`http://scrootca3.ocsp.secomtrust.net` (cRLDistributionPoints が存在する場合はオプション)
id-ad-caIssuers (1.3.6.1.5.5.7.48.2)
accessLocation
URI:`http://repository.secomtrust.net/SC-Root3/SCRoot3ca.cer`
\* 必要に応じてOCSP、CA Issuersを設定 | N | --- ## Table: SECOM TimeStamping CA2 TSA, TA Certificates 表： SECOM TimeStamping CA2 から発行する TSA・TA証明書 | 基本フィールド | 設定 | | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | version | 3 (0x2) | | serialNumber | CA内で一意の値 | | signature | sha256WithRSAEncryption | | issuer | 発行者に関する情報（CA により指定） | | validity | notBefore = 証明書署名前の24時間以内の値
notAfter = [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) に規定 | | subject | 利用者情報 | | subjectPublicKeyInfo | 主体者識別名の公開鍵データ | | 拡張フィールド | 設定 | critical | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | | authorityKeyIdentifier | CA公開鍵の160ビットSHA-1ハッシュ | N | | subjectKeyIdentifier | 主体者識別名公開鍵の160ビットSHA-1ハッシュ値 | N | | keyUsage | digitalSignature, nonRepudiation
([keyCertSign] および [cRLSign] 以外の用途は、必要に応じて CA によって指定される場合がある) | Y | | certificatePolicies | certPolicyId=1.2.392.200091.100.931.1
policyQualifierID=id-qt-cps
qualifier=`https://repo1.secomtrust.net/spcpp/ts/` | N | | subjectAltName | - | - | | extKeyUsage | id-kp-timeStamping | N | | cRLDistributionPoints | URI:`http://repo1.secomtrust.net/spcpp/ts/ca2/fullCRL.crl` | N | | authorityInformationAccess | accessMethod
ocsp (1.3.6.1.5.5.7.48.1)
accessLocation
`http://ts2.ocsp.secomtrust.net` (cRLDistributionPoints が存在する場合はオプション) | N | --- ## Table: SECOM TimeStamping CA3 TSA, TA Certificates 表： SECOM TimeStamping CA3 から発行する TSA・TA証明書 | 基本フィールド | 設定 | | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | version | 3 (0x2) | | serialNumber | CA内で一意の値 | | signature | 以下のいずれかを設定
sha256WithRSAEncryption
sha384WithRSAEncryption | | issuer | 発行者に関する情報（CA により指定） | | validity | notBefore = 証明書署名前の24時間以内の値
notAfter = [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) に規定 | | subject | 利用者情報 | | subjectPublicKeyInfo | 主体者識別名の公開鍵データ | | 拡張フィールド | 設定 | critical | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | | authorityKeyIdentifier | CA公開鍵の160ビットSHA-1ハッシュ | N | | subjectKeyIdenrifier | 利用者公開鍵の160ビットSHA-1ハッシュ | N | | keyUsage | digitalSignature (keyCertSignとcRLSign以外の目的は、このCAによって必要に応じて設定されることがある) | Y | | certificatePolicies | certPolicyId=1.2.392.200091.100.931.3
policyQualifierID=id-qt-cps
qualifier=`https://repo1.secomtrust.net/spcpp/ts/` | N | | subjectAltName | - | - | | extKeyUsage | id-kp-timeStamping | N | | cRLDistributionPoints | URI:`http://repo1.secomtrust.net/spcpp/ts/ca3/fullCRL.crl`
\* id-ad-ocsp accessMethod がauthorityInformationAccess Extensionに存在する場合はオプション | N | | authorityInformationAccess | accessMethod
ocsp (1.3.6.1.5.5.7.48.1)
accessLocation
`http://ts3.ocsp.secomtrust.net` (cRLDistributionPoints が存在する場合はオプション)
accessMethod
caIssuers (1.3.6.1.5.5.7.48.2)
accessLocation
CA証明書のHTTP URL
\* 必要に応じてOCSP、CA Issuersを設定 | N | --- ## Table: SECOM TimeStamping CA4 TSA Certificates (Not issued after 2025-04-15) 表： SECOM TimeStamping CA4 から発行する TSA証明書（2025年4月15日以降発行しない） | 基本フィールド | 設定 | | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | version | 3 (0x2) | | serialNumber | CA内で一意の値 | | signature | 以下のいずれかを設定
sha256WithRSAEncryption
sha384WithRSAEncryption | | issuer | 発行者に関する情報（CA により指定） | | validity | notBefore = 証明書署名前の24時間以内の値
notAfter = [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) に規定 | | subject | 利用者情報 | | subjectPublicKeyInfo | 主体者識別名の RSA 公開鍵データ (少なくとも 3072 ビット) | | 拡張フィールド | Settins | critical | | -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | | authorityKeyIdentifier | CA公開鍵の160ビットSHA-1ハッシュ | N | | subjectKeyIdenrifier | 利用者公開鍵の160ビットSHA-1ハッシュ | N | | keyUsage | digitalSignature
([keyCertSign] および [cRLSign] 以外の用途は、必要に応じて CA によって指定される場合がある) | Y | | certificatePolicies | certPolicyId=1.2.392.200091.100.931.4
policyQualifierID=id-qt-cps
qualifier=`https://repo1.secomtrust.net/spcpp/ts/` | N | | subjectAltName | - | - | | extKeyUsage | timeStamping(1.3.6.1.5.5.7.3.8) | N | | cRLDistributionPoints | URI:`http://repo1.secomtrust.net/spcpp/ts/ca4/fullCRL.crl` | N | | authorityInformationAccess | accessMethod
ocsp (1.3.6.1.5.5.7.48.1)
accessLocation
`http://ts4.ocsp.secom-cert.jp`
accessMethod
caIssuers (1.3.6.1.5.5.7.48.2)
accessLocation
CA証明書のHTTP URL | N | --- ## Table: SECOM TimeStamping Service TSA Certificates 表： SECOM TimeStamping Service TSA証明書 | 基本フィールド | 設定 | | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | version | 3 (0x2) | | serialNumber | CA内で一意の値 | | signature | 以下のいずれかを設定
sha256WithRSAEncryption
sha384WithRSAEncryption | | issuer | 発行者に関する情報（CA により指定） | | validity | notBefore = 証明書署名前の24時間以内の値
notAfter = [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) に規定 | | subject | 利用者情報 | | subjectPublicKeyInfo | 主体者識別名の公開鍵データ | | 拡張フィールド | 設定 | critical | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | | authorityKeyIdentifier | CA公開鍵の160ビットSHA-1ハッシュ | N | | subjectKeyIdenrifier | 利用者公開鍵の160ビットSHA-1ハッシュ | N | | keyUsage | digitalSignature | Y | | certificatePolicies | policyIdentifier
certPolicyId=1.2.392.200091.100.931.5
policyQualifiers
policyQualifierID=id-qt-cps
qualifier= CAリポジトリーの HTTP(S) URL | N | | subjectAltName | - | - | | extKeyUsage | id-kp-timeStamping | N | | cRLDistributionPoints | CAのCRLサービスのHTTP URL
\* id-ad-ocsp accessMethod が authorityInformationAccess 拡張に存在する場合はオプション。 | N | | authorityInformationAccess | accessMethod
id-ad-ocsp（1.3.6.1.5.5.7.48.1)
accessLocation
OCSP レスポンダーの HTTP URL (cRLDistributionPoints が存在する場合はオプション)
id-ad-caIssuers (1.3.6.1.5.5.7.48.2)
accessLocation
CA 証明書の HTTP URL
\* 必要に応じてOCSP、CA Issuersを設定 | N | ---