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 - 目次
• 1. INTRODUCTION - 概説
  • 1.1 Overview - 概要
    • 1.1.1 Standards, Criteria and Regulations - 基準、評価基準および規則
  • 1.2 Document name and identification - 文書名と識別
    • 1.2.1 Revisions - 改訂
  • 1.3 PKI Participants - PKI関係者
    • 1.3.1 Certification Authorities - 認証局（CA）
    • 1.3.2 Registration Authorities - 登録局（RA）
      • 1.3.2.1 Enterprise registration authorities (S/MIME Certificates) - Enterprise RA (S/MIME 証明書)
    • 1.3.3 Subscribers - 利用者
    • 1.3.4 Relying Parties - 検証者
    • 1.3.5 Other Participants - その他関係者
  • 1.4 Certificate Usage - 証明書の用途
    • 1.4.1 Appropriate Certificate Uses - 適切な証明書の用途
    • 1.4.2 Prohibited Certificate Uses - 禁止される証明書の用途
  • 1.5 Policy administration - ポリシー管理
    • 1.5.1 Organization Administering the Document - 文書を管理する組織
    • 1.5.2 Contact Person - 連絡先
    • 1.5.3 Person Determining CPS suitability for the policy - ポリシー適合性決定者
    • 1.5.4 CPS approval procedures - CPS承認手続
  • 1.6 Definitions and Acronyms - 定義と頭字語
    • 1.6.1 Definitions - 定義
    • 1.6.2 Acronyms - 頭字語
    • 1.6.3 References - 参照
    • 1.6.4 Conventions - 慣例
• 2. PUBLICATION AND REPOSITORY RESPONSIBILITIES - 公開およびリポジトリーに関する責任
  • 2.1 Repositories - リポジトリー
  • 2.2 Publication of information - 情報公開
  • 2.3 Time or frequency of publication - 公開時期または頻度
  • 2.4 Access controls on repositories - リポジトリーのアクセス管理
• 3. IDENTIFICATION AND AUTHENTICATION - 識別と認証
  • 3.1 Naming - 識別名
    • 3.1.1 Types of names - 識別名タイプ
    • 3.1.2 Need for names to be meaningful - 識別名の意味付け
    • 3.1.3 Anonymity or pseudonymity of subscribers - 利用者の匿名性または仮名性
    • 3.1.4 Rules for interpreting various name forms - 識別名の解釈規則
    • 3.1.5 Uniqueness of names - 識別名の一意性
    • 3.1.6 Recognition, authentication, and role of trademarks - 商標の認識、認証および役割
  • 3.2 Initial identity validation - 初回の利用者本人確認
    • 3.2.1 Method to prove possession of private key - 私有鍵の所持を証明する方法
    • 3.2.2 Authentication of Organization and Domain Identity - 組織とドメインの認証
      • 3.2.2.1 Identity - アイデンティティ
        • 3.2.2.1.1 Validating authority over mailbox via domain (S/MIME Certificates) - ドメイン経由のメールボックス権限検証 (S/MIME 証明書)
        • 3.2.2.1.2 Validating control over mailbox via email (S/MIME Certificates) - Emailによるメールボックス管理検証 (S/MIME 証明書)
        • 3.2.2.1.3 Validating applicant as operator of associated mail server(s) (S/MIME Certificates) - 申請者が関連メールサーバーの運営者であることの検証（S/MIME証明書）
      • 3.2.2.2 DBA/Tradename - 商号/商標名
        • 3.2.2.2.1 Verification of Applicant's Legal Existence and Identity (EV TLS Server Certificates) - 申請者の法的存在と身元の検証（EV TLSサーバー証明書）
          • 3.2.2.2.1.1 Verification Requirements - 検証要件
          • 3.2.2.2.1.2 Acceptable Method of Verification - 許容される検証方法
        • 3.2.2.2.2 Verification of Applicant's Legal Existence and Identity – Assumed Name (EV TLS Server Certificates) - 申請者の法的存在と身元の検証 - 仮名 (EV TLSサーバー証明書)
          • 3.2.2.2.2.1 Verification Requirements - 検証要件
          • 3.2.2.2.2.2 Acceptable Method of Verification - 許容される検証方法
        • 3.2.2.2.3 Verification of Applicant's Physical Existence (EV TLS Server Certificates) - 申請者の実在検証（EV TLSサーバー証明書）
          • 3.2.2.2.3.1 Address of Applicant's Place of Business - 申請者の事業所住所
        • 3.2.2.2.4 Verified Method of Communication (EV TLS Server Certificates) - 検証済み通信方法（EV TLSサーバー証明書）
          • 3.2.2.2.4.1 Verification Requirements - 検証要件
          • 3.2.2.2.4.2 Acceptable Methods of Verification - 許容される検証方法
        • 3.2.2.2.5 Verification of Applicant's Operational Existence (EV TLS Server Certificates) - 申請者の運用上の存在の検証（EV TLSサーバー証明書）
          • 3.2.2.2.5.1 Verification Requirements - 検証要件
          • 3.2.2.2.5.2 Acceptable Methods of Verification - 許容される検証方法
        • 3.2.2.2.6 Verification of Applicant's Domain Name (EV TLS Server Certificates) - 申請者のドメイン名検証（EV TLSサーバー証明書）
          • 3.2.2.2.6.1 Verification Requirements - 検証要件
        • 3.2.2.2.7 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 - 検証要件
          • 3.2.2.2.7.2 Acceptable Methods of Verification – Name, Title and Agency - 許容される検証方法 – 氏名、役職、所属組織
          • 3.2.2.2.7.3 Acceptable Methods of Verification – Authority - 許容される検証方法 – 権限
          • 3.2.2.2.7.4 Pre-Authorized Certificate Approver - 事前承認証明書承認者
        • 3.2.2.2.8 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 - 検証要件
          • 3.2.2.2.8.2 Acceptable Methods of Signature Verification - 許容される署名検証の方法
        • 3.2.2.2.9 Verification of Approval of EV Certificate Request (EV TLS Server Certificates) - EV 証明書要求の承認の検証 (EV TLSサーバー証明書)
          • 3.2.2.2.9.1 Verification Requirements - 検証要件
          • 3.2.2.2.9.2 Acceptable Methods of Verification - 許容される検証方法
        • 3.2.2.2.10 Verification of Certain Information Sources (EV TLS Server Certificates) - 特定の情報源の検証（EV TLSサーバー証明書）
          • 3.2.2.2.10.1 Verified Legal Opinion - 検証済み法律意見書
          • 3.2.2.2.10.2 Verified Accountant Letter - 検証済み会計士確認書
          • 3.2.2.2.10.3 Face-to-Face Validation - 対面による検証
          • 3.2.2.2.10.4 Independent Confirmation From Applicant - 申請者から独立した確認
          • 3.2.2.2.10.5 Qualified Independent Information Source - 認定独立情報源
          • 3.2.2.2.10.6 Qualified Government Information Source - 認定政府情報源
          • 3.2.2.2.10.7 Qualified Government Tax Information Source - 認定政府税務情報源
        • 3.2.2.2.11 Other Verification Requirements (EV TLS Server Certificates) - その他の検証要件 (EV TLSサーバー証明書)
          • 3.2.2.2.11.1 High Risk Status - ハイリスクステータス
          • 3.2.2.2.11.2 Denied Lists and Other Legal Block Lists - 拒否リストおよびその他法的ブロックリスト
          • 3.2.2.2.11.3 Parent/Subsidiary/Affiliate Relationship - 親会社/子会社/関連会社との関係
        • 3.2.2.2.12 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) - 既存ドキュメントの再利用に関する要件 (EV TLSサーバー証明書)
          • 3.2.2.2.13.1 Validation For Existing Subscribers - 既存の利用者検証
          • 3.2.2.2.13.2 Re-issuance Requests - 再発行要求
          • 3.2.2.2.13.3 Age of Validated Data - 検証済みデータの有効期限
      • 3.2.2.3 Verification of Country - 国名検証
      • 3.2.2.4 Validation of Domain Authorization or Control - ドメイン認証または管理の検証
        • 3.2.2.4.1 Validating the Applicant as a Domain Contact - ドメイン連絡先としての申請者の検証
        • 3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact - ドメイン連絡先へのEmail、FAX、SMSまたは郵便
        • 3.2.2.4.3 Phone Contact with Domain Contact - ドメイン連絡先への電話連絡
        • 3.2.2.4.4 Constructed Email to Domain Contact - ドメイン連絡先への指定アドレス宛Email
        • 3.2.2.4.5 Domain Authorization Document - ドメイン認証文書
        • 3.2.2.4.6 Agreed-Upon Change to Website - ウェブサイトへの合意に基づく変更
        • 3.2.2.4.7 DNS Change - DNS変更
        • 3.2.2.4.8 IP Address - IPアドレス
        • 3.2.2.4.9 Test Certificate - テスト証明書
        • 3.2.2.4.10 TLS Using a Random Value - ランダム値を使用したTLS
        • 3.2.2.4.11 Any Other Method - その他の方法
        • 3.2.2.4.12 Validating Applicant as a Domain Contact - ドメイン連絡先としての申請者検証
        • 3.2.2.4.13 Email to DNS CAA Contact - DNS CAA連絡先へのEmail
        • 3.2.2.4.14 Email to DNS TXT Contact - DNS TXT連絡先へのEmail
        • 3.2.2.4.15 Phone Contact with Domain Contact - ドメイン連絡先への電話連絡
        • 3.2.2.4.16 Phone Contact with DNS TXT Record Phone Contact - DNS TXT連絡先への電話連絡
        • 3.2.2.4.17 Phone Contact with DNS CAA Phone Contact - DNS CAA連絡先への電話連絡
        • 3.2.2.4.18 Agreed-Upon Change to Website v2 - ウェブサイトへの合意に基づく変更 v2
        • 3.2.2.4.19 Agreed-Upon Change to Website - ACME - ウェブサイトへの合意に基づく変更 - ACME
        • 3.2.2.4.20 TLS Using ALPN - ALPNを使用したTLS
      • 3.2.2.5 Authentication for an IP Address - IPアドレス認証
      • 3.2.2.6 Wildcard Domain Validation - ワイルドカードドメイン認証
      • 3.2.2.7 Data Source Accuracy - データソースの正確性
      • 3.2.2.8 CAA Records - CAAレコード
      • 3.2.2.9 Multi-Perspective Issuance Corroboration - マルチパースペクティブ発行検証
    • 3.2.3 Authentication of individual identity - 個人認証
      • 3.2.3.1 Attribute collection of organization identity (S/MIME Certificates) - 組織のアイデンティティ属性の収集 (S/MIME 証明書)
    • 3.2.4 Non-verified subscriber information - 未検証の利用者情報
    • 3.2.5 Validation of authority - 権限検証
    • 3.2.6 Criteria for Interoperation or Certification - 相互運用または認証の基準
  • 3.3 Identification and authentication for re-key requests - 鍵更新申請時の本人性確認と認証
    • 3.3.1 Identification and authentication for routine re-key - 通常の鍵更新時における本人性確認と認証
    • 3.3.2 Identification and authentication for re-key after revocation - 証明書失効後の鍵更新における本人性確認と認証
  • 3.4 Identification and authentication for revocation request - 失効申請時の本人性確認と認証
• 4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS - 証明書ライフサイクルの運用要件
  • 4.1 Certificate Application - 証明書申請
    • 4.1.1 Who can submit a certificate application - 証明書を申請できる者
    • 4.1.2 Enrollment process and responsibilities - 申請手続および責任
  • 4.2 Certificate application processing - 証明書申請手続
    • 4.2.1 Performing identification and authentication functions - 本人性確認と認証の実施
    • 4.2.2 Approval or rejection of certificate applications - 証明書申請の承認または却下
      • 4.2.2.1 Certification authority authorization (CAA) (S/MIME Certificates) - 認証局認可 (CAA) (S/MIME 証明書)
      • 4.2.2.2 Multi-perspective issuance corroboration (S/MIME Certificates) - マルチパースペクティブ発行検証 (S/MIME 証明書)
    • 4.2.3 Time to process certificate applications - 証明書申請の処理時間
  • 4.3 Certificate issuance - 証明書発行
    • 4.3.1 CA actions during certificate issuance - 証明書発行時の処理手続
      • 4.3.1.1 Manual authorization of certificate issuance for Root CAs - Root CAの証明書発行の手動承認
      • 4.3.1.2 Linting of to-be-signed Certificate content - 署名される証明書のリンティング
      • 4.3.1.3 Linting of issued Certificates - 発行済み証明書のリンティング
    • 4.3.2 Notification to subscriber by the CA of issuance of certificate - CAによる利用者への証明書発行通知
  • 4.4 Certificate acceptance - 証明書受領確認
    • 4.4.1 Conduct constituting certificate acceptance - 証明書受領確認手続
    • 4.4.2 Publication of the certificate by the CA - CAによる証明書公開
    • 4.4.3 Notification of certificate issuance by the CA to other entities - CAによる他の関係者への証明書発行通知
  • 4.5 Key pair and certificate usage - 鍵ペアおよび証明書の用途
    • 4.5.1 Subscriber private key and certificate usage - 利用者における私有鍵および証明書の用途
    • 4.5.2 Relying party public key and certificate usage - 検証者における公開鍵と証明書の用途
  • 4.6 Certificate renewal - 鍵更新をともなわない証明書更新
    • 4.6.1 Circumstance for certificate renewal - 鍵更新をともなわない証明書更新の要件
    • 4.6.2 Who may request renewal - 鍵更新をともなわない証明書更新申請の処理手続
    • 4.6.3 Processing certificate renewal requests - 鍵更新をともなわない証明書更新申請の処理手続
    • 4.6.4 Notification of new certificate issuance to subscriber - 利用者への新更新証明書の発行通知
    • 4.6.5 Conduct constituting acceptance of a renewal certificate - 鍵更新をともなわない更新証明書の受領確認手続
    • 4.6.6 Publication of the renewal certificate by the CA - CAによる鍵更新をともなわない更新証明書の公開
    • 4.6.7 Notification of certificate issuance by the CA to other entities - CAによる他の関係者への証明書発行通知
  • 4.7 Certificate re-key - 証明書鍵更新
    • 4.7.1 Circumstance for certificate re-key - 証明書鍵更新に関する要件
    • 4.7.2 Who may request certification of a new public key - 鍵更新をともなう新証明書の申請を行うことができる者
    • 4.7.3 Processing certificate re-keying requests - 鍵更新をともなう証明書申請の処理手続
    • 4.7.4 Notification of new certificate issuance to subscriber - 利用者への新証明書発行通知
    • 4.7.5 Conduct constituting acceptance of a re-keyed certificate - 鍵更新をともなう証明書受領確認手続
    • 4.7.6 Publication of the re-keyed certificate by the CA - CAによる鍵更新された証明書の公開
    • 4.7.7 Notification of certificate issuance by the CA to other entities - CAによる他の関係者への証明書発行通知
  • 4.8 Certificate modification - 証明書記載事項変更による証明書変更
    • 4.8.1 Circumstance for certificate modification - 証明書記載事項変更による証明書変更の要件
    • 4.8.2 Who may request certificate modification - 証明書記載事項変更による証明書変更を要求できる者
    • 4.8.3 Processing certificate modification requests - 証明書変更要求の処理
    • 4.8.4 Notification of new certificate issuance to subscriber - 利用者への新証明書発行通知
    • 4.8.5 Conduct constituting acceptance of modified certificate - 変更された証明書受領確認手続
    • 4.8.6 Publication of the modified certificate by the CA - CAによる変更済み証明書の公開
    • 4.8.7 Notification of certificate issuance by the CA to other entities - CAによる他の関係者への証明書発行通知
  • 4.9 Certificate revocation and suspension - 証明書の失効と一時停止
    • 4.9.1 Circumstances for revocation - 証明書失効要件
      • 4.9.1.1 Reasons for Revoking a Subscriber Certificate - 利用者証明書の失効理由
      • 4.9.1.2 Reasons for Revoking a Subordinate CA Certificate - 下位CA証明書の失効理由
    • 4.9.2 Who can request revocation - 証明書の失効申請を行うことができる者
    • 4.9.3 Procedure for revocation request - 失効申請手続
    • 4.9.4 Revocation request grace period - 失効申請の猶予期間
    • 4.9.5 Time within which CA must process the revocation request - CAが失効処理する時間
    • 4.9.6 Revocation checking requirement for relying parties - 検証者に対する失効確認要件
    • 4.9.7 CRL issuance frequency - CRLの発行頻度
    • 4.9.8 Maximum latency for CRLs (if applicable) - CRL発行の最大遅延 (該当する場合)
    • 4.9.9 On-line revocation/status checking availability - オンライン失効/ステータス確認の可用性
    • 4.9.10 On-line revocation checking requirements - オンライン失効確認の要件
    • 4.9.11 Other forms of revocation advertisements available - その他の形式での証明書有効性確認方法
    • 4.9.12 Special requirements re key compromise - 鍵危殆化の特別要件
    • 4.9.13 Circumstances for suspension - 証明書一時停止の要件
    • 4.9.14 Who can request suspension - 証明書一時停止を要求できる者
    • 4.9.15 Procedure for suspension request - 証明書一時停止要求の手順
    • 4.9.16 Limits on suspension period - 一時停止可能期間
  • 4.10 Certificate status services - 証明書有効性確認サービス
    • 4.10.1 Operational characteristics - 運用特性
    • 4.10.2 Service availability - サービスの可用性
    • 4.10.3 Optional features - オプション機能
  • 4.11 End of subscription - 利用者の利用終了
  • 4.12 Key escrow and recovery - キーエスクロー（鍵預託）と鍵回復
    • 4.12.1 Key escrow and recovery policy and practices - キーエスクロー（鍵預託）と回復に関するポリシーと実施手順
    • 4.12.2 Session key encapsulation and recovery policy and practices - セッション鍵のカプセル化および鍵回復に関するポリシーと実施手順
• 5. MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS -管理、運用、物理的制御
  • 5.1 Physical Security Controls - 物理的セキュリティ管理
    • 5.1.1 Site location and construction - 立地場所と建築構造
    • 5.1.2 Physical access - 物理的アクセス
    • 5.1.3 Power and air conditioning - 電力と空調
    • 5.1.4 Water exposures - 水害対策
    • 5.1.5 Fire prevention and protection - 防火対策
    • 5.1.6 Media storage - 媒体保管
    • 5.1.7 Waste disposal - 廃棄処理
    • 5.1.8 Off-site backup - オフサイトバックアップ
  • 5.2 Procedural controls - 手順の管理
    • 5.2.1 Trusted roles - 信頼された役割
    • 5.2.2 Number of Individuals Required per Task - 職務ごとに必要とされる人数
    • 5.2.3 Identification and authentication for each role - 各役割の本人性確認と認証
    • 5.2.4 Roles requiring separation of duties - 各役割の権限分割
  • 5.3 Personnel controls - 人事管理
    • 5.3.1 Qualifications, experience, and clearance requirements - 資格、経歴およびクリアランス要件
    • 5.3.2 Background check procedures - 身元調査の手順
    • 5.3.3 Training Requirements and Procedures - 教育要件と手順
    • 5.3.4 Retraining frequency and requirements - 再教育の頻度および要件
    • 5.3.5 Job rotation frequency and sequence - ジョブローテーションの頻度と方法
    • 5.3.6 Sanctions for unauthorized actions - 不正行為に対する制裁
    • 5.3.7 Independent Contractor Controls - 委託契約の要件
    • 5.3.8 Documentation supplied to personnel - 担当者に提供される文書
  • 5.4 Audit logging procedures - 監査ログ手順
    • 5.4.1 Types of events recorded - 記録されるイベントの種類
      • 5.4.1.1 Router and firewall activities logs - ルーターとファイアウォールのアクティビティログ
      • 5.4.1.2 Types of events recorded for Timestamp Authorities - タイムスタンプ局に記録されるイベントの種類
    • 5.4.2 Frequency of processing audit log - 監査ログの処理頻度
    • 5.4.3 Retention period for audit log - 監査ログの保管期間
    • 5.4.4 Protection of audit log - 監査ログの保護
    • 5.4.5 Audit log backup procedures - 監査ログのバックアップ手順
    • 5.4.6 Audit collection System (internal vs. external) - 監査収集システム（内部および外部）
    • 5.4.7 Notification to event-causing subject - イベントの要因となるサブジェクトへの通知
    • 5.4.8 Vulnerability assessments - 脆弱性アセスメント
  • 5.5 Records archival - 記録のアーカイブ
    • 5.5.1 Types of records archived - アーカイブされる記録の種類
    • 5.5.2 Retention period for archive - アーカイブ保存期間
    • 5.5.3 Protection of archive - アーカイブ保護
    • 5.5.4 Archive backup procedures - アーカイブバックアップ手順
    • 5.5.5 Requirements for time-stamping of records - 記録のタイムスタンプ要件
    • 5.5.6 Archive collection system (internal or external) - アーカイブ収集システム (内部または外部)
    • 5.5.7 Procedures to obtain and verify archive information - アーカイブ情報の取得および検証手順
  • 5.6 Key changeover - 鍵の切り替え
  • 5.7 Compromise and disaster recovery - 危殆化および災害復旧
    • 5.7.1 Incident and compromise handling procedures - インシデントおよび危殆化対応手順
    • 5.7.2 Recovery Procedures if Computing resources, software, and/or data are corrupted - コンピューティングリソース、ソフトウェア、データが破損した場合の復旧手順
    • 5.7.3 Recovery Procedures after Key Compromise - 鍵危殆化発生後の復旧手順
    • 5.7.4 Business continuity capabilities after a disaster - 災害後の事業継続
  • 5.8 CA or RA termination - CAまたはRAの終了
• 6. TECHNICAL SECURITY CONTROLS - 技術的セキュリティ管理
  • 6.1 Key pair generation and installation - 鍵ペアの生成とインストール
    • 6.1.1 Key pair generation - 鍵ペアの生成
      • 6.1.1.1 CA Key Pair Generation - CA鍵ペアの生成
      • 6.1.1.2 RA Key Pair Generation - RA鍵ペアの生成
      • 6.1.1.3 Subscriber Key Pair Generation - 利用者鍵ペアの生成
    • 6.1.2 Private key delivery to subscriber - 利用者への私有鍵配布
    • 6.1.3 Public key delivery to certificate issuer - 証明書発行者への公開鍵配布
    • 6.1.4 CA public key delivery to relying parties - 検証者へのCA公開鍵配布
    • 6.1.5 Key sizes - 鍵サイズ
    • 6.1.6 Public key parameters generation and quality checking - 公開鍵パラメーターの生成と品質確認
    • 6.1.7 Key usage purposes (as per X.509 v3 key usage field) - 鍵の使用目的（X.509 v3 key usageフィールドに準拠）
  • 6.2 Private Key Protection and Cryptographic Module Engineering Controls - 私有鍵の保護および暗号モジュールの運用管理
    • 6.2.1 Cryptographic module standards and controls - 暗号モジュールの規格と管理
    • 6.2.2 Private key (n out of m) multi-person control - 私有鍵の複数人管理
    • 6.2.3 Private key escrow - 私有鍵のエスクロー
    • 6.2.4 Private key backup - 私有鍵のバックアップ
    • 6.2.5 Private key archival - 私有鍵のアーカイブ
    • 6.2.6 Private key transfer into or from a cryptographic module - 私有鍵の暗号モジュールへの移行または暗号モジュールからの移行
    • 6.2.7 Private key storage on cryptographic module - 暗号モジュールでの私有鍵保管
    • 6.2.8 Activating Private Keys - 私有鍵の活性化
    • 6.2.9 Deactivating Private Keys - 私有鍵の非活性化
    • 6.2.10 Destroying Private Keys - 私有鍵の破棄
    • 6.2.11 Cryptographic Module Rating - 暗号モジュールの評価
  • 6.3 Other aspects of key pair management - 鍵ペア管理に関するその他の事項
    • 6.3.1 Public key archival - 公開鍵のアーカイブ
    • 6.3.2 Certificate operational periods and key pair usage periods - 証明書有効期間と鍵ペア使用期間
  • 6.4 Activation data - アクティベーションデータ
    • 6.4.1 Activation data generation and installation - アクティベーションデータの生成と設定
    • 6.4.2 Activation data protection - アクティベーションデータの保護
    • 6.4.3 Other aspects of activation data - アクティベーションデータに関するその他の事項
  • 6.5 Computer security controls - コンピューターのセキュリティ管理
    • 6.5.1 Specific computer security technical requirements - 特定のコンピューターのセキュリティ技術要件
    • 6.5.2 Computer security rating - コンピューターのセキュリティ評価
  • 6.6 Life cycle technical controls - ライフサイクルの技術的管理
    • 6.6.1 System development controls - システム開発の管理
    • 6.6.2 Security management controls - セキュリティ運用管理
    • 6.6.3 Life cycle security controls - ライフサイクルセキュリティの管理
  • 6.7 Network security controls - ネットワークセキュリティの管理
  • 6.8 Time-stamping - タイムスタンプ
• 7. CERTIFICATE, CRL, AND OCSP PROFILES - 証明書、CRLおよびOCSP プロファイル
  • 7.1 Certificate profile - 証明書プロファイル
    • 7.1.1 Version number(s) - バージョン番号
    • 7.1.2 Certificate Content and Extensions - 証明書拡張
      • 7.1.2.1 Root CA Certificate Profile - Root CA 証明書プロファイル
        • 7.1.2.1.1 Root CA Validity - Root CA の有効期間
        • 7.1.2.1.2 Root CA Extensions - Root CA 拡張
        • 7.1.2.1.3 Root CA Authority Key Identifier - Root CA 認証局鍵識別子
        • 7.1.2.1.4 Root CA Basic Constraints - Root CA の基本制約
      • 7.1.2.2 Cross-Certified Subordinate CA Certificate Profile - クロス認証下位CA証明書プロファイル
        • 7.1.2.2.1 Cross-Certified Subordinate CA Validity - クロス認証下位CAの有効期間
        • 7.1.2.2.2 Cross-Certified Subordinate CA Naming - クロス認証下位CAの識別名
        • 7.1.2.2.3 Cross-Certified Subordinate CA Extensions - クロス認証下位CA拡張
        • 7.1.2.2.4 Cross-Certified Subordinate CA Extended Key Usage - Unrestricted - クロス認証下位CA拡張鍵使用法 - 制約無し
        • 7.1.2.2.5 Cross-Certified Subordinate CA Extended Key Usage - Restricted - クロス認証下位CA拡張鍵使用法 - 制約あり
        • 7.1.2.2.6 Cross-Certified Subordinate CA Certificate Certificate Policies - クロス認証下位CA証明書のCP
      • 7.1.2.3 Technically Constrained Non-TLS Subordinate CA Certificate Profile - 技術的に制約された非TLS下位CA証明書プロファイル
        • 7.1.2.3.1 Technically Constrained Non-TLS Subordinate CA Extensions - 技術的に制約された非TLS下位CA拡張
        • 7.1.2.3.2 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 - 技術的に制約された非TLS下位CA拡張鍵使用法
      • 7.1.2.4 Technically Constrained Precertificate Signing CA Certificate Profile - 技術的に制約された事前証明書サイニングCA証明書プロファイル
        • 7.1.2.4.1 Technically Constrained Precertificate Signing CA Extensions - 技術的に制約された事前証明書サイニングCA拡張
        • 7.1.2.4.2 Technically Constrained Precertificate Signing CA Extended Key Usage - 技術的に制約された事前証明書サイニングCA拡張鍵使用法
      • 7.1.2.5 Technically Constrained TLS Subordinate CA Certificate Profile - 技術的に制約されたTLS下位CA証明書プロファイル
        • 7.1.2.5.1 Technically Constrained TLS Subordinate CA Extensions - 技術的に制約されたTLS下位CA拡張
        • 7.1.2.5.2 Technically Constrained TLS Subordinate CA Name Constraints - 技術的に制約されたTLS下位CA名前制約
      • 7.1.2.6 TLS Subordinate CA Certificate Profile - TLS下位CA証明書プロファイル
        • 7.1.2.6.1 TLS Subordinate CA Extensions - TLS下位CA拡張
      • 7.1.2.7 Subscriber (Server) Certificate Profile - 利用者（サーバー）証明書プロファイル
        • 7.1.2.7.1 Subscriber Certificate Types - 利用者証明書のタイプ
        • 7.1.2.7.2 Domain Validated - ドメイン認証（DV）
        • 7.1.2.7.3 Individual Validated - 個人認証（IV）
        • 7.1.2.7.4 Organization Validated - 組織認証（OV）
        • 7.1.2.7.5 Extended Validation - 拡張認証（EV）
        • 7.1.2.7.6 Subscriber Certificate Extensions - 利用者証明書の拡張
        • 7.1.2.7.7 Subscriber Certificate Authority Information Access - 利用者証明書の権限情報アクセス
        • 7.1.2.7.8 Subscriber Certificate Basic Constraints - 利用者証明書の基本制約
        • 7.1.2.7.9 Subscriber Certificate Certificate Policies - 利用者証明書の証明書ポリシー
        • 7.1.2.7.10 Subscriber Certificate Extended Key Usage - 利用者証明書の拡張鍵使用法
        • 7.1.2.7.11 Subscriber Certificate Key Usage - 利用者証明書の鍵使用法
        • 7.1.2.7.12 Subscriber Certificate Subject Alternative Name - 利用者証明書の主体者識別名代替名
      • 7.1.2.8 OCSP Responder Certificate Profile - OCSPレスポンダー証明書プロファイル
        • 7.1.2.8.1 OCSP Responder Validity - OCSPレスポンダーの有効期限
        • 7.1.2.8.2 OCSP Responder Extensions - OCSP レスポンダーの拡張
        • 7.1.2.8.3 OCSP Responder Authority Information Access - OCSPレスポンダーの機関情報アクセス
        • 7.1.2.8.4 OCSP Responder Basic Constraints - OCSPレスポンダー基本制約
        • 7.1.2.8.5 OCSP Responder Extended Key Usage - OCSPレスポンダー拡張鍵使用法
        • 7.1.2.8.6 OCSP Responder id-pkix-ocsp-nocheck - OCSPレスポンダー id-pkix-ocsp-nocheck
        • 7.1.2.8.7 OCSP Responder Key Usage - OCSPレスポンダー鍵の使用法
        • 7.1.2.8.8 OCSP Responder Certificate Policies - OCSPレスポンダー証明書ポリシー
      • 7.1.2.9 Precertificate Profile - 事前証明書プロファイル
        • 7.1.2.9.1 Precertificate Profile Extensions - Directly Issued - 事前証明書プロファイル拡張 - 直接発行
        • 7.1.2.9.2 Precertificate Profile Extensions - Precertificate CA Issued - 事前証明書プロファイル拡張 - CA発行の事前証明書
        • 7.1.2.9.3 Precertificate Poison - 事前証明書ポイズン
        • 7.1.2.9.4 Precertificate Authority Key Identifier - 事前証明書局鍵識別子
      • 7.1.2.10 Common CA Fields - 共通CAフィールド
        • 7.1.2.10.1 CA Certificate Validity - CA証明書の有効期限
        • 7.1.2.10.2 CA Certificate Naming - CA証明書の識別名
        • 7.1.2.10.3 CA Certificate Authority Information Access - CA証明書の機関情報アクセス
        • 7.1.2.10.4 CA Certificate Basic Constraints - CA証明書の基本制約
        • 7.1.2.10.5 CA Certificate Certificate Policies - CA証明書の証明書ポリシー
        • 7.1.2.10.6 CA Certificate Extended Key Usage - CA証明書の拡張鍵使用法
        • 7.1.2.10.7 CA Certificate Key Usage - CA証明書鍵の使用法
        • 7.1.2.10.8 CA Certificate Name Constraints - CA証明書の名前制約
      • 7.1.2.11 Common Certificate Fields - 共通証明書フィールド
        • 7.1.2.11.1 Authority Key Identifier - 認証局鍵識別子
        • 7.1.2.11.2 CRL Distribution Points - CRL配布ポイント
        • 7.1.2.11.3 Signed Certificate Timestamp List - 署名された証明書のタイムスタンプリスト
        • 7.1.2.11.4 Subject Key Identifier - 主体者識別名鍵識別子
        • 7.1.2.11.5 Other Extensions - その他の拡張
    • 7.1.3 Algorithm object identifiers - アルゴリズムオブジェクト識別子
      • 7.1.3.1 SubjectPublicKeyInfo - 主体者公開鍵情報
        • 7.1.3.1.1 RSA - RSA
        • 7.1.3.1.2 ECDSA - ECDSA
      • 7.1.3.2 Signature AlgorithmIdentifier - 署名アルゴリズム識別子
        • 7.1.3.2.1 RSA - RSA
        • 7.1.3.2.2 ECDSA - ECDSA
    • 7.1.4 Name Forms - 名前形式
      • 7.1.4.1 Name Encoding - 名前のエンコード
      • 7.1.4.2 Subject Attribute Encoding - 主体者識別名属性のエンコード
      • 7.1.4.3 Subscriber Certificate Common Name Attribute - 利用者証明書のコモンネーム属性
      • 7.1.4.4 Other Subject Attributes - その他の主体者識別名属性
    • 7.1.5 Name constraints - 名前制約
    • 7.1.6 Certificate policy object identifier - 証明書ポリシーオブジェクト識別子
      • 7.1.6.1 Reserved Certificate Policy Identifiers - 予約済み証明書ポリシー識別子
    • 7.1.7 Usage of Policy Constraints extension - ポリシー制約拡張の使用
    • 7.1.8 Policy qualifiers syntax and semantics - ポリシー修飾子の構文および意味
    • 7.1.9 Processing semantics for the critical Certificate Policies extension - 重要な証明書ポリシー拡張の意味
  • 7.2 CRL profile - CRLプロファイル
    • 7.2.1 Version number(s) - バージョン番号
    • 7.2.2 CRL and CRL entry extensions - CRLとCRLエントリー拡張
      • 7.2.2.1 CRL Issuing Distribution Point - CRL発行配布ポイント
  • 7.3 OCSP profile - OCSPプロファイル
    • 7.3.1 Version number(s) - バージョン番号
    • 7.3.2 OCSP extensions - OCSP拡張
• 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS - 準拠性監査とその他の監査基準
  • 8.1 Frequency or circumstances of assessment - 評価の頻度と要件
  • 8.2 Identity/qualifications of assessor - 監査人の身元/資格
  • 8.3 Assessor's relationship to assessed entity - 監査人と被監査部門の関係
  • 8.4 Topics covered by assessment - 監査で扱われる事項
  • 8.5 Actions taken as a result of deficiency - 不備に対する対応
  • 8.6 Communication of results - 監査結果の公開
  • 8.7 Self-Audits - 自己監査
  • 8.8 Review of delegated parties - 委託先のレビュー
• 9. OTHER BUSINESS AND LEGAL MATTERS - その他の業務上および法的事項
  • 9.1 Fees - 料金
    • 9.1.1 Certificate issuance or renewal fees - 証明書の発行/更新手数料
    • 9.1.2 Certificate access fees - 証明書アクセス料金
    • 9.1.3 Revocation or status information access fees - 失効またはステータス情報アクセス料金
    • 9.1.4 Fees for other services - その他のサービス料金
    • 9.1.5 Refund policy - 返金ポリシー
  • 9.2 Financial responsibility - 財務的責任
    • 9.2.1 Insurance coverage - 保険適用範囲
    • 9.2.2 Other assets - その他の資産
    • 9.2.3 Insurance or warranty coverage for end-entities - エンドエンティティに対する保険または保証範囲
  • 9.3 Confidentiality of business information - 企業情報の機密保持
    • 9.3.1 Scope of confidential information - 機密情報の範囲
    • 9.3.2 Information not within the scope of confidential information - 機密情報の範囲外の情報
    • 9.3.3 Responsibility to protect confidential information - 機密情報の保護責任
  • 9.4 Privacy of personal information - 個人情報保護方針
    • 9.4.1 Privacy plan - 個人情報保護プラン
    • 9.4.2 Information treated as private - 個人情報として扱われる情報
    • 9.4.3 Information not deemed private - 個人情報と見なされない情報
    • 9.4.4 Responsibility to protect private information - 個人情報の保護責任
    • 9.4.5 Notice and consent to use private information - 個人情報利用に関する通知と同意
    • 9.4.6 Disclosure pursuant to judicial or administrative process - 司法または行政手続に沿った情報開示
    • 9.4.7 Other information disclosure circumstances - その他の情報開示要件
  • 9.5 Intellectual property rights - 知的財産権
  • 9.6 Representations and warranties - 表明および保証
    • 9.6.1 CA representations and warranties - CAの表明および保証
    • 9.6.2 RA representations and warranties - RAの表明および保証
    • 9.6.3 Subscriber representations and warranties - 利用者の表明および保証
    • 9.6.4 Relying party representations and warranties - 検証者の表明および保証
    • 9.6.5 Representations and warranties of other participants - その他関係者の表明および保証
  • 9.7 Disclaimers of warranties - 保証の免責
  • 9.8 Limitations of liability - 責任の制限
  • 9.9 Indemnities - 補償
  • 9.10 Term and termination - CP/CPSの効力開始と終了
    • 9.10.1 Term - CP/CPSの効力開始
    • 9.10.2 Termination - CP/CPSの効力終了
    • 9.10.3 Effect of termination and survival - CP/CPSの効力継続
  • 9.11 Individual notices and communications with participants - 関係者への個別通知および連絡
  • 9.12 Amendments - 改訂
    • 9.12.1 Procedure for amendment - 改訂手続
    • 9.12.2 Notification mechanism and period - 通知方法および期間
    • 9.12.3 Circumstances under which OID must be changed - OIDが変更されなければならない要件
  • 9.13 Dispute resolution provisions - 紛争解決手続
  • 9.14 Governing law - 準拠法
  • 9.15 Compliance with applicable law - 適用法の遵守
  • 9.16 Miscellaneous provisions - 雑則
    • 9.16.1 Entire agreement - 完全合意条項
    • 9.16.2 Assignment - 権利譲渡条項
    • 9.16.3 Severability - 分離条項
    • 9.16.4 Enforcement (attorneys' fees and waiver of rights) - 強制執行条項
    • 9.16.5 Force Majeure - 不可抗力条項
  • 9.17 Other provisions - その他条項
• APPENDIX A – CAA Contact Tag - 付録 A – CAA連絡先タグ
  • A.1. CAA Methods - CAAメソッド
    • A.1.1. CAA contactemail Property - contactemail プロパティ
    • A.1.2. CAA contactphone Property - CAA contactphone プロパティ
  • A.2. DNS TXT Methods - DNS TXT メソッド
    • A.2.1. DNS TXT Record Email Contact - DNS TXT Record Email連絡先
    • A.2.2. DNS TXT Record Phone Contact - DNS TXT Record 電話連絡先
• APPENDIX B – Certificate profile - 付録 B – 証明書プロファイル
  • Table : "Security Communication RootCA2" and Subordinate CAs
  • Table : "Security Communication RootCA3" and Subordinate CAs
  • Table : "Security Communication ECC RootCA1" 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 TLS RSA 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 : 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 (AATL Document Signing Certificates)
  • Table: Subscriber Certificates (S/MIME Certificates)
  • 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 TimeStamping Subordinate CA Certificates (Issued after 2018-06-07)
  • Table: SECOM TimeStamping CA2 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 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 に準拠しており、英語版を正式版とし、英語版CP/CPSとバージョン番号を一致させて公開する。本CP/CPSは、英語版のSection名称の下に日本語のSection名称を記載する。

1.1.1 Standards, Criteria and Regulations

1.1.1 基準、評価基準および規則

認証局（CA）は、CA/ブラウザフォーラムおよびアプリケーションソフトウェアサプライヤーによって定められた基準、評価基準、規則の最新バージョンに準拠する。

CAが従うべき監査スキームについては、Section 8.4を参照。

表: 基準、評価基準および規則リスト

* 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 (セコムトラストシステムズ株式会社)

Root CA から下位 CA 証明書を発行するときに使用される OID

表: OID (Root CA CP)

下位 CA から EE 証明書を発行するときに使用する OID

表: OID（下位 CA CP）

1.2.1 Revisions

1.2.1 改訂

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で定義されている用語である。

1.3.2 Registration Authorities

1.3.2 登録局（RA）

Section 3.2.2.4およびSection 3.2.2.5を除いて、CAはSection 3.2の要件のすべてまたは一部の実行を外部委託先に委任することができる。ただし、プロセス全体がSection 3.2の要件をすべて満たしている場合に限る。

CAが外部委託先に委任機能を実行する権限を与える前に、CAは契約上、外部委託先に以下のいずれかを要求しなければならない。

1. 委託した職務に該当する場合、Section 5.3.1,の資格要件を満たす。
2. Section 5.5.2に従い、ドキュメントを保持する。
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を参照）か、「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またはSection 3.2.2.1.3に従って確認しなければならない。

CAは、これらの制限をEnterprise RAに対する契約上の要件として課し、Section 8.8に従ってEnterprise RAの遵守を監視しなければならない。 Enterprise RAは、委任された組織の承認または管理下にないユーザーのために、Mailbox-validatedプロファイルを使用して証明書リクエストを提出することもできる。この場合、CAは、要求されたメールボックスアドレスに対するメールボックス保有者の管理権限をSection 3.2.2.1.2に従って確認しなければならない。

1.3.3 Subscribers

1.3.3 利用者

利用者とは、CA が発行した証明書を受け取り、利用者契約または利用規約に準拠する自然人または法人を指す。 利用者は、CA が発行する証明書の対象となる鍵ペアを自らの権利で生成する。利用者は、CA に証明書の申請を提出し、発行された証明書を受理した時点で利用者としての資格を得る。利用者は、使用目的に照らして本条項を評価し、これに同意する必要がある。

1.3.4 Relying Parties

1.3.4 検証者

検証者とは、有効な証明書を依拠する自然人または法人を指す。アプリケーションソフトウェアサプライヤーによって配布されるソフトウェアが単に証明書に関連する情報を表示するだけの場合、そのサプライヤーは検証者とは見なされない。 検証者は、CAが発行する証明書の有効性を認証する存在である。検証者は、自らの利用目的に照らして、本条項の内容を確認し同意した上で、認証および信認を行うものとみなされる。

「検証者」および「アプリケーションソフトウェアサプライヤー」は、Section 1.6.1で定義されている。アプリケーションソフトウェアサプライヤーであるCA/ブラウザフォーラムの現在のメンバーは、次の URL にリストされている: https://cabforum.org/members。

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 に従って検証されたドメイン所有者から、ドメインの使用権限があることが確認されない限り、証明書の発行を許可しない。

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では、失効する必要があると判断した場合、証明書を失効する。

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 で定義されている。

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 (https://tools.ietf.org/html/rfc8659)から引用:「認証局認可 (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に従って、証明書の内容と証明書の拡張の要件を定義する一連のドキュメントまたはファイル。例えば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で定義されたEmailアドレス。

DNS CAA Phone Contact (DNS CAA電話連絡先): Appendix A.1.2で定義された電話番号。

DNS TXT Record Email Contact (DNS TXT Record Email連絡先): Appendix A.2.1で定義されたEmailアドレス。

DNS TXT Record Phone Contact (DNS TXT Record 電話連絡先): Appendix A.2.2で定義された電話番号。

Domain Contact (ドメイン連絡担当者): ベースドメイン名のWHOISレコードまたはDNS SOAレコードに記載されている、もしくはドメイン名レジストラとの直接の連絡を通じて取得されたドメイン名登録者、技術担当者、あるいは管理担当者 (または ccTLD における同等の担当者)。

Domain Label (ドメインラベル): RFC 8499 (https://tools.ietf.org/html/rfc8499)から引用:「ドメイン名の一部を構成する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 (https://tools.ietf.org/html/rfc5890)から引用: 「ASCII 文字、数字、ハイフンで構成される文字列。さらに、ハイフンは文字列の先頭または末尾に出現できないという制限がある。すべての DNS ラベルと同様に、合計の長さは 63 オクテットを超えてはならない。」

Legal Entity (法人): 国の法制度において法的地位を持つ協会、法人、パートナーシップ、個人事業体、信託、政府組織、またはその他の団体。

Legal Existence (法的存在): 民間組織、政府組織、または事業体は、有効に設立され、終了、解散、または放棄されていない場合、法的な存在となる。

Legal Practitioner (法務担当者): EV Guidelinesに記載されている弁護士またはラテン公証人のいずれかであり、申請者の事実上の主張について意見を述べる資格を有する者。

Linting (リンティング): 事前証明書 [RFC 6962]、証明書、証明書失効リスト、OCSP 応答などのデジタル署名されたデータ、または tbsCertificate ( RFC 5280, 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 (https://tools.ietf.org/html/rfc5890) からの引用: 「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 で定義され、関連するプロファイルで許可されているように、署名済み証明書タイムスタンプ リストを追加してから、証明書に署名することができる。

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の要件を満たす自然人または法人。

Qualified Government Information Source (認定政府情報源): Section 3.2.2.2.10.6 の要件を満たす政府組織によって管理されるデータベース (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 <r2.csr` \| sed "s/[ -]//g" スクリプト出力： 201602251811c9c863405fe7675a3988b97664ea6baf442019e4e52fa335f406f7c5f26cf14f

Required Website Content (必要なウェブサイトコンテンツ): ランダム値またはリクエストトークンのいずれかと、CAによって指定された利用者を一意に識別する追加情報。

Requirements (要件): 本CP/CPSに記載されているBaseline Requirements。

Reserved IP Address (予約済IPアドレス): 次のIANAレジストリのいずれかのエントリーのアドレスブロックに含まれているIPv4またはIPv6アドレス：

https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml

https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

Root CA: 下位CA証明書を発行する最上位の認証局。Root CAのRoot 証明書は、アプリケーションソフトウェアサプライヤーによって配布される。

Root Certificate (Root 証明書): 自身を識別するため、また下位CAに発行される証明書の検証を容易にするためにルートCAが発行する自己署名証明書。

Root Key Generation Script (ルート鍵生成スクリプト): ルートCA鍵ペアの生成のために実行される手順の文書化された計画。

RSA: 公開鍵暗号システムで広く使用されている最も標準的な暗号化技術の 1つ。

SHA-1 (Secure Hash Algorithm 1) (セキュアハッシュアルゴリズム1): デジタル署名で使用されるハッシュ関数。ハッシュ関数は、指定されたテキストから固定長の文字列を生成する計算手法である。ハッシュ長は 160 ビットである。このアルゴリズムは、送信されたハッシュ値と受信されたハッシュ値を比較することで、送信中に元のメッセージが変更されたかどうかを検出するように機能する。

SHA-2 (Secure Hash Algorithm 2) (セキュアハッシュアルゴリズム2): デジタル署名などに用いられるSecure Hash Algorithmシリーズのハッシュ関数で、SHA-1を改良したもの。SHA-256のビット長は256ビット、SHA-384のビット長は384ビット。データの送信側と受信側でハッシュ値を比較することで、通信中に原文が改ざんされていないかを検出する仕組み。

Short-lived Subscriber Certificate (ショートリブド利用者証明書): 2024年3月15日以降、2026年3月15日より前に発行される証明書では有効期間が10日 (864,000 秒) 以下の利用者証明書。2026年3月15日以降に発行される証明書では有効期間が7日 (604,800 秒) 以下の利用者証明書。

Sovereign State (主権国家): 自身の政府を自身で運営し、他の強国に依存していない、または支配されていない国のこと。

Subject (主体者識別名): 証明書において主体者識別名として識別されている個人、デバイス、システム、設備、または法人。主体者識別名は、利用者もしくは、利用者の管理および運用下にあるデバイスである。

Subject Identity Information (主体者識別名識別情報): 証明書の主体者識別名を識別する情報。主体者識別名識別情報には、subjectAltName拡張領域または主体者識別名commonNameフィールドで指定されるドメイン名は含まれない。

Subordinate CA (下位CA): 証明書がRoot CAまたは別の下位CAによって署名されている認証局。

Subscriber (利用者): 証明書の発行先であり、利用者契約または利用規約によって法的に拘束される自然人または法人。

Subscriber Agreement (利用者契約): CAと申請者/利用者間で締結される、両当事者の権利と義務を定めた契約書。

Subsidiary Company (子会社): 親会社によって支配されている会社。

Technically Constrained Subordinate CA Certificate (技術的に制約された下位CA証明書): 下位CA証明書が利用者または追加の下位CA証明書を発行できる範囲を制限するために、このドキュメントの関連する証明書プロファイル内で定義されているように、拡張キー使用法/名前制約拡張の組み合わせを使用する下位CA証明書。

Terms of Use (利用規約): 申請者/利用者がCAの関連会社である場合、Baseline Requirementsに従って発行される証明書の保管および利用に関する規約。

Test Certificate (テスト証明書): この用語は、Baseline Requirementsでは現在使用されない。

Trustworthy System (信頼できるシステム): 侵入や不正使用から合理的に保護されており、合理的なレベルの可用性、信頼性および正しい運用を提供し、意図される職務の履行に合理的に適しており、かつ適用すべきセキュリティポリシーを施行しているコンピュータハードウェア、ソフトウェアおよび手順。

Unregistered Domain Name (未登録ドメイン名): 登録ドメイン名ではないドメイン名。

Valid Certificate (有効な証明書): RFC 5280で指定された検証手順に合格した証明書。

Validation Specialist (検証スペシャリスト): Baseline Requirementsに定める情報検証業務を行う者。

Validity Period (有効期間): RFC 5280 (https://tools.ietf.org/html/rfc5280)からの引用: 「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 (https://tools.ietf.org/html/rfc5890)からの引用: 「接頭辞"xn--"（大文字と小文字は区別されない）で始まるラベルのクラスだが、それ以外はLDHラベルの規則に準拠している。」

X.500: 分散ディレクトリサービスに関する一連のコンピュータネットワーク標準。

X.509: X.509 ITU-T 証明書および CRL 形式。X.509 v3 (バージョン 3) では、任意の情報を保持するための拡張領域が追加された。

1.6.2 Acronyms

1.6.2 頭字語

1.6.3 References

1.6.3 参照

Section 1.1 を参照。

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))。

セコムトラストシステムズは、http://www.cabforum.org で公開されている「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 の最新バージョンをCAがどのように実装しているかを詳細に記述したCP/CPSを作成、実施、施行し、毎年更新する (SHALL)。CAは、CP/CPSに他の変更が加えられていない場合でも、バージョン番号を増やし、日付付きの変更ログエントリーを追加することで、 Section 1.1.1 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 およびSection 3.1.2 で定義されているとおりに解釈される。

さまざまな名前形式の解釈に関する規則は、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 ならびにCAのCPおよびCPSに記載された要件を満たした検証プロセスを使用して、主体者識別名に関連付けられた国を検証する (SHALL)。申請者がcountryNameフィールドとその他の主体者識別名識別情報を含む証明書を申請する場合、CAは、Section 3.2.2.1 ならびにCAのCPおよびCPSに記載された要件を満たした検証プロセスを使用して、申請者のアイデンティティと、申請権限者の証明書要求の信頼性を検証する(SHALL)。CAは、本Sectionに基づいて信頼されたドキュメントに改編や偽造がないか検査する (SHALL)。

[EV TLSサーバー証明書]

EV証明書発行時に使用する検証元は、以下のURLで公開される。

https://www.secomtrust.net/service/pfw/apply/ev/list.html

[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 で承認された方法のみを使用する (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 で定義されているアドレス解決アルゴリズムを使用して識別され、特定のメールボックス アドレスに対してどの SMTP FQDN が権限を持つかを決定する (SHALL)。複数の SMTP FQDN が検出された場合、CAは、RFC 5321 Section 5.1 の選択プロセスに従って SMTP FQDN の制御を検証する (SHALL)。MX レコード RDATA 内のエイリアスは、この検証方法では使用されない (SHALL NOT)。

申請者の SMTP FQDN の制御を確認するために、CAは Section 3.2.2.4 で現在承認されている方法のみを使用する (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 を次のように設定する。

法人番号と設立年月日がCAで確認できない場合は、serialNumber に次のテキストを入力する。

利用者が次の場合、CAは businessCategory を次のように設定する。

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 (1)に記載されているすべての項目は、申請者の設立または登録の管轄区域内の設立または登録機関に直接確認されるか、直接入手されなければならない (MUST)。そのような検証は、設立または登録機関によって、あるいは設立もしくは登録機関に代わって運営される認定政府情報源を使用することによって、または認定政府情報源、設立あるいは登録機関、もしくは認定独立情報源から直接取得した住所または電話番号を使用して、設立あるいは登録機関に直接連絡するか、郵便、Email、Webアドレス、もしくは電話で連絡することによって行うことができる (MAY)。

2. 政府組織の主体者識別名: 6項に基づいて検証されない限り、Section 3.2.2.2.1.1(2) に列挙されているすべての項目は、次のいずれかに直接検証されるか、直接入手されなければならない (MUST)。

   i. 当該政府組織が運営する行政区分内の認定政府情報源。 ii. 申請者と同じ行政区分に属する上位の政府組織。 iii. その政治区分内の連邦、州、または地方裁判所の現役裁判官から。

   裁判官からのあらゆる連絡は、Section 3.2.2.2.10.1 に規定されているように弁護士が主張する事実の主張を検証するために使用されるのと同じ方法で検証される (SHALL)。

   このような確認は、適切な政府組織に直接連絡して行うか、または適格な独立情報源から取得した住所または電話番号を使用して、郵便、Email、Web アドレス、または電話を介して行うことができる (MAY)。

3. 事業体の主体者識別名: 6項に基づいて検証されない限り、上記 Section 3.2.2.2.1.1 (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 (4)に記載されているすべての項目は、次のいずれかの方法で検証されなければならない (MUST)。

   A. 国際機関が設立された設立文書を参照している B. CAが事業を行うことが許可されている署名国の政府と直接関係している。このような証明は、適切な政府機関またはその国の法律から、または、その国の政府が国際機関でその国を代表する任務を持っていることを確認することによって取得できる。 C. CA/ブラウザフォーラムが https://www.cabforum.org で維持している、資格のあるエンティティの現在のリストに直接対している。 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 で使用される関連する認定政府情報源に示されている事業所と同じではない場合

   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 で使用される 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 に基づく政府組織の法的存在の確認に依拠することができる (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に記載、または、契約署名者/証明書承認者が申請者の従業員であるか、もしくは申請者の代理人として任命されていることを確認する専門家による確認書を取得する。 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に記載)。

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 の手順のいずれかに従って、契約署名者の署名権限を確認した。

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 に従って事前承認されていない限り、文書を提出する証明書要求者によって署名されなければならない (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 の要件に従って証明書承認者が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 に従って、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 (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 (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 (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、Section 3.2.2.2.4、 Section 3.2.2.2.5.1、または Section 3.2.2.2.6.1で許可されている場合、申請者と親会社、子会社、または関連会社との関係を検証しなければならない (MUST)。申請者と親会社、子会社、または関連会社との関係を検証する許容される方法は次のとおりである。

1. QIIS または QGIS: 申請者と親会社、子会社、または関連会社との関係は QIIS または QGIS で特定される。

2. 親会社、子会社、または関連会社からの独立した確認: CAは、適切な親会社、子会社、または関連会社から独立した確認を取得することにより、申請者と親会社、子会社、または関連会社との関係を確認することができる (MAY)(Section 3.2.2.2.10.4に記載)。

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 に含まれるすべての資格要件を満たすために、適切なトレーニング、経験、判断力を備えた管理下の従業員を使用して、この最終的な相互照合および適切な精査のSectionの要件を実行しなければならない (MUST)。CAの管理下にある従業員が最終的な相互照合および適切な精査を実行するために必要な言語スキルを持っていない場合、CAは次のことを行うことができる (MAY)。

   A. 翻訳者が翻訳を受け取った場合、文書の関連部分の言語翻訳に依拠する。 B. CAがRAのサービスを利用している場合、RAが Section 3.2.2.2.12、Sub Section (1)、(2)および (3) に準拠していることを条件として、CAは最終的な相互照合および適切な精査を実行するためにRAの言語スキルに依存することができる (MAY)。前述にかかわらず、EV証明書を発行する前にCAはRAによって完了した作業を確認し、すべての要件が満たされていることを確認しなければならない (MUST)。 C. CAがRAのサービスを利用している場合、RAがこのSectionに準拠し、 Section 8.7 および Section 8.2 の監査要件に従うことを条件として、CAは最終的な相互照合と適切な精査の実行をRAに依頼することができる (MAY)。

Section 1.3.2 の要件に準拠して発行される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 に基づいて確認された本人。
2. Section 3.2.2.2.3.1に基づく申請者の事業所。
3. 申請者の検証済み通信方法は Section 3.2.2.2.4 で要求されているが、Section 3.2.2.2.4 (B) で要求されている検証を実行しなければならない (MUST)。
4. 申請者の事業上の存在 ( Section 3.2.2.2.5に基づく）
5. 契約署名者および証明書承認者の氏名、役職、機関および権限（Section 3.2.2.2.7 参照）
6. 申請者は、 Section 3.2.2.2.6に基づいて指定されたドメイン名を使用する権利を有する。ただし、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 に基づくEV証明書の再発行を除き、またSection 3.2.2.2.13.1 で別途許可されている場合を除き、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 および Section 3.2.2.2.9 で許可されている範囲で、同じ主体者識別名を含む複数のEV証明書をサポートするために単一のEV証明書要求を使用することを含め、以前に送信されたEV証明書要求、利用者契約、または利用規約を再利用できる (MAY)。

4. CAは、Section 3.2.2.2.13.1 で別途許可されている場合を除き、上記の制限期間外で取得した情報については、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 で特定された方法。.

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 など) で指定された期間内に検証が開始されていなければならない。ドメイン検証の目的では、申請者という用語には、申請者の親会社、子会社、または関連会社が含まれる。

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 または EV ガイドラインの Section 3.2.2.14.3 など）。

この方法を使用するCAは、Section 3.2.2.9 で指定されているように、マルチパースペクティブ発行検証を実装しなければならない(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 で指定されているように、マルチパースペクティブ発行検証を実装しなければならない (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 で指定されているように、マルチパースペクティブ発行検証を実装しなければならない (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 で定義されている 301、302、または 307 HTTP ステータス コード応答の結果、または RFC 7538, Section 3 で定義されている 308 HTTP ステータスコード応答の結果でなければならない (MUST)。リダイレクトは、 RFC 7231, Section 7.1.2 で定義されている Location HTTP 応答ヘッダーの最終値でなければならない (MUST)。 b. 2021年7月1日より前に実行された検証の場合、リダイレクトは、RFC 7231, 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 で指定されているように、マルチパースペクティブ発行検証を実装しなければならない(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 で定義されている 301、302、または 307 HTTP ステータスコード応答の結果、または RFC 7538, Section 3 で定義されている 308 HTTP ステータスコード応答の結果でなければならない (MUST)。リダイレクトは、RFC 7231, Section 7.1.2 で定義されている Location HTTP 応答ヘッダーの最終値でなければならない (MUST)。 b. 2021年7月1日より前に実行された検証の場合、リダイレクトは、RFC 7231, 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 で指定されているように、マルチパースペクティブ発行検証を実装しなければならない (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 の検証要件を満たす目的で情報を収集することである場合、信頼できるデータ ソースとして適格ではない。

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 を参照) または IP アドレス (Section 3.2.2.5を参照) に対する申請者の所有権または管理権を検証するために使用する方法の中には、証明書の発行 (Section 3.2.2.9 を参照) の前に追加のリモートネットワークパースペクティブから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 を参照) が作成され、少なくとも 2 つのパブリックログに記録され、事前証明書の発行時にCAAがチェックされた証明書の場合、オプションである。
• Section 7.1.2.3 またはSection 7.1.2.5 に規定されている技術的に制約のある下位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 では、マルチパースペクティブ発行検証の使用を必要とする検証方法と、ネットワークパースペクティブがプライマリネットワークパースペクティブによって決定された結果を確認する方法について説明する。

あるネットワークパースペクティブから取得された結果または情報は、後続のネットワークパースペクティブを通じて検証を実行するときに再利用またはキャッシュしてはならない (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)。

表: 定足数要件

マルチパースペクティブ発行検証を実行するリモート ネットワーク パースペクティブ

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 に掲載された情報源を使用して、信頼できる通信手段を検証できる (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 に記載されている情報源を使用して、信頼できる通信方法を検証できる (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 に規定されているのと同じ方法で、鍵更新のために識別および認証される (SHALL)。

3.3.2 Identification and authentication for re-key after revocation

3.3.2 証明書失効後の鍵更新時における本人性確認と認証

失効後の定期的な鍵更新はサポートされていない。証明書の（鍵更新）申請は新規申請として扱われ、申請者である利用者は、Section 3.2 に規定されているのと同じ方法で識別および認証される (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 に従い、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 を満たすために必要であると判断した追加の文書を取得する必要がある (SHOULD)。

証明書を発行する前に、CAは、CAが規定し、Section 1.1.1 Standards, Criteria and Regulations に準拠する形式で、申請者から証明書要求を取得する (SHALL)。各証明書が、申請者に代わって適切な申請者代表者によって署名された有効な最新の証明書要求によってサポートされていることを条件として、Section 4.2.1 の有効期限と更新の要件に従い、1 つの証明書要求で、同じ申請者に複数の証明書を発行できる (MAY)。証明書要求は、電子的に作成、提出/署名できる (MAY)。

証明書要求には、申請者または申請者の代理人からの証明書発行要求と、そこに含まれるすべての情報が正しいことの申請者または申請者の代理人による証明が含まれていなければならない (MUST)。

[S/MIME 証明書]

証明書を発行する前に、CAは申請者から以下の文書を取得する (SHALL)。

1. 証明書発行申請書
2. 契約締結された利用者契約/利用規約

証明書要求および利用者契約または利用規約は、CAが規定する形式であり、Section 9.6.3 を含むSection 1.1.1 Standards, Criteria and Regulations に準拠する (SHALL)。CAは、Section 1.1.1 Standards, Criteria and Regulations を満たすために必要であると判断した追加の文書を取得する必要がある (SHOULD)。

証明書要求には、申請者または申請者の代理人からの証明書発行要求およびそこに含まれるすべての情報が正しいことの申請者または申請者の代理人による証明が含まれている (SHALL)。

各証明書が、申請者に代わって適切な申請代表者によって署名された有効な最新の証明書要求によってサポートされていることを条件として、Section 4.2.1 に記載されている検証再利用期間に従い、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 に従って、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 は、利用者証明書の有効期間を制限する。CAは、Section 3.2 で指定されたソースからデータまたは文書を取得するか、証明書の発行前 825 日以内に検証を完了している場合、Section 3.2 で提供される文書およびデータを使用して証明書情報を検証することも、以前の検証自体を再使用することもできる (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 は利用者証明書の有効期間を制限する。

CAは、 Section 3.2 に従って実行された完了した検証/裏付けとなる証拠を、以下の制限内で再利用することができる (MAY)。

1. メールボックスの承認または制御の検証: Section 3.2.2.1.1 または Section 3.2.2.1.3 に従ったメール サーバの制御の検証の完了は、証明書の発行の 398 日前までに取得する (SHALL)。

   Section 3.2.2.1.1 で指定されたTLS Baseline Requirements 方法に変更があった場合、CAはこのSectionに記載されている期間、完了した検証/裏付けとなる証拠を再利用し続けることができる (MAY)。

   Section 3.2.2.1.2 に従ったメールボックスの制御の検証は、証明書の発行の 30 日前までに完了する (SHALL)。

以前の検証で使用されたデータまたは文書が、証明書の発行前にデータまたは文書の再利用に許可された最大期限を超えて取得された場合、以前の検証は再利用されない (SHALL NOT)。

[ドキュメントサイニング証明書とタイムスタンプ証明書]

CAは、Section 3.2 に従って実行された完了した検証/裏付けとなる証拠を以下の制限内で再利用することができる (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 または Section 3.2.2.5 に従って検証できないためである。

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がCAAissuemailレコードで発行を許可していると認識する発行者ドメイン名のセットを明確に指定する (SHALL)。2024年9月15日以降、メールボックスアドレスを含む証明書を発行する前に、CAは RFC 9495: Certification Authority Authorization (CAA) Processing for Email Addresses の Section 4 に従ってCAAレコードを取得して処理する必要がある (SHOULD)。

2025年3月15日以降、メールボックスアドレスを含む証明書を発行する前に、CAは RFC 9495: Certification Authority Authorization (CAA) Processing for Email Addresses のSection 4「に従ってCAAレコードを取得して処理する (SHALL)。

証明書で使用されるメールボックスアドレスのドメイン部分に対する申請者の制御を検証するために依存している一部の方法 (Section 3.2.2.1.1 および Section 3.2.2.1.3 を参照) では、証明書の発行前に追加のリモート ネットワークパースペクティブからCAAレコードを取得して処理する必要がある (Section 4.2.2.2 を参照)。プライマリネットワークパースペクティブを確認するには、両方のパースペクティブからの応答がバイト単位で同一であるかどうかに関係なく、リモートネットワークパースペクティブの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 に規定されているように、技術的に制約のある下位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 を実装するべきである (SHOULD)。 2025年5月15日より、CAは TLS Baseline Requirements の Section 3.2.2.9を実装する必要がある (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) (https://cabforum.org/resources/tools/ を参照)。

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 の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 の規定が適用される。

4.6.3 Processing certificate renewal requests

4.6.3 鍵更新をともなわない証明書更新申請の処理手続

Section 4.3.1 - 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 の規定が適用される。

4.6.5 Conduct constituting acceptance of a renewal certificate

4.6.5 鍵更新をともなわない更新証明書の受領確認手続

Section 4.4.1 - 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 の規定が適用される。

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 の規定が適用される。

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 の規定が適用される。

4.7.3 Processing certificate re-keying requests

4.7.3 鍵更新をともなう証明書申請の処理手続

Section 4.3.1 - 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 の規定が適用される。

4.7.5 Conduct constituting acceptance of a re-keyed certificate

4.7.5 鍵更新をともなう証明書受領確認手続

Section 4.4.1 - 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 の規定が適用される。

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 の規定が適用される。

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 および Section 4.1.1 の規定が適用される。

4.8.3 Processing certificate modification requests

4.8.3 証明書変更要求の処理

Section 4.3.1 - 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 の規定が適用される。

4.8.5 Conduct constituting acceptance of modified certificate

4.8.5 変更された証明書受領確認手続

Section 4.4.1 - 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 の規定が適用される。

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 の規定が適用される。

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 を参照) を使用する(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)（CRLReason #1、keyCompromise）で特定されているものが含まれるが、これに限定されない。
5. CAが、証明書内におけるドメイン認証の承認またはFQDNやIPアドレスの管理が信用できない証拠を得た (CRLReason #4, superseded)。

ショートリブド利用者証明書を除き、CAは、以下のいずれかが発生した場合、24 時間以内に利用者証明書を失効させる必要があり(SHOULD)、5日以内に証明書を失効し、対応するCRLReason Section 7.2.2 を使用しなければならない(MUST)。

6. 証明書が Section 6.1.5 および Section 6.1.6 の要件に準拠しなくなった (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 または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 の弱い鍵などhttps://wiki.debian.org/SSLkeys) を参照)。
5. CAが、証明書内のメールボックスアドレスのドメイン認証またはメールボックス制御の検証を信頼できないという証拠を取得する。

CAは、以下の1つ以上が発生した場合、24時間以内に証明書を失効する必要があり (SHOULD)、5日以内に証明書を失効する (SHALL)。

1. 証明書が Section 6.1.5 および Section 6.1.6 の要件に準拠しなくなる。
2. CAが、証明書が不正使用されたという証拠を取得する。
3. CAが、利用者が利用者契約または利用規約に基づく重要な義務の 1 つ以上に違反したことを認識する。
4. CAが、証明書内のEmailアドレスまたはFQDNの使用が法的に許可されなくなったことを示す状況を認識している (例: 裁判所または調停機関がEmailアドレスまたはドメイン名の使用権を失効した、利用者間の関連するライセンス契約またはサービス契約が終了した、またはアカウント所有者がEmailアドレスまたはドメイン名のアクティブステータスを維持できなかった)。
5. CAが、証明書に含まれる情報に重大な変更があったことを認識する。
6. CAが、証明書が Section 1.1.1 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 および Section 6.1.6 の要件に準拠しなくなる。
8. CAが証明書が不正使用されたという証拠を入手する。
9. CAが、利用者が利用者契約または利用規約に基づく重要な義務の 1 つ以上に違反したことを認識する。
10. CAが、証明書に含まれる情報に重大な変更があったことを認識する。
11. CAが、証明書が Section 1.1.1 Standards, Criteria and Regulations またはCAのCPやCPSに従って発行されなかったことを認識する。
12. CAが、証明書に記載されている情報のいずれかが不正確であると判断するか、またはそのことを認識する。
13. CAが、CRL/OCSPリポジトリーの維持を継続する手配を行わない限り、Section 1.1.1 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 および Section 6.1.6 の要件に準拠しなくなる。
7. CAが、証明書が不正使用されたという証拠を入手する。
8. CAが、利用者が利用者契約または利用規約に基づく重要な義務の 1 つ以上に違反したことを認識する。
9. CAが、証明書に含まれる情報に重大な変更があったことを認識する。
10. CAが、証明書が Section 1.1.1 Standards, Criteria and Regulations またはCAのCPやCPSに従って発行されなかったことを認識する。
11. CAが、証明書に記載されている情報のいずれかが不正確であると判断するか、またはそのことを認識する。
12. CAが CRL/OCSPリポジトリーの維持を継続する手続きを行わない限り、Section 1.1.1 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および Section 6.1.6の要件に準拠しなくなった証拠を得る。
4. 発行CAが、証明書の不正使用の証拠を得る。
5. 証明書が Section 1.1.1 Standards, Criteria and Regulations または適用されるCP/CPSに従って発行されなかったこと、または下位CAが Section 1.1.1 Standards, Criteria and Regulations または適用されるCP/CPSに準拠していないことを、発行CAが認識する。
6. 証明書に表示されている情報が不正確または誤解を招く恐れがあると発行CAが判断する。
7. 発行CAまたは下位CAが何らかの理由で運用を中止したが、証明書の失効サポートが別のCAによって提供されるように手配しない。
8. Section 1.1.1 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 で手順を公開する (SHALL)。

4.9.4 Revocation request grace period

4.9.4 失効申請の猶予期間

実際の失効スケジュールは、この section 4.9.1.1 および section 4.9.1.2 に記載されている失効の理由によって異なる。

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 で規定されている期間を超えてはならない (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 で定義される事前証明書サイニング証明書によって発行されている

証明書のシリアルは、「割り当てられていない」場合、「未割り当て」となる。

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 のOCSPレスポンダ証明書プロファイルに準拠しているOCSPレスポンダによって署名されている

利用者証明書のOCSP応答の有効期間は 8時間以上10日以下でなければならない (MUST)。

OCSPレスポンダーが「未割り当て」の証明書シリアルナンバーのステータスのリクエストを受信した場合、レスポンダーは「good」ステータスで応答すべきではない (SHOULD NOT)。OCSPレスポンダーが Section 7.1.2.3 または Section 7.1.2.5 に沿って技術的に制約されていない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 を参照。

4.9.13 Circumstances for suspension

4.9.13 証明書一時停止の要件

リポジトリーには、証明書が 一時停止されていることを示すエントリーを含めてはならない (MUST NOT)。

一時停止の使用に関する制限については、Section 7.2.2 を参照。

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 に記載されている役割を遂行する担当者を少なくとも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 に記載されている役割は、独立した担当者によって実行される。サービス運用管理者は、ログ検査担当者を兼務することができる。

[EV TLSサーバー証明書]

1. CAは、検証義務の分割に関する厳格な管理手順を実施して、1 人の人物が単独でEV証明書の発行を検証および承認できないようにしなければならない (MUST)。Section 3.2.2.2.12 で概説されているように、最終的な相互照合および適切な精査の手順は、いずれかの人物によって実行される場合がある (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 に記載された役割を担当する個人の信頼性と適性を任命時およびその後、定期的に審査する。

[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 に記載されている役割を担当する個人に更新トレーニングを提供する。

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 のトレーニングおよびスキルの要件および Section 5.4.1 の文書保持およびイベントログの要件を満たしていることを確認する (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 に準拠していることを証明するものとして、公認監査人にこれらの記録を提示できるようにする (SHALL)。

CAは、少なくとも以下のイベントを記録する (SHALL)。

1. 以下を含むCA証明書と鍵ライフサイクルイベント

   1. 鍵の生成、バックアップ、保管、回復、アーカイブ化、破棄
   2. 証明書の要求、更新、鍵の再生成の要求および失効
   3. 証明書要求の承認と拒否
   4. 暗号化デバイスライフサイクル管理イベント
   5. 証明書失効リストの生成
   6. OCSP応答の署名（Section 4.9 および Section 4.10で説明）
   7. 新しい証明書プロファイルの導入と既存の証明書プロファイルの廃止

2. 以下を含む利用者証明書ライフサイクル管理イベント

   1. 証明書の要求、更新、鍵の再生成要求および失効
   2. Baseline Requirements およびCAのCPSで定められたすべての検証業務
   3. 証明書要求の承認と拒否
   4. 証明書の発行
   5. 証明書失効リストの生成
   6. OCSP応答の署名（Section 4.9 および Section 4.10で説明）
   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 で説明)
   7. CA施設への出入記録

ログ記録には、少なくとも以下の要素を含めなければならない (MUST)。

1. イベントの日時
2. ジャーナルレコードを作成する人の身元 (該当する場合)
3. イベントの詳細

5.4.1.1 Router and firewall activities logs

5.4.1.1 ルーターとファイアウォールのアクティビティログ

Section 5.4.1 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 (1)に記載）は、以下のいずれかが発生した後に保管する。
   1. CA私有鍵の破壊
   2. cAフィールドが true に設定された X.509v3basicConstraints拡張を持ち、CA私有鍵に対応する共通の公開鍵を共有する一連の証明書のうち、最後のCA証明書の失効または有効期限切れ
2. 利用者証明書の有効期限が切れた後の利用者証明書ライフサイクル管理イベント記録（Section 5.4.1 (2)に規定）
3. イベント発生後のセキュリティイベント記録（Section 5.4.1 (3)に規定）
4. Code Signing Certificates の場合、TSA証明書私有鍵の失効または更新後のタイムスタンプ局データ記録Section 5.4.1.2およびイベント発生後のセキュリティイベント記録（Section 5.4.1.2に規定）

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に規定）。

さらに、CAおよび各外部委託先は以下をアーカイブするのとする (SHALL)。

1. 証明書システムのセキュリティに関連するドキュメント、証明書管理システム、Root CAシステムおよび外部委託先システム
2. 証明書要求および証明書の検証、発行および失効に関連するドキュメント

5.5.2 Retention period for archive

5.5.2 アーカイブ保存期間

アーカイブされた監査ログ（Section 5.5.1 に規定されているように)は、レコード作成のタイムスタンプから少なくとも2年間、または Section 5.4.3 に従って保持する必要がある限り、いずれか長い方の期間保持される (SHALL)。

さらに、CAおよび各外部委託先は、少なくとも2年間、以下を保持する (SHALL)。

1. 証明書システム、証明書管理システム、Root CAシステムおよび外部委託先システムのセキュリティに関連するすべてのアーカイブされたドキュメント (Section 5.5.1 に規定)
2. 証明書要求および証明書の検証、発行、失効（Section 5.5.1 に規定）に関連する、以下のいずれかの事象が発生した後のアーカイブされたすべての文書
   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に規定されている手順に従って失効を処理する。

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 / Section 6.1.6 に定められた要件を満たしていない。

2. 私有鍵を生成するために使用された特定の方法に欠陥があったという明確な証拠がある。

3. CAが、申請者の私有鍵が危殆化する実証済みまたは証明済みの方法を認識している。

4. CAが、 Section 4.9.3 および Section 4.9.12 に記載されているCAの失効要求手順を使用して、申請者の私有鍵が鍵危殆化を受けたことを以前に通知されている。

5. 公開鍵は、業界で実証された弱い私有鍵に適合している。2024年11月15日以降に提出されたリクエストについては、少なくとも以下の予防措置を実施する (SHALL)。

   1. Debian の弱い鍵の脆弱性 (https://wiki.debian.org/SSLkeys) の場合、CAはリポジトリーにリストされている各鍵のタイプ (RSA、ECDSAなど) とサイズについて、https://github.com/cabforum/Debian-weak-keys/ で見つかったすべての鍵を拒否する (SHALL)。Section 6.1.5 の要件を満たすその他のすべての鍵については、8192 ビットを超えるRSA鍵サイズを除き、CAは Debian の弱鍵を拒否する (SHALL)。
   2. ROCAの脆弱性の場合、CAは https://github.com/crocs-muni/roca または同等のツールによって識別された鍵を拒否する (SHALL)。
   3. Close Primes 脆弱性 (https://fermatattack.secvuln.info/) の場合、CAは、フェルマー因数分解法を使用して100ラウンド以内に因数分解できる弱鍵を拒否する (SHALL)。

   弱い鍵をチェックするための推奨ツール: https://cabforum.org/resources/tools/

利用者証明書に、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 で指定されている検証済みシステムまたはデバイスの外部でのCA私有鍵の保護は、私有鍵の漏洩を防ぐ方法で実装された物理的なセキュリティ、暗号化、またはその両方の組み合わせで構成されていなければならない (MUST)。CAは、暗号化された鍵または鍵部分の残存寿命の間、暗号解読攻撃に耐えることができる最新のアルゴリズムと鍵長を使用して、私有鍵を暗号化する (SHALL)。

6.2.1 Cryptographic module standards and controls

6.2.1 暗号モジュールの規格と管理

CA私有鍵の生成、保存、署名操作は、Section 6.2.7 を使用して実行される。 利用者の私有鍵については規定がない。

[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 を参照。

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 私有鍵を管理するレベルのサブスクリプションは、私有鍵を保護するリソースに対するすべてのアクセス、操作および構成の変更をログに記録するように構成しなければならない。
3. 利用者は、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 に規定されているとおりである。利用者の私有鍵について規定はない。

6.3 Other aspects of key pair management

6.3 鍵ペア管理に関するその他の事項

6.3.1 Public key archival

6.3.1 公開鍵のアーカイブ

CA公開鍵に関する条項は Section 6.2.1 に規定されている。利用者私有鍵について規定しない。

電子認証基盤上で運用されるCA公開鍵のアーカイブについては、Section 5.5.1 に規定される。

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 の要件を満たさなければならない (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 に記載された者によって行われる。

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 に規定される。

7. CERTIFICATE, CRL, AND OCSP PROFILES

7 証明書、CRLおよびOCSP プロファイル

7.1 Certificate profile

7.1 証明書プロファイル

CAは、Section 6.1.5 - Key SizesおよびSection 6.1.6 - 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 を参照。

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から派生し、組み込まれている。明示的に記載されている場合を除き、RFC 5280によって課されるすべての規範的要件が、この文書によって課される規範的要件に加えて適用される。

• CA 証明書
  • Section 7.1.2.1 - Root CA 証明書プロファイル
  • 下位 CA 証明書
    • クロス証明書
      • Section 7.1.2.2 - クロス下位CA証明書プロファイル
    • 技術的制約されたCA証明書
      • Section 7.1.2.3 - 技術的制約されたTLS以外の下位CA証明書プロファイル
      • Section 7.1.2.4 - 技術的制約された事前CA証明書プロファイル
      • Section 7.1.2.5 - 技術的制約されたTLS下位CA証明書プロファイル
    • Section 7.1.2.6 - TLS下位CA証明書
• Section 7.1.2.7 - 利用者 (EE) 証明書プロファイル
• Section 7.1.2.8 - OCSPレスポンダー証明書プロファイル
• Section 7.1.2.9 - 事前証明書プロファイル

7.1.2.1 Root CA Certificate Profile

7.1.2.1 Root CA 証明書プロファイル

7.1.2.1.1 Root CA Validity

7.1.2.1.1 Root CA の有効期間

注意: この制限は、既存の subject および subjectPublicKeyInfo に対して新しいルート CA 証明書を生成する場合 (再発行等) にも適用される。 新しい CA 証明書は、これらのルールに準拠する必要がある。

7.1.2.1.2 Root CA Extensions

7.1.2.1.2 Root CA 拡張

7.1.2.1.3 Root CA Authority Key Identifier

7.1.2.1.3 Root CA 認証局鍵識別子

7.1.2.1.4 Root CA Basic Constraints

7.1.2.1.4 Root CA の基本制約

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)。

7.1.2.2.1 Cross-Certified Subordinate CA Validity

7.1.2.2.1 クロス認証下位CAの有効期間

7.1.2.2.2 Cross-Certified Subordinate CA Naming

7.1.2.2.2 クロス認証下位CAの識別名

subjectは Section 7.1.4 の要件に準拠していなければならない (MUST)。または、既存のCA 証明書が当時の Baseline Requirements のバージョンに準拠して発行されている場合、エンコードされたsubject名は、既存のCA証明書のエンコードされたsubject名とバイト単位で同一でなければならない (MUST)。

注意: 上記の例外により、既存のCA証明書が発行時に有効な Baseline Requirements に準拠している場合、CAはクロス認証された下位CA証明書を発行できる。これにより、クロス認証を許可しながら、Section 7.1.4 の要件を時間の経過とともに改善できる。既存のCA証明書が準拠していない場合、クロス証明書の発行は許可されない。

7.1.2.2.3 Cross-Certified Subordinate CA Extensions

7.1.2.2.3 クロス認証下位CA拡張

上記に加えて、extKeyUsage 拡張の要件は、クロス証明書で表された発行者組織と主体者識別名組織の関係によって異なる。

extKeyUsage 拡張は、次の表に示すように、以下の場合に「無制約」になる場合がある (MAY)。

• 対応する証明書の発行者名と主体者識別名で表される organizationName は、次のいずれかである。

  • 同じ
  • 主体者識別名で表される organizationName は、発行者名で表される organizationName の関連会社である。

• クロス証明書の主体者識別名によって表される対応するCAは、発行CAと同じ組織または発行CAの関連会社によって運営されている。

表: 制約されてないEKUを持つクロス認証された下位CA

それ以外の場合、extKeyUsage 拡張機能は、次の表に示すように「制限」されなければならない (MUST)。

表: 制約されたEKUを持つクロス認証された下位CA

[^eku_ca]: RFC 5280, Section 4.2.1.12 では、この拡張機能は通常、エンドエンティティ証明書内にのみ表示されると記載されているが、Section 1.1.1 Standards, Criteria and Regulations では、多くのアプリケーションソフトウェアサプライヤーによって実装されているように、この拡張機能を使用してCA証明書の範囲を制限することで、検証者をさらに保護する。

[^name_constraints1]: この拡張機能の重要性を含む詳細な要件については、Section 7.1.2.10.8 を参照のこと。

7.1.2.2.4 Cross-Certified Subordinate CA Extended Key Usage - Unrestricted

7.1.2.2.4 クロス認証下位CA拡張鍵使用法 - 制約無し

表: 制約されてない拡張鍵の使用目的（関連クロス認証CA）

あるいは、発行CAがこの形式を使用しない場合、拡張鍵使用法の拡張機能が存在する場合は、Section 7.1.2.2.5で指定されているようにエンコードされなければならない (MUST)。

7.1.2.2.5 Cross-Certified Subordinate CA Extended Key Usage - Restricted

7.1.2.2.5 クロス認証下位CA拡張鍵使用法 - 制約あり

表: 制約されたTLSクロス認証下位CA拡張鍵の使用目的 (つまり、TLS証明書を直接または推移的に発行する制約ありクロス認証下位CAの場合)

表: 制約された非TLSクロス認証下位CA拡張鍵の使用目的 (つまり、TLS証明書を直接または推移的に発行しない制限されたクロス認証下位CAの場合)

それぞれに含まれる拡張鍵使用法の鍵使用目的:

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）

表: ポリシー制約あり

このプロファイルでは、証明書ポリシー拡張内の最初のPolicyInformation値に予約済み証明書ポリシー識別子 (7.1.6.1を参照) [^first_policy_note] を含めることを推奨する (RECOMMENDS)。PolicyInformation値の順序に関係なく、証明書ポリシー拡張には少なくとも 1 つの予約済み証明書ポリシー識別子を含めなければならない (MUST)。利用者証明書がこの証明書プロファイルに基づいて発行された証明書に直接連鎖する場合、このクロス認証された下位CA証明書には、正確に 1 つの予約済み証明書ポリシー識別子を含めなければならない (MUST)。

注意: policyQualifiers は、この証明書プロファイルに基づいて発行されるどの証明書にも存在することは推奨されない (NOT RECOMMENDED)。この情報は、通常の検証者に何の価値も提供せずに証明書のサイズを増加させ、必要に応じて他の手段で取得できるためである。

policyQualifiers が許可され、PolicyInformation フィールド内に存在する場合、次のようにフォーマットされなければならない (MUST)。

表: 許可された policyQualifiers

7.1.2.3 Technically Constrained Non-TLS Subordinate CA Certificate Profile

7.1.2.3 技術的に制約された非TLS下位CA証明書プロファイル

この証明書プロファイルは、技術的に制約があると見なされるCA証明書を発行する場合に使用できる (MAY)が、TLS証明書を直接または推移的に発行するためには使用されない。

7.1.2.3.1 Technically Constrained Non-TLS Subordinate CA Extensions

7.1.2.3.1 技術的に制約された非TLS下位CA拡張

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）

表: ポリシー制約あり

表: 許可された policyQualifiers

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)。

7.1.2.4 Technically Constrained Precertificate Signing CA Certificate Profile

7.1.2.4 技術的に制約された事前証明書サイニングCA証明書プロファイル

この証明書プロファイルは、RFC 6962, Section 3.1 で説明されているように、事前証明書サイニングCAとして使用されるCA証明書を発行するときに使用しなければならない (MUST)。CA証明書がこのプロファイルに準拠している場合、技術的に制約があると見なされる。

事前証明書サイニングCAは、Section 7.1.2.9 で定義されているように、事前証明書に署名するためにのみ使用しなければならない (MUST)。事前証明書サイニングCAが事前証明書を発行する場合、事前証明書サイニングCAの発行CAが、RFC 6962, Section 3.2 で指定された変更を適用した後、事前証明書に一致する tbsCertificate を含む証明書を発行したと解釈される。

RFC 6962 のSection 3.2 に記載されているように、事前証明書のsignatureフィールドは、これらの変更の一部として変更されない。そのため、事前証明書サイニングCAは、事前証明書を発行するときに発行CAと同じ署名アルゴリズムを使用しなければならない (MUST)。また、それに応じて、発行CAと同じ公開鍵アルゴリズムの公開鍵を使用しなければならない (MUST)が、異なるCA鍵ペアを使用することもできる (MAY)。

7.1.2.4.1 Technically Constrained Precertificate Signing CA Extensions

7.1.2.4.1 技術的に制約された事前証明書サイニングCA拡張

7.1.2.4.2 Technically Constrained Precertificate Signing CA Extended Key Usage

7.1.2.4.2 技術的に制約された事前証明書サイニングCA拡張鍵使用法

7.1.2.5 Technically Constrained TLS Subordinate CA Certificate Profile

7.1.2.5 技術的に制約されたTLS下位CA証明書プロファイル

この証明書プロファイルは、技術的に制約があると見なされ、TLS証明書を直接または推移的に発行するために使用されるCA証明書を発行するときに使用できる (MAY)。

7.1.2.5.1 Technically Constrained TLS Subordinate CA Extensions

7.1.2.5.1 技術的に制約されたTLS下位CA拡張

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またはexcludedSubtreesのいずれかのGeneralSubtreeのbase内に表示されるGeneralNameの要件が含まれている。

表: baseフィールドの GeneralName の要件

他の 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証明書プロファイル

7.1.2.6.1 TLS Subordinate CA Extensions

7.1.2.6.1 TLS下位CA拡張

7.1.2.7 Subscriber (Server) Certificate Profile

7.1.2.7 利用者（サーバー）証明書プロファイル

7.1.2.7.1 Subscriber Certificate Types

7.1.2.7.1 利用者証明書のタイプ

発行される可能性のある利用者証明書には4つのタイプがある。これは、含まれる主体者識別名情報の量に基づいて異なる。これらの各証明書タイプは、3つの例外を除いて共通のプロファイルを共有している。発生する可能性のあるsubject名フィールド、それらのフィールドの検証方法およびcertificatePolicies 拡張の内容。

注意: 各利用者証明書の種類によって主体者識別名情報は異なるが、すべての証明書はデバイス ID (ドメイン名や IP アドレス) について同じレベルの保証を提供する。

7.1.2.7.2 Domain Validated

7.1.2.7.2 ドメイン認証（DV）

利用者証明書がドメイン認証されるためには、次のプロファイルを満たしていなければならない (MUST)。

すべてのsubject名は Section 7.1.4 で指定されているとおりにエンコードされなければならない (MUST)。

次の表は、AttributeTypeAndValue の type フィールド内に表示される可能性のある許容される AttributeType と、value フィールド内で許可される内容の詳細を示している。

表: ドメイン認証済みのsubject属性

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名はSection 7.1.4 で指定されているとおりにエンコードされなければならない (MUST)。

次の表は、AttributeTypeAndValue の type フィールド内に表示される可能性のある許容される AttributeType と、value フィールド内で許可される内容の詳細を示している。

表: 組織認証済みの subject 属性

さらに、subject属性には、「.」、「-」、「」(つまりスペース) 文字などのメタデータのみ/値が存在しない、不完全である、または該当しないことを示すその他の情報のみを含めてはならない (MUST NOT)。

7.1.2.7.5 Extended Validation

7.1.2.7.5 拡張認証（EV）

利用者証明書が拡張認証であるためには、拡張認証証明書の発行および管理に関するEV Guidelinesのその時点の最新バージョンで指定されている証明書プロファイルに準拠していなければならない (MUST)。 さらに、次のプロファイルを満たさなければならない (MUST)。

さらに、subject属性には、「.」、「-」、「」(つまりスペース) 文字などのメタデータのみ/値が存在しない、不完全である、または該当しないことを示すその他の情報のみを含めてはならない (MUST NOT)。

7.1.2.7.6 Subscriber Certificate Extensions

7.1.2.7.6 利用者証明書の拡張

注意:

• subjectAltName 拡張を Critical としてマークするかどうかは、Section 7.1.2.7.12 で詳述されているように、証明書の subject フィールドの内容によって異なる。
• CRL配布ポイント拡張が存在しなければならないかどうかは、1) 証明書に id-ad-ocsp accessMethod を持つ authorityInformationAccess 拡張が含まれているかどうかおよび 2) Section 7.1.2.11.2 で詳述されている証明書の有効期間によって決まる。

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 には順序付けの要件はない。

7.1.2.7.8 Subscriber Certificate Basic Constraints

7.1.2.7.8 利用者証明書の基本制約

7.1.2.7.9 Subscriber Certificate Certificate Policies

7.1.2.7.9 利用者証明書の証明書ポリシー

存在する場合、証明書ポリシー拡張には少なくとも 1 つの PolicyInformation が含まれていなければならない (MUST)。各 PolicyInformation は次のプロファイルと一致しなければならない (MUST)。

このプロファイルでは、証明書ポリシー拡張内の最初の PolicyInformation 値に予約済み証明書ポリシー識別子 (7.1.6.1 を参照) [^first_policy_note] を含めることを推奨する (RECOMMEND)。PolicyInformation 値の順序に関係なく、証明書ポリシー拡張には予約済み証明書ポリシー識別子が 1 つだけ含まれていなければならない (MUST)。

表: 許可された policyQualifiers

[^first_policy_note]: RFC 5280 では、PolicyInformation が任意の順序で出現することを許可しているが、いくつかのクライアント実装では、特定のフィルターに一致する policyIdentifier を考慮するロジックが実装されている。そのため、予約済み証明書ポリシー識別子が最初の PolicyInformation であることを保証することで、相互運用性の問題のリスクが軽減される。

7.1.2.7.10 Subscriber Certificate Extended Key Usage

7.1.2.7.10 利用者証明書の拡張鍵使用法

7.1.2.7.11 Subscriber Certificate Key Usage

7.1.2.7.11 利用者証明書の鍵使用法

許容される鍵使用法の値は、証明書の subjectPublicKeyInfo がRSA公開鍵を識別するか、ECC公開鍵を識別するかによって異なる。CAは、鍵使用法が証明書の公開鍵に適切であることを確認しなければならない (MUST)。

表: RSA公開鍵の鍵使用法

注意: RSA公開鍵には、少なくとも 1 つの鍵使用法を設定しなければならない (MUST)。digitalSignature ビットは、TLS 1.3 などの最新のプロトコルや安全な暗号スイートで使用するために必須だが、keyEncipherment ビットは、安全でない暗号スイートを使用する場合に、TLS 1.2 などの古いプロトコルをサポートするために使用される場合がある (MAY)。利用者は、このようなレガシープロトコルによるリスクを制限するために鍵の分離を確実にすることを望む場合があり (MAY)、そのためCAは、keyEncipherment ビットのみを使用する利用者証明書を発行する場合がある (MAY)。ほとんどの利用者にとって、digitalSignature ビットで十分だが、同じアルゴリズムで安全でない暗号スイートと安全な暗号スイートを混在させたい加入者は、同じ証明書内で digitalSignature と keyEncipherment の両方を使用することを選択できるが、これは推奨されない (NOT RECOMMENDED)。 dataEncipherment ビットは現在許可されているが、保留中の禁止事項であるため、設定することは推奨されない (NOT RECOMMENDED) (https://github.com/cabforum/servercert/issues/384)。

表: ECC公開鍵の鍵使用法

注意: keyAgreement ビットは現在許可されているが、保留中の禁止事項であるため、設定することは推奨されない (NOT RECOMMENDED) (https://github.com/cabforum/servercert/issues/384)。

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 で指定されているように、クリティカルとしてマークしなければならない (MUST)。それ以外の場合、この拡張はクリティカルとしてマークしてはならない (MUST NOT)。

表: subjectAltName 拡張内の GeneralName

注意: RFC 5280 からの明示的な例外として、P ラベルは IDNA 2003 に準拠しないことが許可されている。Section 1.1.1 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 で定義されているOCSP認定レスポンダーを使用することができる (MAY)。レスポンダーの発行CAは、応答を提供する証明書の発行CAと同じでなければならない (MUST)。

7.1.2.8.1 OCSP Responder Validity

7.1.2.8.1 OCSPレスポンダーの有効期限

7.1.2.8.2 OCSP Responder Extensions

7.1.2.8.2 OCSP レスポンダーの拡張

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)。

7.1.2.8.4 OCSP Responder Basic Constraints

7.1.2.8.4 OCSPレスポンダー基本制約

OCSPレスポンダー証明書はCA証明書であってはならない (MUST NOT)。発行CAは、basicConstraints 拡張を省略するか、cA ブール値を FALSE に設定する basicConstraints 拡張を含めるかのいずれかの方法でこれを示す。

注意: 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レスポンダー拡張鍵使用法

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 で指定されているように、ASN.1 NULL 値のエンコードされた表現である 16 進エンコードされたバイト 0500 と同じ extnValue OCTET STRING が含まれていなければならない (MUST)。

7.1.2.8.7 OCSP Responder Key Usage

7.1.2.8.7 OCSPレスポンダー鍵の使用法

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 で定義されているように、証明書の透明性ログに送信できる署名されたデータ構造である。事前証明書は、extensionsフィールドの OID が 1.3.6.1.4.1.11129.2.4.3 である特別な重大なポイズン拡張を除き、構造的には証明書と同一である。この拡張により、事前証明書は RFC 5280 に準拠するクライアントによって証明書として受け入れられないことが保証される。署名された事前証明書の存在は、対応する証明書も存在する証拠として扱うことができる。署名は、CAによるそのような証明書を発行できるという拘束力のあるコミットメントを表すためである。

事前証明書は、CAが証明書の発行を決定した後、証明書に実際に署名する前に作成される。CAは、証明書の透明性ログに送信する目的で、証明書に対応する事前証明書を作成して署名することができる (MAY)。CAは、返された署名済み証明書のタイムスタンプを使用して、証明書に署名する前に、Section 7.1.2.11.3 で定義され、関連するプロファイルで許可されているように、署名済み証明書のタイムスタンプリストを追加して、証明書のextensionsフィールドを変更することができる (MAY)。

事前証明書が署名されると、検証者はこれを、対応する証明書を発行する意図、またはより一般的には、対応する証明書が存在するというCAからの拘束力のあるコミットメントとして扱うことが許可される。証明書は、RFC 6962, Section 3.2 で定義されたプロセスによって変換された tbsCertificate コンテンツの値に基づいて、事前証明書に対応していると見なされる。

このプロファイルは、証明書から事前証明書を作成するために許可される変換について説明している。CAは、対応する証明書を発行する意思がない限り、すでに発行したかどうかに関係なく、事前証明書を発行してはならない (MUST NOT)。同様に、CAは、対応する証明書が Baseline Requirements に準拠しない限り、CAが対応する証明書に署名したかどうかに関係なく、事前証明書を発行してはならない (MUST NOT)。

事前証明書は、発行CAによって直接発行されるか、または Section 7.1.2.4 で定義されている技術的に制約のある事前証明書サイニングCAによって発行される。事前証明書サイニングCAによって発行される場合、事前証明書ポイズンおよび署名済み証明書タイムスタンプリスト拡張に加えて、事前証明書issuerフィールドおよび (存在する場合は) authorityKeyIdentifier 拡張が、以下に説明するように証明書と異なる場合がある。

表: 事前証明書が発行CAによって直接発行される場合

表: 事前証明書が発行CAに代わって事前証明書サイニングCAによって発行される場合

注意: このプロファイルでは、事前証明書の serialNumber フィールドが対応する証明書の serialNumber フィールドと同一でなければならない (MUST)。RFC 5280, 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 で定義されているように、事前証明書サイニングCA証明書からではなく、CAから直接発行された事前証明書のコンテキストに適用される。

注意: この要件は、事前証明書から事前証明書ポイズン拡張が削除され、署名済み証明書タイムスタンプリストが証明書から削除された場合、extensions フィールドの内容は証明書とバイト単位で同一でなければならない (MUST) ことを示している。

7.1.2.9.2 Precertificate Profile Extensions - Precertificate CA Issued

7.1.2.9.2 事前証明書プロファイル拡張 - CA発行の事前証明書

これらの拡張は、Section 7.1.2.4 で定義されているように、事前証明書サイニングCA証明書からの事前証明書のコンテキストで適用される。このような事前証明書の場合、証明書にauthorityKeyIdentifier が存在する場合は、RFC 6962, Section 3.2 で説明されているように、事前証明書で変更される。

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 で指定されているように、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)。

注意: RFC 6962 では、事前証明書に存在する authorityKeyIdentifier が、事前証明書サイニングCAのauthorityKeyIdentifier 拡張の値 (つまり、実際の発行者証明書の keyIdentifier を反映) を含むように変換され、クライアントによって検証されたときに対応する証明書と一致する方法について説明している。Baseline Requirements では、チェーン内のすべての証明書の subjectKeyIdentifier とauthorityKeyIdentifier の一貫性を確保するために、事前証明書サイニングCAの keyIdentifier をそのCAが発行する事前証明書で使用することを推奨している (RECOMMEND)。RFC 5280 ではこのような一貫性は厳密には要求されていないが、多くのクライアント実装では証明書に対してこのような一貫性が強制されており、これにより証明書の透明性ログがこのようなチェックを誤って実装することによるリスクを回避している。

7.1.2.10 Common CA Fields

7.1.2.10 共通CAフィールド

このSectionには、複数のCA証明書プロファイルに共通するいくつかのフィールドが含まれている。ただし、これらのフィールドはすべてのCA証明書プロファイルに共通であるとは限らない。証明書を発行する前に、CAは、各フィールドの内容を含む証明書の内容が、Section 7.1.2 に記載されている少なくとも 1 つの証明書プロファイルのすべての要件に全体的に準拠していることを確認しなければならない (MUST)。

7.1.2.10.1 CA Certificate Validity

7.1.2.10.1 CA証明書の有効期限

7.1.2.10.2 CA Certificate Naming

7.1.2.10.2 CA証明書の識別名

すべての subject 名は Section 7.1.4 で指定されているとおりにエンコードされなければならない (MUST)。

次の表は、AttributeTypeAndValue の type フィールド内に表示される可能性のある許容される AttributeType と、value フィールド内で許可される内容の詳細を示している。

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 には順序付けの要件はない。

7.1.2.10.4 CA Certificate Basic Constraints

7.1.2.10.4 CA証明書の基本制約

7.1.2.10.5 CA Certificate Certificate Policies

7.1.2.10.5 CA証明書の証明書ポリシー

存在する場合、証明書ポリシー拡張機能には少なくとも 1 つの PolicyInformation が含まれていなければならない (MUST)。各 PolicyInformation は次のプロファイルと一致しなければならない (MUST)。

表: ポリシー制約なし（関連CA）

表: ポリシー制約あり

ポリシー制約プロファイルでは、証明書ポリシー拡張内の最初のPolicyInformation値に予約済み証明書ポリシー識別子 (7.1.6.1)[^first_policy_note] を含めることが推奨される (RECOMMEND)。PolicyInformation値の順序に関係なく、証明書ポリシー拡張には予約済み証明書ポリシー識別子が 1 つだけ含まれていなければならない (MUST)。

注意: policyQualifiers は、この証明書プロファイルに基づいて発行されるどの証明書にも存在することは推奨されない (NOT RECOMMENDED)。この情報は、通常の検証者に何の価値も提供せずに証明書のサイズを増加させ、必要に応じて他の手段で取得できるからである。

policyQualifiers が許可され、PolicyInformation フィールド内に存在する場合、次のようにフォーマットされなければならない (MUST)。

表: 許可された policyQualifiers

7.1.2.10.6 CA Certificate Extended Key Usage

7.1.2.16 CA証明書の拡張鍵使用法

7.1.2.10.7 CA Certificate Key Usage

7.1.2.10.7 CA証明書鍵の使用法

[^ocsp_signing]: CA証明書が digitalSignature ビットを使用しない場合は、CA私有鍵をOCSP応答の署名に使用してはならない (MUST NOT)。詳細については、Section 7.3 を参照のこと。

7.1.2.10.8 CA Certificate Name Constraints

7.1.2.10.8 CA証明書の名前制約

存在する場合、名前制約拡張は次のようにエンコードされなければならない (MUST)。RFC 5280 からの明示的な例外として、この拡張はクリティカルとしてマークする必要がある(MAY)が、名前制約をサポートしない特定のレガシーアプリケーションとの互換性が必要な場合は、非クリティカルとしてマークすることができる (MAY)。

表: nameConstraints の要件

次の表には、permittedSubtrees または excludedSubtrees のいずれかの GeneralSubtree の base 内に表示される GeneralName の要件が含まれている。

表: base フィールドの GeneralName 要件

何らかの 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 に記載されている少なくとも 1 つの証明書プロファイルのすべての要件に全体的に準拠していることを確認しなければならない (MUST)。

7.1.2.11.1 Authority Key Identifier

7.1.2.11.1 認証局鍵識別子

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 プロファイル

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 で指定されているように、エンコードされた 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 で定義されているとおりに設定されなければならない (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