title: SECOM Publicly Trusted Certificate Policy/Certification Practice Statement / SECOM パブリックトラスト証明書ポリシー/認証運用規程

subtitle: Version 1.02

author: SECOM Trust Systems CO., LTD. / セコムトラストシステムズ株式会社

date: 2025-10-22

copyright: © 2025 SECOM Trust Systems CO., LTD. This CP/CPS is licensed under the Creative Commons Attribution-NoDerivatives (CC-BY-ND) 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.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.1.1 DNSSEC validation of CAA records - CAAレコードのDNSSEC認証
      • 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.1.1 Incident Response and Disaster Recovery Plans - インシデント対応および災害復旧計画
    • 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.2 Cross-Certified Subordinate CA Certificate Profile - クロス認証下位CA証明書プロファイル
      • 7.1.2.3 Subordinate CA Certificate Profile - 下位CA証明書プロファイル
      • 7.1.2.4 Technically Constrained Precertificate Signing CA Certificate Profile - 技術的に制約された事前証明書サイニングCA証明書プロファイル
      • 7.1.2.5 Technically Constrained TLS Subordinate CA Certificate Profile - 技術的に制約されたTLS下位CA証明書プロファイル
      • 7.1.2.6 TLS Subordinate CA Certificate Profile - TLS下位CA証明書プロファイル
      • 7.1.2.7 Subscriber Certificate Profile - 利用者証明書プロファイル
      • 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.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.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.2. DNS TXT Methods - DNS TXT メソッド
    • A.2.1. DNS TXT Record Email Contact - DNS TXT Record Email連絡先
• APPENDIX B – Certificate profile - 付録 B – 証明書プロファイル
  • Table : "Security Communication RootCA2" and Subordinate CAs
  • Table : "Security Communication RootCA3" 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 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は、認証業務の一部をS/MIME Baseline Requirementsに準拠した外部の事業者に委託する場合があり（以下「外部委託先」という）、二社間の契約については契約書に定める。

本CP/CPSと「Table: Standards, Criteria and Regulations List」の規準に不整合がある場合、「Table: Standards, Criteria and Regulations List」の規準が本CP/CPSに優先する（SHALL）。

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）

Section 7.1.6.1 Reserved Certificate Policy Identifiers 参照。

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）

[S/MIME証明書]

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

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

1. 委託した職務に該当する場合、Section 5.3.1,の資格要件を満たす。
2. Section 5.5.2に従い、ドキュメントを保持する。
3. S/MIME Baseline Requirements以外にも、委託された職務に適用される条件を遵守する。
4. 以下のいずれかに準拠する。a). CAのCP/CPS b). CAがS/MIME Baseline Requirementsに準拠していることを認定した委託先の運用規程

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公開鍵証明書を使用して、そのような証明書の信頼性を認証できる。

1.4.2 Prohibited Certificate Uses

1.4.2 禁止される証明書の用途

規定しない。

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® ソフトウェアで開くたびに信頼されるデジタル署名を作成できるプログラム。

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)、25(smtp)、22(ssh)

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 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 TXT Record Email Contact (DNS TXT Record Email連絡先): Appendix A.2.1で定義されたEmailアドレス。

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 (エスクロー): エスクローとは、資産を独立した第三者の管理下に置く（委託する）ことを意味する。

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で説明された) などの署名対象データ オブジェクトの内容が、S/MIME 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の権限の下で運用され、証明書ステータス要求を処理するためにリポジトリーに接続されたオンラインサーバー。オンライン証明書ステータスプロトコルも参照のこと。

Online Certificate Status Protocol (オンライン証明書ステータスプロトコル): 検証者アプリケーションソフトウェアが識別された証明書のステータスを判断できるようにするオンライン証明書チェックプロトコル。OCSPレスポンダーも参照のこと。

Parent Company (親会社): 子会社を支配する会社。

Pending Prohibition​ (禁止保留中)​: このラベルで説明されている動作の使用は、推奨されないことが予定されており、将来的には MUST NOT と指定される可能性が高いため推奨できない。

Place of Business (事業所): 申請者の事業が行われている施設（工場、小売店、倉庫など）の所在地。

Primary Network Perspective (プライマリーネットワークパースペクティブ): CAが 1) 要求されたドメインまたは IP アドレスに対して証明書を発行するCAの権限および 2) 要求されたドメインまたは IP アドレスに対する申請者の権限/ドメイン承認または制御を決定するために使用するネットワークパースペクティブ。

Principal Individual（主要関係者）: 民間組織、政府機関、または事業体に所属する個人であり、雇用上の肩書によって所有者、パートナー、業務執行社員、取締役、または役員として識別される者、または、当該組織や団体によって、EV証明書の申請、発行、使用に関連する業務を行う権限を与えられた従業員、契約者、または代理人。

Private Organization (民間団体): 設立管轄区域内の設立機関またはその同等機関への申請（またはその行為）によって存在が確立された非政府法人（所有権が非公開か公開かに関わらず）。

Private Key (私有鍵): 鍵ペアの所有者によって秘密に保持され、デジタル署名を作成したり、対応する公開鍵で暗号化された電子記録やファイルを復号化するために使用される鍵ペアの鍵。

Public Key (公開鍵): 対応する私有鍵の所有者によって公開される可能性のある鍵ペアの鍵であり、検証者が所有者の対応する私有鍵で作成されたデジタル署名を検証したり、メッセージを暗号化して所有者の対応する私有鍵でのみ復号化できるようにするために使用される。

Public Key Infrastructure (公開鍵基盤): 公開鍵暗号化技術に基づいた信頼できる証明書および鍵の作成、発行、管理および使用を促進するために使用される一連のハードウェア、ソフトウェア、人、手順、ルール、ポリシーおよび義務。

Publicly-Trusted Certificate (パブリックトラスト証明書): 対応するルート証明書が、広く利用可能なアプリケーションソフトウェアで信頼アンカーとして配布されているという事実によって信頼される証明書。

Qualified Auditor (公認監査人): Section 8.2の要件を満たす自然人または法人。

Qualified Government Information Source (認定政府情報源): 政府組織によって管理されるデータベース (SEC 提出書類など)。

Qualified Independent Information Source (認定独立情報源: 定期的に更新され、最新の公開データベースであり、参照される情報を正確に提供することを目的として設計されており、そのような情報の信頼できる情報源として一般に認識されている。

Random Value (ランダム値): 少なくとも 112 ビットのエントロピーを示す、CAによって申請者に指定された値。

Registered Domain Name (登録ドメイン名): ドメイン名レジストラに登録されたドメイン名。

Registration Authority (RA) (登録局): 証明書の主体者識別名の識別および認証を担当する法人組織。ただし、CAではないため、証明書の署名や発行は行わない。RAは、証明書申請プロセスまたは失効プロセス、あるいはその両方を支援する場合がある。「RA」が役割や機能を指すために用いられる場合は、必ずしも別の組織体を示唆するものではなく、CAの一部である可能性がある。

Reliable Data Source (信頼データ情報源): 主体者識別名識別情報を検証するために用いられる識別文書またはデータ情報源で、民間企業や政府機関の間で信頼できるものとして一般的に認識されており、申請者による証明書取得以外の目的で第三者によって作成されたもの。

Reliable Method of Communication (信頼連絡手段): 申請権限者以外の情報源を使用して確認された、郵便/宅配便の配送先住所、電話番号、Emailアドレスなどの連絡方法。

Relying Party (検証者): 有効な証明書に依拠する自然人または法人。アプリケーションソフトウェアサプライヤーによって配布されるソフトウェアが単に証明書に関連する情報を表示するだけの場合、そのサプライヤーは検証者とは見なされない。

Repository (リポジトリー): 公開されている PKI ガバナンス ドキュメント (証明書ポリシーや認証運用規程など) と証明書ステータス情報 (CRL または OCSP 応答の形式) を含むオンライン データベース。

Request Token (申請トークン: CAによって指定された手法で得られた値で、管理の証明を証明書要求にバインドする。CAは、CPS（またはCPSによって明確に参照されているドキュメント）内で、受け入れるトークンの形式と方法を定義する必要がある(SHOULD)。 申請トークンには、証明書要求で使用された鍵を組み込むこととする(SHALL)。 申請トークンには、それがいつ作成されたかを示すタイムスタンプを含めることができる(MAY)。 申請トークンには、その一意性を確保するその他の情報を含めることができる(MAY)。 タイムスタンプを含む申請トークンは、その作成時から30日間だけ有効となる(SHALL)。 タイムスタンプを含む申請トークンは、そのタイムスタンプが未来の日時を指す場合、無効として扱われる(SHALL)。 タイムスタンプを含まない申請トークンは、1回のみ使用できる。CAは、使用済みのトークンを後続の検証に再使用しないこととする(SHALL NOT)。 バインドでは、証明書要求への署名に使用されるものと同程度の強度を持つデジタル署名アルゴリズムまたは暗号化ハッシュアルゴリズムを使用することとする(SHALL)。

Note (注): リクエストトークンの例には以下が含まれるが、これらに限定されない。

i. 公開鍵のハッシュ ii. Subject Public Key Info [X.509]のハッシュ iii. PKCS＃10 CSRのハッシュ

リクエストトークンは、タイムスタンプまたはその他のデータと連結することもできます。CAが常にPKCS＃10 CSRのハッシュをリクエストトークンとして使用することを望み、タイムスタンプを組み込みたくなく、証明書キーの再利用を許可したい場合、申請者はOpenSSLを使用したCSRの作成でチャレンジパスワードを使用して、後続のリクエスト間でサブジェクトとキーが同一であっても一意性を確保できる。

Note (注): この単純なシェルコマンドは、タイムスタンプとCSRのハッシュを持つ要求トークンを生成する。 echo `date -u +%Y%m%d%H%M` `sha256sum <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ビット。データの送信側と受信側でハッシュ値を比較することで、通信中に原文が改ざんされていないかを検出する仕組み。

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 3912に定義されたプロトコル経由のドメイン名登録業者やレジストリオペレーター、RFC 7482に定義されたレジストリデータアクセスプロトコル、または HTTPSウェブサイトから直接回収された情報。

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 慣例

キーワード「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は、最新バージョンの Section 1.1.1 Standards, Criteria and Regulations をCAがどのように実装するかを詳細に説明したCP/CPSを作成、実施、施行し、少なくとも 365 日に 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は、S/MIME Baseline Requirements を正式に適用し、最新の公開バージョンに準拠することを表明する (SHALL)。CAは、S/MIME Baseline Requirements をCP/CPSに直接組み込むか、次のような条項を使用して参照によって組み込むことで、この要件を満たすことができる (MAY) (S/MIME Baseline Requirements の公式バージョンへのリンクを含めなければならない (MUST))。

セコムトラストシステムズは、http://www.cabforum.org で公開されている「Baseline Requirements for the Issuance and Management of Publicly-Trusted S/MIME Certificates」の最新バージョンに準拠している。本CP/CPSと S/MIME Baseline Requirements の間に矛盾がある場合は、S/MIME Baseline Requirements が本CP/CPSよりも優先される。

2.3 Time or frequency of publication

2.3 公開時期または頻度

CAは、 Section 1.1.1 Standards, Criteria and Regulations の最新バージョンをCAがどのように実装しているかを詳細に記述したCP/CPSを作成、実施、施行し、毎年更新する (SHALL)。CP/CPSを少なくとも365日ごとに見直しおよび更新し、たとえ他に変更がない場合でも、バージョン番号を増分し、日付付きの変更履歴エントリを追加する（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標準および Section 1.1.1 Standards, Criteria and Regulations の要件を満たし、証明書所有者に割り当てられた識別名は X.500識別名形式に従って設定される。CAが発行する証明書には、次の情報が含まれる。

1. countryName は、日本を表す 2 文字の ISO 3166-1 国コード略語である「JP」（大文字）になる (SHALL)。
2. organizationName は組織の名前とする (SHALL)。stateOrProvinceName と localityName には組織の地域情報が含まれる。

3.1.2 Need for names to be meaningful

3.1.2 識別名の意味付け

証明書に指定される主体者識別名は、適切な範囲で組織または機関と関連している (SHALL)。利用者は、第三者の商標または関連する名前を含む証明書申請をCAに提出してはならない (SHALL NOT)。

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

[S/MIME 証明書 2023年8月31日以前の発行]

2023年8月31日以前の発行の場合、以下に説明する方法を使用して、証明書に登録された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アカウントの制御を確認する。

[S/MIME 証明書 2023-09-01以降の発行]

本セクションでは、発行される証明書に含まれるメールボックスアドレスに対する申請者の管理権限を確認するために許容される手続きおよびプロセスを定義する。

CAは、証明書に記載されるすべてのメールボックスフィールドに関連付けられた電子メールアカウントについて、申請者がそのアカウントを管理している、またはアカウント保有者から代理権限を与えられていることを検証しなければならない（SHALL）。

CAは、メールボックスの認可または管理権限の検証を委任してはならない（SHALL NOT）。

CAのCP/CPSには、CAがこの検証を実施するために採用している手続きが記載されていなければならない（SHALL）。CAは、発行された証明書に含まれるすべてのドメインまたは電子メールアドレスを検証する際に使用した検証方法と、その方法に対応するTLS Baseline RequirementsまたはS/MIME Baseline Requirementsのバージョン番号を記録として保持しなければならない（SHALL）。

申請者の権限に関する検証が完了していれば、複数の証明書の発行にわたって有効である場合がある（MAY）。いずれの場合も、検証は証明書発行の前に、関連する要件（例：Section 4.2.1）で指定された期間内に開始されていなければならない（SHALL）。

注記： メールボックスフィールドは、subjectAltName拡張内のrfc822Nameまたはtype id-on-SmtpUTF8MailboxのotherNamesを使用して、利用者証明書に記載される場合がある（MAY）。メールボックスフィールドは、nameConstraints拡張内のpermittedSubtreesにおけるrfc822Nameを通じて、下位CA証明書に記載される場合がある（MAY）。

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 of the TLS Baseline Requirements で承認された方法のみを使用する (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 of the TLS Baseline Requirements で現在承認されている方法のみを使用する (SHALL)。

3.2.2.2 DBA/Tradename

3.2.2.2 商号/商標名

主体者識別名のアイデンティティ情報に商号または商標名が含まれる場合、CAは、以下の少なくとも1つを使用して、商号/商標名を使用するための申請者の権利を検証する (SHALL)。

1. 申請者の法的な設立、存在、または承認の管轄地域にある政府機関が提供するドキュメントまたは、このような政府機関とのやり取りで得られた情報。
2. 信頼データ情報源。
3. 当該商号または商標名の管理を担当している政府機関とのやり取りで得られた情報。
4. 文書による裏付けのある意見書。
5. 公共料金請求書、銀行取引明細書、クレジットカード明細書、政府発行の税務書類、その他、CAが信頼できると見なした本人確認書類。

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.3 Authentication of individual identity

3.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およびセコムトラストシステムズがSection 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運用基準に基づいて本人確認および認証を行う。

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

[コードサイニング証明書]

コードサイニング証明書は2024年5月1日以降、発行しない（SHALL NOT）。

4.2.2 Approval or rejection of certificate applications

4.2.2 証明書申請の承認または却下

CAは、承認した申請に対応する証明書を発行し、当該利用者にその完了と証明書の発行を通知する。なお、すべての項目の審査が適切に完了していない証明書の申請は拒否することができ、以下の理由を含むものは拒否される。

• 以前に拒否された、または以前に契約条件に違反した申請者または利用者の証明書

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の基盤外である場合
• レコード検索が少なくとも一度は再試行されている
• CAが、RFC 4035 Section 4.3で定義される「Insecure」であることを確認している（MUST）

S/MIME証明書を発行する許可を希望する利用者は、DNSの issuemail プロパティタグに値 "secomtrust.net" を含めなければならない。S/MIME利用者がDNSゾーンにすでにCAAエントリを持っており、CAからの証明書発行を必要とする場合は、issuemail プロパティ タグに値 "secomtrust.net" を含めなければならない (MUST)。

4.2.2.1.1 DNSSEC validation of CAA records

4.2.2.1.1 CAAレコードのDNSSEC認証

2026年3月15日以降：プライマリネットワークパースペクティブによって実施されるCAAレコードのルックアップに関連するすべてのDNSクエリに対して、IANA DNSSEC RootトラストアンカーまでのDNSSEC検証を実施しなければならない（MUST）。プライマリネットワークパースペクティブによってCAAレコードのルックアップに関連して使用されるすべてのDNSクエリに使用されるDNSリゾルバーは、以下を満たす（MUST）。

• RFC 4035 Section 5で定義されるアルゴリズムを使用してDNSSEC検証を実施（MUST）
• RFC 5155で定義されるNSEC3をサポート（MUST）
• RFC 4509およびRFC 5702で定義されるSHA-2をサポート（MUST）
• RFC 6840 Section 4に列挙されているセキュリティ上の懸念事項を適切に処理（MUST）

2026年3月15日以降：CAは、CAAレコードのルックアップに関連するDNSクエリに対して、DNSSEC検証を無効化するためにローカルポリシーを使用してはならない（MUST NOT）。

2026年3月15日以降：プライマリネットワークパースペクティブによって観測されたDNSSEC検証エラー（例：SERVFAIL）は、発行の許可として扱ってはならない（MUST NOT）。

マルチパースペクティブ発行検証の一環として、リモートネットワークパースペクティブによって実施されるCAAレコードのルックアップに関連するすべてのDNSクエリに対して、IANA DNSSEC RootトラストアンカーまでのDNSSEC検証を実施してもよい（MAY）。

IANA DNSSEC RootトラストアンカーまでのDNSSEC検証は、Section 8.7の要件を満たすために実施される自己監査の対象外と見なされる。

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 署名される証明書のリンティング

[S/MIME 証明書]

CAが署名する前に、署名対象の各アーティファクトの技術的適合性をテストするためのリンティングプロセスを実装することがベストプラクティスであると考えられている。

• 2025年3月15日より、CAは S/MIME Baseline Requirements への準拠をテストするリンティングプロセスを実装するべきである (SHOULD)。

• 2025年9月15日より、CAは S/MIME Baseline Requirements への準拠をテストするリンティングプロセスを実装する (SHALL)。

署名対象の証明書コンテンツを含む証明書を作成するために使用される方法には、次のものが含まれるが、これらに限定されない。

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を通じて、証明書利用者に発行を通知する。

4.4 Certificate acceptance

4.4 証明書受領確認

4.4.1 Conduct constituting certificate acceptance

4.4.1 証明書受領確認手続

[S/MIME証明書]

利用者が証明書をダウンロードしたとき、または利用者が送信した証明書がその他の方法によりサーバーに導入されたときに、その承諾が完了したものとみなされる。

[クライアント認証証明書、ドキュメントサイニング証明書、タイムスタンプ証明書]

CAがLRAまたは利用者から受領報告を受け取った場合、またはCAによる証明書の配布後14日以内に異議が申し立てられなかった場合は、LRAまたは利用者が証明書を受領したものとみなされる。

4.4.2 Publication of the certificate by the CA

4.4.2 CAによる証明書公開

CA証明書はリポジトリーに公開される。

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 利用者証明書の失効理由

[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 (公開) 経由で利用できなければならない。

[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レスポンスが提供される場合、それは RFC 6960 / RFC 5019 に準拠していなければならない（SHALL）。OCSPレスポンスは以下のいずれかによって署名されていなければならない（SHALL）：

1. 失効状態を確認する対象の証明書を発行したCA。
2. 失効状態を確認する対象の証明書を発行したCAによって署名された証明書を持つOCSPレスポンダ。

後者の場合、OCSP署名用証明書には、ocspSigning EKU（1.3.6.1.5.5.7.3.9）および RFC 6960 に定義される id-pkix-ocsp-nocheck 型の拡張が含まれていなければならない（SHALL）。

4.9.10 On-line revocation checking requirements

4.9.10 オンライン失効確認の要件

CAが運用するOCSPレスポンダは、RFC 6960 / RFC 5019 に記載されているHTTP GETメソッドをサポートしていなければならない（SHALL）。

OCSPレスポンスの有効期間は、thisUpdate フィールドと nextUpdate フィールドの時間差（両端を含む）である。差分の計算においては、3,600秒の差は1時間、86,400秒の差は1日とみなし、うるう秒は無視するものとする。

利用者証明書のステータスに関して以下すべてを満たさなければならない。

1. OCSPレスポンスの有効期間は8時間以上でなければならない（SHALL）。
2. OCSPレスポンスの有効期間は10日以下でなければならない（SHALL）。
3. 有効期間が16時間未満のOCSPレスポンスについては、CAはnextUpdateの半分の期間より前に、オンライン証明書ステータスプロトコルを通じて提供される情報を更新しなければならない（SHALL）。
4. 有効期間が16時間以上のOCSPレスポンスについては、CAはnextUpdateの少なくとも8時間前までに、かつthisUpdateから4日以内に、オンライン証明書ステータスプロトコルを通じて提供される情報を更新しなければならない（SHALL）。

下位CA証明書のステータスに関して、CAはOCSPを通じて提供される情報を以下のとおり更新しなければならない（SHALL）。

1. 少なくとも12か月ごと。
2. 下位CA証明書を失効させた後24時間以内。

OCSPレスポンダが「未使用」の証明書シリアル番号に対するステータス要求を受け取った場合、レスポンダは「good」ステータスで応答すべきではない（SHOULD NOT）。OCSPレスポンダが Section 7.1.5 に従って技術的制約を受けていないCAに対応している場合、そのような要求に対して「good」ステータスで応答してはならない（SHALL NOT）。

OCSPリクエスト内の証明書シリアル番号は、発行CAが現在または過去の鍵を使用してそのシリアル番号の証明書を発行している場合は「割り当て済み」とされ、それ以外の場合は「未使用」とされる。

4.9.11 Other forms of revocation advertisements available

4.9.11 その他の形式での証明書有効性確認方法

規定しない。

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 は、認証基盤システムの重要度に応じて、物理的アクセス制御と電子的アクセス制御を組み合わせた適切なセキュリティ制御を実施する。また、認証基盤システムへのアクセスは、設置された監視カメラやその他のセンサーによって監視される。

24時間体制の監視、入退室管理（多要素認証・複数人制御）など、物理的な不正侵入防止策を実施し、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 手順の管理

CAは、信頼された役割、ネットワーク境界制御、CAインフラストラクチャに関する文書化された変更管理プロセスを維持する（SHALL）。

このプロセスには以下を含める（SHALL）。

• 年次レビューおよび必要に応じた更新
• 信頼された役割、ネットワーク境界制御、CAインフラストラクチャの変更に対するリスクアセスメント
• 例外および緊急変更の管理手順
• 適用可能な場合の変更の巻き戻し手順

信頼された役割の定義、任命、ネットワーク境界制御、CAインフラストラクチャに対するすべての変更は、この変更管理プロセスに従って実施しなければならない（MUST）。

5.2.1 Trusted roles

5.2.1 信頼された役割

CAは、認証基盤システムの運用に必要な役割を次のように定義する。

1. サービス責任者
   • 電子認証基盤を管理する。
   • 認証基盤システムおよび運用手順の変更/改訂を承認する。
2. サービス運用管理者
   • 運用担当者に作業指示を与える。
   • 現場でCA私有鍵の操作を監視する。
   • サービス業務全体を管理する。
3. CA管理者
   • CAサーバー、リポジトリーサーバーおよびその他の認証基盤システムを維持および管理する。
   • CA私有鍵の有効化と無効化を実行する。
4. RA担当者
   • 認証基盤システムを使用してRAサービスを実行する顧客の情報の登録と削除を管理する。
   • 認証基盤システムを通じて、CAが運営するRAサービスを実施する。

各信頼された役割は、その責任、権限、アクセス権を文書化しなければならず（SHALL）、最小権限の原則および職務分離の原則に従って割り当てる（SHALL）。

グループアカウントや共有認証情報は、CAインフラストラクチャまたはネットワーク境界制御へのアクセスに使用すべきではない（SHOULD NOT）。
グループアカウントや共有認証情報を使用する場合は、その利用ごとに承認された活動および個々のユーザーまたはサービスアカウントに帰属できなければならない（MUST）。

認証情報は、関連する認可が変更または失効した場合には、変更または失効しなければならない（MUST）。
CAインフラストラクチャおよびネットワーク境界制御へのアクセスは、従業員または契約関係の終了から24時間以内に無効化しなければならない（MUST）。

CAインフラストラクチャまたはネットワーク境界制御に認証またはアクセス可能なすべてのアカウントは、少なくとも3か月ごとにレビューし、不要なアカウントは無効化または削除しなければならない（SHALL）。

繰り返しの認証試行（例：ブルートフォース攻撃）による不正アクセスのリスクを最小化するため、文書化されたリスクアセスメントに基づき、セキュリティ対策を実装しなければならない（SHALL）。

ワークステーションは、一定期間操作がない場合に継続的なアクセスを防止するよう（例：自動ログオフ）、リスクアセスメントに基づき設定しなければならない（SHALL）。

Root CAシステムへの物理アクセスには、マルチパーティコントロールを要求しなければならない（SHALL）。

認証情報として使用するパスワードは、NIST 800-63B Revision 3 Appendix Aに従って生成・管理することが推奨される（SHOULD）。

CAインフラストラクチャへの特権アクセスを可能にするリモート接続は、以下を満たさなければならない（MUST）：

• CAが所有または管理するワークステーションから発信されること
• 一時的かつ非永続的で暗号化されたチャネルを通じて行われること
• 多要素認証を用いて認証されること
• CAのネットワーク内に配置され、これらの要件に従って保護され、リモート接続を仲介するネットワーク境界制御資産に対して行われること

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

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 に記載された役割を担当する個人の信頼性と適性を任命時およびその後、定期的に審査する。

5.3.3 Training Requirements and Procedures

5.3.3 教育要件と手順

CAは、情報検証業務を実行するすべての要員に、基本的な公開鍵基盤の知識、認証および検証ポリシーおよび手順（CAのCP/CPSを含む）、情報検証プロセスに対する一般的な脅威（フィッシングおよびその他のソーシャル・エンジニアリング手法を含む）および S/MIME Baseline Requirements を網羅したスキル研修を提供する（SHALL）。

CAは、このようなトレーニングの記録を保持し、検証スペシャリストの職務を委託された要員が、そのような職務を満足に遂行できるスキルレベルを維持していることを保証する (SHALL)。

CAは、検証スペシャリストにタスクの実行を許可する前に、各検証スペシャリストがそのタスクに必要なスキルを有していることを文書化する (SHALL)。

CAは、すべての検証スペシャリストに対して、S/MIME 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 監査ログ手順

CAは、CAインフラストラクチャおよびネットワーク境界制御の監視およびログ取得の能力を特定し、文書化しなければならない（SHALL）。
監視およびログ取得に関する方針および手順は、少なくとも年1回レビューし、必要に応じて更新する（SHALL）。

ログ処理の完全性は、継続的な自動監視、または信頼された役割に割り当てられた者による少なくとも31日に1回のレビューによって監視しなければならない（SHALL）。

監査ログは、これらの要件および適用される義務を満たすために必要な期間保持またはアーカイブし、不正な改ざんやアクセスを防止するよう管理しなければならない（SHALL）。

監査ログは、信頼された役割の管理下で自動化された仕組みにより処理し、重大なセキュリティイベントや不正な変更の可能性を識別しなければならない（SHALL）。

信頼された役割に割り当てられた担当者は、監査ログの改ざんの可能性、重大なセキュリティイベント、不正な変更が識別された場合、複数の手段や通信チャネルを通じてアラートを受けなければならない（SHALL）。

信頼された役割に割り当てられた担当者は、そのようなアラートが発生してから24時間以内に初動対応を開始しなければならない（SHALL）。

インシデント対応計画には、インシデントの潜在的な影響、範囲、重大性の特定、さらなる影響を最小化するための封じ込め、根本原因の特定および除去または緩和を含めることが望ましい（SHOULD）。

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. S/MIME 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 インシデントおよび危殆化対応手順

5.7.1.1 Incident Response and Disaster Recovery Plans

5.7.1.1 インシデント対応および災害復旧計画

インシデント発生時は、アラート発生から24時間以内に初動対応を開始し、対応記録を残す。重大インシデントの場合は、関係者・関係当局へのすみやかな報告を行う。

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. 災害発生から元のサイトまたはリモートサイトで安全な環境を復元するまでの期間に可能な範囲で設備を保護するための手順

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通信によって暗号化される。

6.1.4 CA public key delivery to relying parties

6.1.4 検証者へのCA公開鍵配布

検証者は、CAリポジトリーにアクセスしてCA公開鍵を取得できる。

6.1.5 Key sizes

6.1.5 鍵サイズ

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年以下とする。

[コードサイニング証明書とコードサイニング証明書のタイムスタンプ証明書]

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 システム開発の管理

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は、証明書管理システム、CAサーバ、HSM、ネットワーク機器、サポートシステムを含むCAインフラストラクチャのインベントリを定義し、文書化し、維持する。インベントリは年次でレビューし、CA/Browser ForumのNetwork and Certificate System Security Requirementsに従い、変更があった場合は更新する。

CAインフラストラクチャは、機能的および論理的な関係に基づき、分離されたネットワークに分割する。ネットワーク分割は、以下を目的として設計・実装する（SHALL）。

• 攻撃面の最小化
• ネットワーク内でのラテラルムーブメントの制限
• 異なるネットワークセグメント間のトラフィックフローの制限
• すべてのCAインフラストラクチャ構成要素の不正アクセスからの保護

ネットワーク分割は、ファイアウォール、ネットワークスイッチ、物理的に分離されたネットワーク、ソフトウェア定義ネットワークなどのネットワーク境界制御を用いて実装する（SHALL）。VLAN、VLANアクセス制御リスト、VPNなどのソフトウェアベースの分割手法も、必要に応じて活用してよい（MAY）。

CAインフラストラクチャのいずれかの構成要素と同じネットワーク上にあるすべてのシステムは、CAインフラストラクチャに要求されるのと同等のセキュリティ制御を実装しなければならない（MUST）。

Root CAシステムは、他のすべてのCAインフラストラクチャから物理的に分離しなければならない（SHALL）。

CAインフラストラクチャへの接続は、認証および暗号化を行うものとし、ただし正式な仕様で認証や暗号化の使用が禁止または制限されている場合はこの限りでない（SHALL）。

CAは、侵入検知・防御システム（IDS/IPS）を実装し、未使用のネットワークポートやサービスを無効化し、管理者アクセスに多要素認証を強制する（SHALL）。

本セクションの方針および手順は、すべての証明書システム、セキュリティサポートシステム、ネットワーク境界制御に適用する。

CAは、以下を含む脆弱性修正プロセスを文書化し、これに従わなければならない（MUST）。

• 識別
• レビュー
• 対応
• 修正

脆弱性管理要件

• ペネトレーションテストは、少なくとも年1回、およびインフラやアプリケーションの重大な変更後に、有資格かつ独立した担当者が適切なツールと手法を用いて実施する（SHALL）。
• 脆弱性識別プロセスには、関連するセキュリティアドバイザリの継続的な監視を含める（SHALL）。
• 重大または高リスクと評価された脆弱性については、発見から72時間以内に対応計画を策定する（SHALL）。
• 高リスクまたは中リスクの脆弱性については、CAがリスクアセスメントに基づき定めた期間内（通常60日を超えない）に修正を完了する（SHALL）。
• 脆弱性は、もはや存在しないように修正された場合、または影響がCAのセキュリティ体制に影響しないと確認・文書化された場合に、修正済みとみなす（SHALL）。
• すべての対応と結果は文書化し、監査対象とする（SHALL）。

侵入や侵害が発生している場合は、インシデントが緩和されるまで証明書発行を停止する（SHALL）。

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 に定められた技術要件を満たさなければならない。

7.1.1 Version number(s)

7.1.1 バージョン番号

証明書は X.509 v3 形式とする。

7.1.2 Certificate Content and Extensions

7.1.2 証明書拡張

このセクションでは、証明書の内容および証明書の拡張に関する追加要件を規定する。

7.1.2.1 Root CA Certificate Profile

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

APPENDIX B – Certificate profile参照。

7.1.2.2 Cross-Certified Subordinate CA Certificate Profile

7.1.2.2 クロス認証下位CA証明書プロファイル

APPENDIX B – Certificate profile参照。

7.1.2.3 Subordinate CA Certificate Profile

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

APPENDIX B – Certificate profile参照。

7.1.2.4 Technically Constrained Precertificate Signing CA Certificate Profile

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

規定しない。

7.1.2.5 Technically Constrained TLS Subordinate CA Certificate Profile

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

規定しない。

7.1.2.6 TLS Subordinate CA Certificate Profile

7.1.2.6 TLS下位CA証明書プロファイル

規定しない。

7.1.2.7 Subscriber Certificate Profile

7.1.2.7 利用者証明書プロファイル

APPENDIX B – Certificate profile参照。

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

規定しない。

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証明書の証明書ポリシー

[S/MIME 証明書およびコードサイニング証明書]

存在する場合、証明書ポリシー拡張機能には少なくとも 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.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証明書
• id-ad-ocsp accessMethod を持つ authorityInformationAccess 拡張を含まない利用者証明書。
• コードサイニング証明書。

CRL配布ポイント拡張は、次の場所には存在すべきではない (SHOULD NOT)。

• Root CA証明書

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

CAは、id-ecPublicKey (OID: 1.2.840.10045.2.1) アルゴリズム識別子を使用してECDSA鍵を示す (SHALL)。パラメータは namedCurve エンコーディングを使用しなければならない (MUST)。

• P-256鍵の場合、namedCurve は secp256r1 (OID: 1.2.840.10045.3.1.7) でなければならない (MUST)。
• P-384鍵の場合、namedCurve は secp384r1 (OID: 1.3.132.0.34) でなければならない (MUST)。
• P-521鍵の場合、namedCurve は secp521r1 (OID: 1.3.132.0.35) でなければならない (MUST)。

エンコードされると、ECDSA鍵の AlgorithmIdentifier は、次の16進エンコードされたバイトとバイト単位で同一でなければならない (MUST)。

• P-256鍵の場合、 301306072a8648ce3d020106082a8648ce3d030107.
• P-384鍵の場合、 301006072a8648ce3d020106052b81040022.
• P-521鍵の場合、 301006072a8648ce3d020106052b81040023.

7.1.3.2 Signature AlgorithmIdentifier

7.1.3.2 署名アルゴリズム識別子

CA私有鍵によって署名されたすべてのオブジェクトは、署名のコンテキストにおける AlgorithmIdentifier または AlgorithmIdentifier 派生型の使用に関する Section 1.1.1 Standards, Criteria and Regulationsに 準拠しなければならない (MUST)。

特に、以下のすべてのオブジェクトとフィールドに適用される。

• 証明書または事前証明書の signatureAlgorithm フィールド。
• TBSCertificate の signature フィールド (たとえば、証明書または事前証明書のいずれかで使用されるもの)
• CertificateList の signatureAlgorithm フィールド
• TBSCertListの signature フィールド
• BasicOCSPResponse の signatureAlgorithm フィールド

これらのフィールドには他のエンコードは許可されていない。

7.1.3.2.1 RSA

7.1.3.2.1 RSA

CAは、以下の署名アルゴリズムとエンコーディングのいずれかを使用する (SHALL)。エンコードされると、AlgorithmIdentifier は指定された16進エンコードされたバイトとバイト単位で同一でなければならない (MUST)。

• SHA-256 を使用した RSASSA-PKCS1-v1_5:

  エンコーディング: 300d06092a864886f70d01010b0500.

• SHA-384 を使用した RSASSA-PKCS1-v1_5:

  エンコーディング: 300d06092a864886f70d01010c0500.

• SHA-512 を使用した RSASSA-PKCS1-v1_5:

  エンコーディング: 300d06092a864886f70d01010d0500.

• SHA-256 を使用した RSASSA-PSS、SHA-256 を使用した MGF-1、そしてソルト長 32 バイト:

  エンコーディング:

  304106092a864886f70d01010a3034a00f300d0609608648016503040201
  0500a11c301a06092a864886f70d010108300d0609608648016503040201
  0500a203020120
  

• SHA-384 を使用した RSASSA-PSS、SHA-384 を使用した MGF-1、そしてソルト長 48 バイト:

  エンコーディング:

  304106092a864886f70d01010a3034a00f300d0609608648016503040202
  0500a11c301a06092a864886f70d010108300d0609608648016503040202
  0500a203020130
  

• SHA-512 を使用した RSASSA-PSS、SHA-512 を使用した MGF-1、そしてソルト長 64 バイト:

  エンコーディング:

  304106092a864886f70d01010a3034a00f300d0609608648016503040203
  0500a11c301a06092a864886f70d010108300d0609608648016503040203
  0500a203020140
  

さらに、CAは、以下の条件がすべて満たされている場合、次の署名アルゴリズムとエンコーディングを使用する場合がある (MAY)。

• 証明書の signatureAlgorithm フィールドや TBSCertificate の signature フィールドなど、証明書内で使用される場合:

  • 新しい証明書は、クロス証明書であるルートCA証明書または下位CA証明書である。
  • 同じ発行CA証明書によって発行された既存の証明書があり、署名アルゴリズムに次のエンコードを使用している。
  • 既存の証明書には少なくとも64ビットの長さの serialNumber がある。
  • 新しい証明書と既存の証明書の唯一の違いは、次のいずれかである。
    • 同じアルゴリズムと鍵サイズを使用する、subjectPublicKeyInfo 内の新しい subjectPublicKey
    • 既存の証明書と同じエンコードされた長さの新しいserialNumber
    • 新しい証明書の extKeyUsage 拡張が存在し、少なくとも 1 つのキー目的が指定されており、指定されたキー目的のいずれも id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1) または anyExtendedKeyUsage (OID: 2.5.29.37.0) キー目的ではない。
    • 新しい証明書の basicConstraints 拡張に、ゼロの pathLenConstraint がある。

• BasicOCSPResponseの signatureAlgorithm などのOCSPレスポンス内で使用される場合:

  • ResponseData の producedAt フィールド値は 2022-06-01 00:00:00 UTC より前でなければならない (MUST)。
  • CA鍵ペアの公開鍵を含み、同じ主体者識別名を持つ、有効期限が切れておらず、失効されていないすべての証明書には、存在する鍵使用法が id-kp-ocspSigning (OID: 1.3.6.1.5.5.7.3.9) のみである extKeyUsage 拡張も含まれていなければならない (MUST)。

• CRL内で使用される場合 (CertificateList の signatureAlgorithm フィールドや TBSCertList の signature フィールドなど) は次のとおりである。

  • CRLは1つ以上のルートCAまたは下位CA証明書によって参照される。
  • ルートCAまたは下位CA証明書は、署名アルゴリズムに次のエンコーディングを使用して 1 つ以上の証明書を発行した。

注意: 上記の要件により、CAはこのエンコードを使用して事前証明書に署名することはできない。

• SHA-1を使用したRSASSA-PKCS1-v1_5:

  エンコーディング: 300d06092a864886f70d0101050500

7.1.3.2.2 ECDSA

7.1.3.2.2 ECDSA

CAは、使用される署名鍵に基づいて適切な署名アルゴリズムとエンコーディングを使用する (SHALL)。

署名鍵が P-256 の場合、署名には SHA-256 を使用した ECDSA を使用しなければならない (MUST)。エンコードされると、AlgorithmIdentifier は次の16進エンコードされたバイトとバイト単位で同一でなければならない (MUST): 300a06082a8648ce3d040302

署名鍵が P-384 の場合、署名には SHA-384 を使用した ECDSA を使用しなければならない (MUST)。エンコードされると、AlgorithmIdentifier は次の16進エンコードされたバイトとバイト単位で同一でなければならない (MUST): 300a06082a8648ce3d040303

署名鍵が P-521 の場合、署名には SHA-512 を使用した ECDSA を使用しなければならない (MUST)。エンコードされると、AlgorithmIdentifier は次の16進エンコードされたバイトとバイト単位で同一でなければならない (MUST): 300a06082a8648ce3d040304

7.1.4 Name Forms

7.1.4 名前形式

属性値は RFC 5280 に従ってエンコードされる (SHALL)。

このSectionでは、CAによって発行されるすべての証明書に適用されるエンコードルールについて詳しく説明する。Section 7.1.2 でさらに制限が指定される場合があるが、これらの制限は Section 1.1.1 Standards, Criteria and Regulations に優先するものではない。

7.1.4.1 Name Encoding

7.1.4.1 名前のエンコード

以下の要件は、Section 7.1.2 に記載されているすべての証明書に適用される。

有効な認証パス（RFC 5280, Section 6 で定義）に関しては以下のとおり。

• 認証パス内の各証明書について、証明書の発行者識別名フィールドのエンコードされた内容は、発行CA証明書のサブジェクト識別名フィールドのエンコードされた形式とバイト単位で同一である (SHALL)。
• 認証パス内の各CA証明書について、証明書のサブジェクト識別名フィールドのエンコードされた内容は、期限切れの証明書や失効した証明書を含め、RFC 5280, Section 7.1 に従ってサブジェクト識別名が等しいと比較できるすべての証明書間でバイト単位で同一である (SHALL)。

Name をエンコードする際、CAは次の点を確認する (SHALL)。

• 各 Name には RDNSequence が含まれていなければならない (MUST)。
• 各 RelativeDistinguishedName には、AttributeTypeAndValue が 1 つのみ含まれていなければならない (MUST)。
• 各 RelativeDistinguishedName が存在する場合、Section 7.1.4.2 に現れる順序で RDNSequence 内にエンコードされる。
  • たとえば、countryName AttributeTypeAndValue ペアを含む RelativeDistinguishedName は、stateOrProvinceName AttributeTypeAndValue を含む RelativeDistinguishedName の前に、RDNSequence 内でエンコードされなければならない (MUST)。
• Section 1.1.1 Standards, Criteria and Regulations で明示的に許可されていない限り、各 Name には、すべての RelativeDistinguishedName にわたって、特定の AttributeTypeAndValue のインスタンスが複数含まれていてはならない (MUST NOT)。

7.1.4.2 Subject Attribute Encoding

7.1.4.2 主体者識別名属性のエンコード

このドキュメントでは、tbsCertificate の subject フィールド内に表示される可能性のある多数の属性の内容と検証の要件を定義している。CAは、Section 7.1.2 で指定された関連する証明書プロファイルで指定されているとおりに内容が検証されていない限り、またそのプロファイルで許可されている場合以外は、これらの属性を含めることができない (SHALL NOT)。

以下の表に記載されている属性を証明書の subject フィールドに含むCAは、それらの属性を表に表示されている相対順序でエンコードし、属性に指定されたエンコード要件に従う (SHALL)。

表: 選択した属性のエンコードと順序の要件

以下の表に記載されている証明書の subject フィールドに属性を含むCAは、その属性に指定されたエンコード要件に従う (SHALL)。

表: 選択した属性のエンコード要件

[^maxlength]: 注意: DirectoryString の ASN.1 の長さ制限は、バイト制限ではなく文字制限として表される。

7.1.4.3 Subscriber Certificate Common Name Attribute

7.1.4.3 利用者証明書のコモンネーム属性

規定しない。

7.1.4.4 Other Subject Attributes

7.1.4.4 その他の主体者識別名属性

Section 7.1.2 で指定された関連する証明書プロファイルによって明示的に許可されている場合、CAは Section 7.1.4.2 で指定された属性以外に、AttributeTypeAndValue 内に追加の属性を含めることができる (MAY)。

7.1.5 Name constraints

7.1.5 名前制約

規定しない。

7.1.6 Certificate policy object identifier

7.1.6 証明書ポリシーオブジェクト識別子

7.1.6.1 Reserved Certificate Policy Identifiers

7.1.6.1 予約済み証明書ポリシー識別子

次の証明書ポリシー識別子は、証明書が Section 1.1.1 Standards, Criteria and Regulations に準拠していることを示すオプションの手段としてCAが使用するために予約されている。

2.23.140.1.5.2.1および2.23.140.1.5.2.3は、セコムトラストシステムズがExternally-Operated Subordinate CAsに対してS/MIME下位CA証明書を発行する際に使用する。したがって、本CP/CPSでは、これらのOIDに対応するS/MIMEエンドエンティティ証明書の審査およびプロファイルについては言及していない。

7.1.7 Usage of Policy Constraints extension

7.1.7 ポリシー制約拡張の使用

規定しない。

7.1.8 Policy qualifiers syntax and semantics

7.1.8 ポリシー修飾子の構文および意味

ポリシー修飾子については、このCP/CPSを公開する Web ページの URI を保存できる (MAY)。

7.1.9 Processing semantics for the critical Certificate Policies extension

7.1.9 重要な証明書ポリシー拡張の意味

規定しない。

7.2 CRL profile

7.2 CRLプロファイル

[コードサイニング証明書]

失効された証明書のシリアル番号は、証明書の有効期限より前から少なくとも10年間はCRLに残しておかなければならない（MUST）。アプリケーションソフトウェア提供者は、CAとの契約においてより長い保持期間をCAに求めることができる（MAY）。 コードサイニング証明書にLifetime Signing OIDが含まれている場合、コードサインがタイムスタンプされていたとしても、コードサイニング証明書の有効期限が切れるとコードサインは無効になる。Lifetime Signing OIDは試験目的でのみ使用されることを意図しているため、CAはLifetime Signing OIDを含むコードサイニング証明書の有効期限が切れた後に、その証明書の失効情報の維持を中止することができる（MAY）。 コードサイニング証明書が以前に失効されており、CAが後により適切な失効日を把握した場合、CAはその失効日を以後のCRLエントリに使用することができる（MAY）。

[すべての証明書に共通 ]

表: CRLフィールド

7.2.1 Version number(s)

7.2.1 バージョン番号

証明書失効リストは、X.509 v2 タイプでなければならない (MUST)。

7.2.2 CRL and CRL entry extensions

7.2.2 CRLとCRLエントリー拡張

表: CRL拡張

表: revokedCertificates コンポーネント

表: crlEntryExtensions コンポーネント

表: CRLReasons

利用者契約書、またはその中で参照されるオンラインリソースでは、利用者に上記の失効理由オプションについて通知し、各オプションを選択するタイミングについて説明を提供しなければならない (MUST)。CAが利用者に提供するツールでは、利用者が証明書の失効を要求するときにこれらのオプションを簡単に指定できるようにしなければならない (MUST)。デフォルト値は失効理由が提供されないことである (つまり、デフォルトは CRLReason が「未指定 (0)」に相当し、CRLに reasonCode 拡張が提供されない)。

privilegeWithdrawn reasonCodeは、失効理由オプションとして利用者に提供しないようにする (SHOULD NOT)。この reasonCode の使用は利用者ではなくCAによって決定されるためである。

CAが、CRLエントリーに reasonCode 拡張が含まれていないか、または reasonCode 拡張に keyCompromise 以外の理由が含まれている証明書の鍵危殆化の検証可能な証拠を取得した場合、CAはCRLエントリーを更新して、reasonCode 拡張の CRLReason として keyCompromise を入力する必要がある (SHOULD)。

7.2.2.1 CRL Issuing Distribution Point

7.2.2.1 CRL発行配布ポイント

パーティション化されたCRLには、distributionPoint 拡張が含まれている必要がある。発行配布ポイント拡張の distributionPoint フィールドが存在しなければならない (MUST)。さらに、DistributionPointName 値の fullName フィールドが存在しなければならず (MUST)、その値は次の要件に準拠していなければならない (MUST)。

1. CRLの範囲内の証明書にCRL配布ポイント拡張が含まれている場合、CRL配布ポイントの fullName フィールドにある少なくとも 1 つの uniformResourceIdentifiers が、CRLの発行配布ポイント拡張の fullName フィールドに含まれていなければならない (MUST)。発行配布ポイント拡張の uniformResourceIdentifier 値のエンコードは、証明書のCRL配布ポイント拡張で使用されるエンコードとバイト単位で同一でなければならない (MUST)。
2. 他のuniformResourceIdentifier タイプの GeneralNames も含めることができる (MAY)。
3. 非uniformResourceIdentifier GeneralName タイプを含めることはできない (MUST NOT)。

indirectCRL および onlyContainsAttributeCerts フィールドは FALSE (つまり、使用されない) に設定されなければならない (MUST)。

CAは、CRLの範囲に応じて、onlyContainsUserCerts フィールドと onlyContainsCACerts フィールドのいずれかを TRUE に設定できる (MAY)。

CA は、onlyContainsUserCerts フィールドと onlyContainsCACerts フィールドの両方を使用してはならない (MUST NOT)。

onlySomeReasons フィールドは含めないようにする (SHOULD NOT)。含める場合、CAは理由コードに関係なくすべての失効を範囲とする別のCRLを提供しなければならない (MUST)。

この拡張は、full CRLには推奨されない (NOT RECOMMENDED)。

7.3 OCSP profile

7.3 OCSPプロファイル

OCSP応答が Root CAまたは下位CA証明書 (相互認証された下位CA証明書を含む) に対するものであり、その証明書が失効している場合は、CertStatus の RevokedInfo 内の revocationReason フィールドが存在しなければならない (MUST)。

示された CRLReason には、Section 7.2.2 で指定されているように、CRL に許可された値が含まれていなければならない (MUST)。

7.3.1 Version number(s)

7.3.1 バージョン番号

CAはOCSPバージョン 1 を使用する。

7.3.2 OCSP extensions

7.3.2 OCSP拡張

OCSP 応答の singleExtensions には、reasonCode (OID 2.5.29.21) CRL エントリ拡張を含めることはできない (MUST NOT)。

8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS

8 準拠性監査とその他の監査基準

CAは常に次の事項を遵守する (SHALL)。

1. 事業を展開するすべての管轄区域において、その事業および発行する証明書に適用されるすべての法律に従って証明書を発行し、PKIを運用する。
2. Section 1.1.1 Standards, Criteria and Regulations に準拠する。
3. CP/CPSに規定された監査要件に準拠する。
4. 証明書の発行に当該管轄区域の法律によりライセンスが必要な場合は、運営する各管轄区域でCAとしてライセンスを取得する必要がある。

8.1 Frequency or circumstances of assessment

8.1 評価の頻度と要件

新しい証明書を発行するために使用できる証明書はこの Section の残りのすべての要件に従って完全に監査されなければならない (MUST)。証明書に X.509v3 basicConstraints 拡張が含まれており、cAブール値が true に設定されている場合、新しい証明書を発行するために使用できるとみなされ、したがって定義上、Root CA 証明書または下位CA証明書になる。

CAが証明書を発行する期間は、連続した監査期間に分割される (SHALL)。監査期間は 1 年を超えてはならない (MUST NOT)。

CAが Section 8.4 に記載されている監査スキームのいずれかに準拠していることを示す現在有効な監査レポートを持っていない場合、CAは、パブリックトラスト証明書を発行する前に、Section 8.4 に記載されている監査スキームのいずれかの適用可能な標準に従って実行されるポイントインタイムの準備状況評価に合格する (SHALL)。ポイントインタイムの準備状況評価は、パブリックトラスト証明書を発行する 12 か月前までに完了するものとし (SHALL)、最初のパブリックトラスト証明書を発行してから 90 日以内に、そのようなスキームに基づく完全な監査が続く (SHALL)。

8.2 Identity/qualifications of assessor

8.2 監査人の身元/資格

CAの監査は、公認監査人によって実行される (SHALL)。公認監査人とは、以下の資格およびスキルを総合的に有する自然人、法人、または自然人もしくは法人のグループを指す。

1. 監査の対象から独立している。
2. 適格な監査スキームで指定されている条件に対応する監査を実施できる能力（Section 8.4 を参照）
3. 公開鍵基盤技術、情報セキュリティツールと技術、情報技術とセキュリティ監査および第三者の認証機能の検査に精通した個人を雇用する。
4. (WebTrust規格に基づいて実施される監査の場合) WebTrustによる実施許可を受けている。
5. 法律、政府の規制、または職業倫理に準拠している。
6. 国内政府監査機関の場合を除き、少なくとも100万米ドルの補償を保険範囲とする業務上の過失および不備に対する責任保険に加入している。

8.3 Assessor's relationship to assessed entity

8.3 監査人と被監査部門の関係

監査人は、監査関連の側面を除き、評価対象組織から業務上および組織的に独立している (SHALL)。監査を実施するにあたり、評価対象組織は監査活動に対して適切な支援を提供する (SHALL)。

8.4 Topics covered by assessment

8.4 監査で扱われる事項

CAは以下のスキームに従って監査を受ける (SHALL)。

1. WebTrust (S/MIME CA):

   • S/MIME Baseline Requirements の最初のバージョンの Section 1.2.1 で定義されている発効日より前に開始される監査期間については、"WebTrust for CAs v2.2.2以降"
   • S/MIME Baseline Requirements の最初のバージョンの Section 1.2.1 で定義された発効日以降に開始する監査期間については、"WebTrust for CAs v2.2.2以降" および "WebTrust for S/MIME Baseline Requirements v1.0.0以降"
   • 2025-04-01 以降に開始する監査期間の場合、"WebTrust for CAs v2.2.2 以降"、"WebTrust for S/MIME Baseline Requirements v1.0.0以降" および "WebTrust for Network Security v2.0 以降"

2. WebTrust (コードサイニングCA):

   • “WebTrust for CAs v2.0" および "WebTrust for Certification Authorities – Code Signing Baseline Requirements v2.0以降" および “WebTrust for Certification Authorities – Network Security – Version 1.0 以降"

1. WebTrust (AATLドキュメントサイニングCAおよびAATLタイムスタンプCA):

   • “WebTrust for CA v.2.0以降”;

監査が制度の要件に従って継続的に実施されることを保証するために、定期的な監視/説明責任の手順を組み込まなければならない (MUST)。

監査は、Section 8.2 に規定されているように、公認監査人によって実施されなければならない (MUST)。

エンタープライズRAではない外部委託先の場合、CAは、外部委託先のパフォーマンスが外部委託先の運用規程またはCAの CP/CPSのいずれかに準拠しているかどうかの意見を提供する、Section 8.4 に記載されている承認済み監査スキームの基礎となる監査基準に基づいて発行された監査レポートを取得する (SHALL)。外部委託先が準拠していないという意見の場合、CAは外部委託先が委任された機能を継続して実行することを許可しない (SHALL NOT)。

外部委託先の監査期間は 1 年を超えない (SHALL NOT) (理想的にはCAの監査と一致する)。

8.5 Actions taken as a result of deficiency

8.5 不備に対する対応

セコムトラストシステムズは、監査報告書で指摘された不備に対してすみやかに是正措置を実施する。

8.6 Communication of results

8.6 監査結果の公開

監査レポートには、 Section 7.1.6.1 に記載されているポリシー識別子の 1 つ以上を主張するすべての証明書の発行に使用される関連システムとプロセスが対象となっていることが明示的に記載される (SHALL)。CAは監査レポートを公開する (SHALL)。

CAは、監査期間の終了後 3 か月以内に監査レポートを公開しなければならない (MUST)。3 か月を超える遅延が発生した場合、CAは公認監査人が署名した説明文書を提供する (SHALL)。

監査レポートには、少なくとも次の明確にラベル付けされた情報が含まれていなければならない (MUST)。

1. 監査対象の組織の名称
2. 監査を実施する組織の名称と住所
3. 監査の範囲内にあった、クロス認証された下位CA証明書を含む、すべての Root および下位CA証明書のSHA-256フィンガープリント
4. 各証明書（および関連する鍵）を監査するために使用された監査基準とバージョン番号
5. 監査中に参照されたCAポリシー文書のリスト（バージョン番号付き）
6. 監査が一定期間を評価したのか、それともある時点を評価したのか
7. 監査期間が一定期間にわたる場合、開始日と終了日
8. 監査期間がある時点のものである場合は、その時点の日付
9. レポートが発行された日付。これは必ず終了日または特定の時点より後の日付になる。

公に入手可能な監査情報の信頼できる英語版は、公認監査人によって提供されなければならず(MUST)、CAはそれが公に入手可能であることを保証する(SHALL)。

監査レポートはPDF形式で提供されなければならず (MUST)、必要なすべての情報についてテキスト検索可能である (SHALL)。監査レポート内の各SHA-256フィンガープリントは大文字でなければならず (MUST)、コロン、スペース、または改行を含んではならない (MUST NOT)。

8.7 Self-Audits

8.7 自己監査

• S/MIME CA

  CAが証明書を発行する期間中、CAはCP/CPSおよび S/MIME Baseline Requirements への準拠を監視し、少なくとも四半期ごとに、前回の自己監査サンプルが取得された直後から始まる期間中にCAが発行した証明書の 3% または 30個のいずれか大きい方の証明書を含むランダムに選択されたサンプルに対して自己監査を実行することにより、サービス品質を管理する (SHALL)。

  2025年3月15日以降、CAは、同じ証明書に対して以前に実行されたリンティングとは独立して、選択されたサンプルセット内の証明書の技術的な正確性を検証するためにリンティングプロセスを使用する必要がある (SHOULD)。

• コードサイニングCA

  CAは、Baseline Requirements for Code Signing Certificates の自己監査要件を遵守しなければならない。コードサイニング証明書を発行する期間中、CAは、最後のサンプルが採取された直後に始まる期間に発行した非EVコードサイニング証明書の少なくとも 3% とEVコードサイニング証明書の少なくとも 3% のランダムに選択されたサンプルに対して継続的な自己監査を実行することにより、サービス品質を厳密に管理しなければならない (MUST)。Baseline Requirements for Code Signing Certificates のSection 8 の最終的な相互照合と適切な精査の要件がRAによって実行されるすべてのコードサイニング証明書については、CAは、最後のサンプルが採取された直後に始まる期間に発行した非EVコードサイニング証明書の少なくとも 6% とEVコードサイニング証明書の少なくとも 6% のランダムに選択されたサンプルに対して継続的な自己監査を実行することにより、サービス品質を厳密に管理しなければならない (MUST)。

8.8 Review of delegated parties

8.8 委託先のレビュー

Section 8.4 で指定された基準を満たす年次監査を受ける外部委託先、Enterprise RAおよび技術的に制約のある下位CAを除き、CAは委任された当事者の慣行と手順が Section 1.1.1 Standards, Criteria and Regulations および関連するCP/CPSに準拠していることを確認する (SHALL)。CAは委任された当事者の義務を文書化し、委任された当事者がそれらの義務を遵守しているかどうかを少なくとも毎年監視する (SHALL)。

9. OTHER BUSINESS AND LEGAL MATTERS

9 その他の業務上および法的事項

9.1 Fees

9.1 料金

9.1.1 Certificate issuance or renewal fees

9.1.1 証明書の発行/更新手数料

契約書に別途規定する。

9.1.2 Certificate access fees

9.1.2 証明書アクセス料金

規定しない。

9.1.3 Revocation or status information access fees

9.1.3 失効またはステータス情報アクセス料金

規定しない。

9.1.4 Fees for other services

9.1.4 その他のサービス料金

規定しない。

9.1.5 Refund policy

9.1.5 返金ポリシー

契約書に別途規定する。

9.2 Financial responsibility

9.2 財務的責任

9.2.1 Insurance coverage

9.2.1 保険適用範囲

規定しない。

9.2.2 Other assets

9.2.2 その他の資産

規定しない。

9.2.3 Insurance or warranty coverage for end-entities

9.2.3 エンドエンティティに対する保険または保証範囲

規定しない。

9.3 Confidentiality of business information

9.3 企業情報の機密保持

9.3.1 Scope of confidential information

9.3.1 機密情報の範囲

セコムトラストシステムズが所有する個人および組織に関する情報は、証明書、CRL、本 CP/CPSの一部として明示的に公開されたものを除き、機密保持の対象となる。

セコムトラストシステムズは、法律で義務付けられている場合、または関連する利用者の事前の同意がある場合を除き、そのような情報を外部に開示しない。セコムトラストシステムズは、法律で義務付けられている法律、司法、行政またはその他の手続きに関連してアドバイスを提供する法律顧問または財務アドバイザーに機密情報を開示する場合がある。また、企業の合併、買収、または再編に関するアドバイスを提供する弁護士、会計士、法的機関、またはその他の専門家に機密情報を開示する場合がある。

利用者の私有鍵は、利用者自身の責任において秘密に保持されるべき情報とみなされる。いかなる場合も、本サービスはこれらの鍵へのアクセスを提供しない。監査ログおよび監査レポートに含まれる情報自体は機密保持の対象であり、機密情報の範囲内である。セコムトラストシステムズは、Section 8.6 に規定されている場合、または法律で要求されている場合を除き、そのような情報を外部に開示しない。

9.3.2 Information not within the scope of confidential information

9.3.2 機密情報の範囲外の情報

証明書およびCRLに入力された情報は機密情報とはみなされない。また、以下の情報は、本機密保持規定の対象にはならない。

• セコムトラストシステムズの責によらずに知り得た、または知った情報。
• セコムトラストシステムズ以外の当事者から機密保持義務なしにセコムトラストシステムズに知らされた、または知らされる情報。
• セコムトラストシステムズが独自に開発した情報
• 当該利用者により開示が承認された情報。

9.3.3 Responsibility to protect confidential information

9.3.3 機密情報の保護責任

セコムトラストシステムズは、法令に基づき開示を求められた場合、または契約者の事前の同意がある場合には、秘密情報を開示することがある。この場合、情報を入手した当事者は、契約上または法律上の制約により、当該情報を第三者に開示することができない。

9.4 Privacy of personal information

9.4 個人情報保護方針

9.4.1 Privacy plan

9.4.1 個人情報保護プラン

セコムトラストシステムズは、当社の認証サービス利用者から収集した個人情報を、申込内容の確認、必要書類等の送付、本人確認など、電子認証基盤上で運用する本CAの運営に必要な範囲で利用する。 セコムトラストシステムズのプライバシーポリシーは、セコムトラストシステムズのホームページ（http://www.secomtrust.net）で公表する。

9.4.2 Information treated as private

9.4.2 個人情報として扱われる情報

セコムトラストシステムズは、国内法令に基づき個人情報と定義される情報（セコム認証サービスの利用者から収集した情報等）を個人情報として取り扱い、適切に管理する。

9.4.3 Information not deemed private

9.4.3 個人情報と見なされない情報

セコムトラストシステムズは、個人情報を Section 9.4.2 に規定されているとおりに取り扱う。

9.4.4 Responsibility to protect private information

9.4.4 個人情報の保護責任

セコムトラストシステムズは、契約の締結および終了にあたり知り得た相手方の個人情報を、契約期間中、契約終了後を問わず第三者に開示しない。また、個人情報保護管理者を置き、従業員に個人情報保護方針を遵守させる。

9.4.5 Notice and consent to use private information

9.4.5 個人情報利用に関する通知と同意

セコムトラストシステムズは、法令に定める場合を除き、証明書利用者の同意を得る目的以外で個人情報を利用しない。個人番号および特定個人情報は、法令で認められた利用目的および証明書利用者の同意を得た利用目的のために利用されている。

9.4.6 Disclosure pursuant to judicial or administrative process

9.4.6 司法または行政手続に沿った情報開示

法令、規則、裁判所の決定・命令、行政機関の命令・指示等により開示を求められた場合、証明書利用者の個人情報は開示されることがある。

9.4.7 Other information disclosure circumstances

9.4.7 その他の情報開示要件

規定しない。

9.5 Intellectual property rights

9.5 知的財産権

セコムトラストシステムズと利用者との間で別段の合意がない限り、本サービスに関する以下の情報資料およびデータは、以下に定める当事者に帰属する。

9.6 Representations and warranties

9.6 表明および保証

9.6.1 CA representations and warranties

9.6.1 CAの表明および保証

証明書を発行することにより、CAは以下の証明書受益者に対してここに記載されている証明書保証を行う。

1. 利用者契約または証明書の使用条件の当事者である利用者。
2. Root CAが、そのアプリケーションソフトウェアサプライヤーが配布するソフトウェアにルート証明書を含める契約を締結したすべてのアプリケーションソフトウェアサプライヤー
3. 有効な証明書に合理的に依存するすべての検証者。CAは、証明書の有効期間中、証明書の発行および管理において Section 1.1.1 Standards, Criteria and Regulations およびCP/CPSに準拠していることを証明書受益者に表明し、保証する。

証明書保証には具体的には以下の内容が含まれるが、これらに限定されない。

1. メールボックスアドレスの使用権 [S/MIME 証明書]: 発行時にCAは、

   i. 申請者が証明書の subject フィールドと subjectAltName 拡張に記載されているメールボックスアドレスを使用する権利、または管理権を持っていることを確認する手順を実装した（または、そのような使用権または管理権を持つ人物からそのような権利または管理権が委任された）。 ii. 証明書を発行する際にその手順に従った。 iii. CA の CP/CPS にその手順を正確に記載した。

2. コンプライアンス. CAは、各証明書の発行およびPKIまたは委任サービスの運用において、Section 1.1.1 Standards, Criteria and Regulations の標準、基準、規制に準拠している。

3. 証明書の承認: 発行時にCAは、

   i. 対象者が証明書の発行を承認したことおよび申請者代表が対象者に代わって証明書を要求する権限を持っていることを確認する手順を実装した。 ii. 証明書を発行する際の手順に従った。 iii. CAのCP/CPSに手順を正確に記載した。

4. 情報の正確性: 発行時にCAは、

   i. 証明書に含まれるすべての情報の正確性を検証するための手順を実施した。 ii. 証明書を発行する際の手順に従った。 iii. CAのCP/CPSに手順を正確に記載した。

5. 鍵の保護: CAは、コードサイニング証明書およびAATLドキュメントサイニング証明書に関連付けられた私有鍵を安全に保管し、不正使用を防止する方法に関するドキュメントを発行時に利用者に提供したことを表明する。

6. 申請者の身元: 証明書に主体者識別名識別情報が含まれている場合、CAは、

   i. Section 3.2 および Section 7.1.2に従って申請者の身元を確認する手順を実施した。 ii. 証明書を発行する際の手順に従った。 iii. CAのCP/CPSに手順を正確に記載した。

7. 利用者契約: CAと利用者が提携関係にない場合、利用者とCAは、Section 1.1.1 Standards, Criteria and Regulations を満たす法的に有効かつ強制力のある利用者契約の当事者である、またはCAと利用者が同じ組織であるか提携関係にある場合、申請者代表は利用規約を承認している。

8. ステータス: CAは、有効期限内のすべての証明書のステータス (有効または失効) に関する最新情報を24時間365日公開可能なリポジトリーに保持する。

9. 失効: CAは、Section 1.1.1 Standards, Criteria and Regulationsに指定されたいずれかの理由により証明書を失効する。

Root CAは、Root CAが証明書を発行する下位CAであるかのように、下位CAの履行と保証、下位CAの Section 1.1.1 Standards, Criteria and Regulationsへの準拠および Section 1.1.1 Standards, Criteria and Regulations に基づく下位CAのすべての責任と補償義務について責任を負う (SHALL)。

9.6.2 RA representations and warranties

9.6.2 RAの表明および保証

本CP/CPS Section 9.6.1 と同様。

9.6.3 Subscriber representations and warranties

9.6.3 利用者の表明および保証

CAは、利用者契約または利用規約の一部として、申請者がCAおよび証明書受益者の利益のために本セクションの約束と保証を行うことを要求する (SHALL)。

[S/MIME証明書]

証明書の発行前に、CAは、CAおよび証明書の受益者の明示的な利益のために、以下のいずれかを取得しなければならない（SHALL）：

1. CAとの利用者契約に対する申請者の同意
2. 利用条件に対する申請者の承認

CAは、各利用者契約または利用条件が申請者に対して法的に強制力を持つことを確保するためのプロセスを実装しなければならない（SHALL）。いずれの場合も、契約は証明書リクエストに基づいて発行される証明書に適用されなければならない（MUST）。CAは、電子的または「クリック同意」形式の契約を使用してもよい（MAY）が、その契約が法的に強制力を持つと判断している必要がある。証明書リクエストごとに個別の契約を使用してもよく（MAY）、または将来の複数の証明書リクエストおよびそれに基づいて発行される証明書を対象とする単一の契約を使用してもよい（MAY）。ただし、CAが申請者に対して発行する各証明書が、その利用者契約または利用条件によって明確に対象とされている必要がある。

利用者契約または利用条件には、申請者自身（または申請者が委託先やホスティングサービスとの関係において、その主体者または代理人のために行う場合）に対して、以下の義務および保証を課す条項を含めなければならない（MUST）：

1. 情報の正確性：証明書リクエストにおいて、またCAが証明書の発行に関連して要求する場合において、常に正確かつ完全な情報をCAに提供する義務および保証
2. 私有鍵の保護：申請者が、要求された証明書に含まれる公開鍵に対応する私有鍵（および関連するアクティベーションデータやデバイス、例：パスワードやトークン）を常に管理し、機密性を保持し、適切に保護するために合理的な措置を講じる義務および保証
3. 証明書の受領：利用者が証明書の内容を確認し、正確性を検証する義務および保証
4. 証明書に記載されたMailBox Addressでのみ証明書を使用する義務および保証（SHALL）、ならびに証明書をすべての適用法令および利用者契約または利用条件にのみ従って使用する義務および保証（SHALL）
5. 報告および失効：以下の義務および保証
   a. 証明書に含まれる公開鍵に対応する利用者の私有鍵が実際に、または疑わしく不正使用または漏洩された場合、証明書の失効をすみやかに要求し、証明書および私有鍵の使用を停止すること
   b. 証明書の情報が不正確または不正確になった場合、証明書の失効をすみやかに要求し、使用を停止すること
6. 証明書の使用終了：鍵漏洩により証明書が失効された場合、対応する私有鍵の使用をすみやかに停止する義務および保証
7. 応答性：鍵漏洩または証明書の不正使用に関するCAの指示に、指定された期間内に応答する義務
8. 認識および受諾：申請者が利用者契約または利用条件に違反した場合、またはCAのCP/CPSまたはSection 1.1.1 Standards, Criteria and Regulationsにより失効が求められる場合、CAが証明書を即時失効する権利を有することの認識および受諾

[コードサイニング証明書]

証明書の発行に先立ち、CAは、CAおよび証明書の利害関係者の明示的な利益のために、以下のいずれかを取得しなければならない（SHALL）：

1. CAとの利用者契約に対する申請者の同意
2. 利用条件に対する申請者の承認

CAは、各利用者契約または利用条件が申請者に対して法的に強制力を持つことを保証するプロセスを実装しなければならない（SHALL）。いずれの場合も、契約は証明書リクエストに基づいて発行される証明書に適用されなければならない（MUST）。CAは、電子的または「クリック同意型」の契約を使用してもよい（MAY）が、その契約が法的に強制力を持つと判断している必要がある。証明書リクエストごとに個別の契約を使用してもよく（MAY）、または将来の複数の証明書リクエストおよびそれに基づく証明書を対象とする単一の契約を使用してもよい（MAY）。ただし、CAが申請者に発行する各証明書がその利用者契約または利用条件に明確に含まれていることが必要である。

利用者契約または利用条件には、申請者自身（または申請者が委託先やホスティングサービスとの関係において代理人や主契約者のために行う場合）に対して、以下の義務および保証を課す条項を含めなければならない（MUST）：

1. 情報の正確性：証明書の発行に関連して、証明書リクエストを含む、またCAが要求するその他の情報について、常に正確かつ完全な情報を提供すること。
2. 私有鍵の保護：署名サービスの外部で鍵が利用可能な場合、Section 6.2.7に従って、対応する私有鍵（および関連するアクティベーションデータやデバイス、例：パスワードやトークン）を常に単独で管理し、秘密にし、適切に保護すること。CAは私有鍵の保護方法に関する文書を利用者に提供しなければならない（MUST）。この文書はホワイトペーパーとして、または利用者契約の一部として提供してもよい（MAY）。利用者は、私有鍵を格納するデバイスを、CAが注文プロセス中に提供するコード署名のベストプラクティス文書に記載された安全な方法で生成・運用することを表明しなければならない（MUST）。CAは、私有鍵を輸送する際に、16文字以上で大文字・小文字・数字・記号を含むランダム生成されたパスワードを使用するよう利用者に義務付けなければならない（MUST）。
3. 私有鍵の再利用禁止：証明書内の公開鍵がコード署名以外の証明書で使用されている、または使用される予定である場合、コード署名証明書を申請してはならないこと。
4. 使用目的：証明書および関連する私有鍵を、許可された合法的な目的のみに使用すること。疑わしいコードの署名に証明書を使用してはならず、すべての適用法令および利用者契約または利用条件に従ってのみ使用すること。
5. 業界標準の遵守：CAがこれらの要件またはSection 1.1.1 Standards, Criteria and Regulationsの変更に対応するために利用者契約または利用条件を変更する可能性があることを認識し、受け入れること。
6. 不正使用の防止：私有鍵の不正使用を防ぐために、適切なネットワークおよびその他のセキュリティ対策を提供すること。また、私有鍵への不正アクセスがあった場合、CAは事前通知なしに証明書を失効させることができる。
7. 証明書の受領：申請者またはその代理人が証明書の内容を確認し、正確性を検証するまで証明書を使用してはならないこと。
8. 報告と失効：以下のいずれかに該当する場合、証明書および関連する私有鍵の使用を直ちに停止し、CAに証明書の失効をすみやかに要求すること：
   (a) 証明書の情報が不正確または不正確になる場合
   (b) 証明書に含まれる公開鍵に対応する私有鍵が不正使用または漏洩した場合
   (c) 証明書が疑わしいコードの署名に使用された証拠がある場合
9. 情報の共有：以下のいずれかに該当する場合、CAが申請者、署名されたアプリケーション、証明書およびその周辺状況に関する情報を他のCAや業界団体（CA/Browser Forumを含む）と共有することを認識し、受け入れること：
   (a) 証明書または申請者が疑わしいコードの発信源と特定された場合
   (b) 証明書の申請権限が確認できない場合
   (c) 証明書が利用者の要求以外の理由（私有鍵の漏洩、マルウェアの発見など）で失効された場合
10. 証明書の使用終了：証明書の有効期限切れまたは失効時に、証明書に記載された公開鍵に対応する私有鍵の使用を直ちに停止すること。
11. 対応義務：私有鍵の漏洩や証明書の不正使用に関するCAの指示に、指定された期間内に対応する義務。
12. 承認と受諾：申請者が利用条件または利用者契約に違反した場合、CAが証明書を即時に失効させる権利を有することを認識し、受け入れること。

[その他の証明書]

証明書の発行に先立ち、CAは、CAおよび証明書の利害関係者の明示的な利益のために、以下のいずれかを取得しなければならない（SHALL）：

1. CAとの利用者契約に対する申請者の同意
2. 利用条件に対する申請者の承認

CAは、各利用者契約または利用条件が申請者に対して法的に強制力を持つことを保証するプロセスを実装しなければならない（SHALL）。いずれの場合も、契約は証明書リクエストに基づいて発行される証明書に適用されなければならない（MUST）。CAは、電子的または「クリック同意型」の契約を使用してもよい（MAY）が、その契約が法的に強制力を持つと判断している必要がある。証明書リクエストごとに個別の契約を使用してもよく（MAY）、または将来の複数の証明書リクエストおよびそれに基づく証明書を対象とする単一の契約を使用してもよい（MAY）。ただし、CAが申請者に発行する各証明書がその利用者契約または利用条件に明確に含まれていることが必要である。

利用者契約または利用条件には、申請者自身（または申請者が委託先やホスティングサービスとの関係において代理人や主契約者のために行う場合）に対して、以下の義務および保証を課す条項を含めなければならない（MUST）：

1. 情報の正確性：証明書の発行に関連して、証明書リクエストを含む、またCAが要求するその他の情報について、常に正確かつ完全な情報を提供すること。
2. 私有鍵の保護：署名サービスの外部で鍵が利用可能な場合、Section 6.2.7に従って、対応する私有鍵（および関連するアクティベーションデータやデバイス、例：パスワードやトークン）を常に単独で管理し、秘密にし、適切に保護すること。CAは私有鍵の保護方法に関する文書を利用者に提供しなければならない（MUST）。この文書はホワイトペーパーとして、または利用者契約の一部として提供してもよい（MAY）。
   利用者は、本CP/CPSに定められたすべての鍵管理要件を遵守しなければならない（SHALL）。
3. 使用目的：証明書および関連する私有鍵を、許可された合法的な目的のみに使用し、すべての適用法令および利用者契約または利用条件に従ってのみ使用すること。
4. 業界標準の遵守：CAがSection 1.1.1 Standards, Criteria and Regulationsの変更に対応するために利用者契約または利用条件を変更する可能性があることを認識し、受け入れること。
5. 不正使用の防止：私有鍵の不正使用を防ぐために、適切なネットワークおよびその他のセキュリティ対策を提供すること。また、私有鍵への不正アクセスがあった場合、CAは事前通知なしに証明書を失効させることができる。
6. 証明書の受領：申請者またはその代理人が証明書の内容を確認し、正確性を検証するまで証明書を使用してはならないこと。
7. 報告と失効：以下のいずれかに該当する場合、証明書および関連する私有鍵の使用を直ちに停止し、CAに証明書の失効をすみやかに要求すること：
   (a) 証明書の情報が不正確または不正確になる場合
   (b) 証明書に含まれる公開鍵に対応する私有鍵が不正使用または漏洩した場合
8. 情報の共有：証明書の申請権限が確認できない場合、CAが申請者、署名されたアプリケーション、証明書およびその周辺状況に関する情報を他のCAや業界団体と共有することを認識し、受け入れること。
9. 証明書の使用終了：証明書の有効期限切れまたは失効時に、証明書に記載された公開鍵に対応する私有鍵の使用を直ちに停止すること。
10. 対応義務：私有鍵の漏洩や証明書の不正使用に関するCAの指示に、指定された期間内に対応する義務。
11. 承認と受諾：申請者が利用条件または利用者契約に違反した場合、CAが証明書を即時に失効させる権利を有することを認識し、受け入れること。

9.6.4 Relying party representations and warranties

9.6.4 検証者の表明および保証

CAサービスの検証者には、以下の義務がある。

• CAによって発行された証明書を信頼し、本CP/CPSでこのCAによって指定された目的にのみ証明書を使用する。
• 証明書を信頼しようとするときは、リポジトリー内のCRLまたはOCSPレスポンダーによって証明書が失効されていないことを確認する。
• 証明書を信頼する場合は、証明書の有効期間を確認し、有効期間内であることを確認する。
• このCAによって発行された証明書を信頼する場合は、証明書がCAの証明書によって署名および検証できることを確認する。
• CAの証明書を信頼して使用する場合、本CP/CPSで指定されているように、検証者として責任を負うことに同意する。

9.6.5 Representations and warranties of other participants

9.6.5 その他関係者の表明および保証

規定しない。

9.7 Disclaimers of warranties

9.7 保証の免責

CAは、Section 9.6.1 および Section 9.6.2 に規定されている保証に関連して発生する直接的、特別、偶発的または結果的な損害、または逸失利益、データ損失、またはその他の間接的または結果的な損害について責任を負わない。

9.8 Limitations of liability

9.8 責任の制限

本CP/CPSにおいて、CAは、以下の場合には、本CP/CPSの「9.6.1 CAの表明および保証」および「9.6.2 RAの表明および保証」の規定について責任を負わない。

• 違法行為、無許可使用、過失、またはCAに帰責事由のないその他の原因から生じた損害。
• 確認された情報の誤りが申請者の詐欺または故意の不正行為の結果である場合、いかなる場合でも一切の責任を負わない。
• 利用者が義務を履行しなかったことに起因する損害。
• 利用者または検証者のシステムに起因する損害。
• 利用者の環境（ハードウェアまたはソフトウェア）の欠陥、故障、またはその他の動作に起因する損害
• 利用者が契約書に定められた加入料の支払いを怠った期間中に生じた損害。
• CAに帰責事由のない理由により、証明書、CRL、またはOCSPレスポンダーに公開された情報によって生じた損害。
• CAの責任に帰責事由によらない理由により正常な通信が停止したことにより生じた損害。
• 取引債務を含む証明書の使用に関連して生じる損害。
• 委託先によるサービス提供義務の不履行（委託先によるサービス提供の終了など）により生じた損害。
• 現時点での予想を超えるハードウェアまたはソフトウェアの暗号アルゴリズムの解読技術の向上に起因する損害。
• 自然災害、地震、噴火、火災、津波、洪水、落雷、戦争、内乱、テロリズムなど、不可抗力によりCAの業務が停止したことに起因する損害。

9.9 Indemnities

9.9 補償

利用者および検証者に対する責任の制限があっても、CAは、ルート認証局とルート証明書配布契約を締結しているアプリケーションソフトウェアサプライヤーが、 Section 1.1.1 Standards, Criteria and Regulations に基づく、あるいは証明書の発行・維持、またはそれに対する信頼によって発生する可能性のある認証局の義務や責任を一切負わないことを理解し、認める。

CAは、CAが発行した証明書に関連してアプリケーションソフトウェアサプライヤーが被ったすべての請求、損害および損失について、その請求原因や法的理論にかかわらず、アプリケーションソフトウェアサプライヤーを擁護し、補償・損害を負わせないものとする。

ただし、当該アプリケーションソフトウェアサプライヤーのソフトウェアが、以下のいずれかの方法で証明書を誤って表示したことにより直接引き起こされた請求、損害、または損失には適用されない。

1. 有効な証明書を信頼できないものとして表示した場合

2. 以下の証明書を信頼できるものとして表示した場合

   • 有効期限が切れた証明書
   • 失効済みの証明書（ただし、その失効ステータスがCAからオンラインで現在取得可能であり、かつアプリケーションソフトウェアがそのステータスを確認しなかった、または失効の表示を無視した場合に限る）

9.10 Term and termination

9.10 CP/CPSの効力開始と終了

9.10.1 Term

9.10.1 CP/CPSの効力開始

本CP/CPSは、本委員会の承認を得て発効する。

本CP/CPSは、Section 9.10.2 に規定される終了までは、いかなる状況においても効力を失うことはない。

9.10.2 Termination

9.10.2 CP/CPSの効力終了

本CP/CPSは、Section 9.10.3 に規定されている規定を除き、CAによる本CP/CPSの終了と同時に効力を失う。

9.10.3 Effect of termination and survival

9.10.3 CP/CPSの効力継続

利用者による証明書の使用が終了した場合、または外部委託先が提供するサービスが終了した場合、もしくはCAが事業を停止した場合であっても、その性質上有効に存続すべき規定は、その理由にかかわらず、かかる終了後も存続し、利用者およびCAに関して完全に効力を維持する。

9.11 Individual notices and communications with participants

9.11 関係者への個別通知および連絡

CAは外部委託先に必要な通知を提供し、外部委託先は、Web サイト、Email、またはその他の書面形式を通じて利用者および検証者に必要な通知を提供する。

9.12 Amendments

9.12 改訂

9.12.1 Procedure for amendment

9.12.1 改訂手続

1. 重要な改訂/修正 セコムは、本CP/CPSの改訂が利用者および検証者による証明書またはCRLの使用活動に明らかな影響を及ぼすと判断される場合、改訂後の本CP/CPS(バージョン履歴/説明/日付を含む) をリポジトリーに公開し、メジャーバージョン番号を更新することにより、利用者および検証者に本CP/CPSの改訂を通知する。

2. 重要でない改訂/修正 セコムは、本CP/CPSの改訂が利用者および検証者による証明書またはCRLの使用活動に影響を及ぼさないか、または影響が小さいと判断される場合、改訂後の本CP/CPS (バージョン履歴/説明/日付を含む) をリポジトリーに公開し、マイナーバージョン番号を更新することにより、利用者および検証者に本CP/CPSの改訂を通知する。

本CP/CPSは、CAによって適宜改訂され、本委員会の承認を得て発効される。

9.12.2 Notification mechanism and period

9.12.2 通知方法および期間

本CP/CPSが改訂/修正された場合、改訂後の本CP/CPS (バージョン履歴/説明/日付を含む) がリポジトリーにすみやかに公開されることをもって、利用者および検証者への通知とみなす。利用者は、当該通知後 1 週間以内に請求を行うことができるが、当該期間内に請求が行われない場合、本CP/CPSの改訂後のバージョンは利用者により承認されたものとみなされる。本CP/CPSが変更された場合は、改訂後のCP/CPSがすみやかに公開されることをもって、関係者への通知とみなす。

9.12.3 Circumstances under which OID must be changed

9.12.3 OIDが変更されなければならない要件

本委員会が必要と判断した場合、OID は変更されるものとする。

9.13 Dispute resolution provisions

9.13 紛争解決手続

CAが発行した証明書に関する紛争の解決のため、CAに対して訴訟を提起し、仲裁を請求し、その他の法的措置を取ろうとする当事者は、事前にその旨をCAに通知するものとする。仲裁および裁判手続きの場所については、東京に所在する紛争解決機関が専属管轄権を有するものとする。

9.14 Governing law

9.14 準拠法

CA、利用者、または検証者の所在地に関わらず、本CP/CPSの解釈または有効性に関する紛争については日本の法律が適用される。仲裁および裁判手続きの場所については、当事者は東京にある紛争解決機関の専属管轄権に従う。

9.15 Compliance with applicable law

9.15 適用法の遵守

CAは、日本の関連輸出規制に従って暗号ハードウェアおよびソフトウェアを取り扱うものとする。

9.16 Miscellaneous provisions

9.16 雑則

9.16.1 Entire agreement

9.16.1 完全合意条項

セコムトラストシステムズは、本サービスの提供にあたり、利用者および検証者の義務およびその他の関連事項を本CP/CPSおよびサービス規約に包括的に規定する。口頭または書面によるその他の合意は、いかなる効力も有しないものとする。

9.16.2 Assignment

9.16.2 権利譲渡条項

セコムトラストシステムズは、サービスを第三者に譲渡する場合、本CP/CPSおよびサービス規約に規定される責任およびその他の義務を譲渡することができる。

9.16.3 Severability

9.16.3 分離条項

本CP/CPS、サービス規約のいずれかの規定が無効と判断された場合でも、そこに規定されているその他の規定はすべて完全に効力を維持する。

Section 1.1.1 Standards, Criteria and Regulations と、CAが運用または証明書を発行する法域の法律、規制、または政府命令 (以下、「法律」) との間に矛盾がある場合、CAは、その法域で要件を有効かつ合法にするために必要な最小限の範囲で、矛盾する Section 1.1.1 Standards, Criteria and Regulations を修正することができる (MAY)。これは、その法律の対象となる運用または証明書の発行にのみ適用される。このような場合、CAは、修正された要件に基づいて証明書を発行する前に、CAのCP/CPSの Section 9.16.3 に、この section に基づいてS/MIME Baseline Requirements の修正を要求する法律への詳細な参照およびCAによって実装された S/MIME Baseline Requirements への具体的な修正を直ちに盛り込むものとする (SHALL)。

また、CAは (修正された要件に基づいて証明書を発行する前に)、CP/CPSに新しく追加された関連情報をCA/ブラウザフォーラムに通知しなければならない (MUST)。通知するには、questions [at] cabforum [dot] org にメッセージを送信し、その情報がパブリックメーリングリストに投稿され、https://cabforum.org/pipermail/public/ (またはフォーラムが指定するその他のEmailアドレスとリンク) で利用可能なパブリックメールアーカイブにインデックス登録されたことの確認を受け取る。これにより、CA/ブラウザフォーラムは、それに応じて S/MIME Baseline Requirements の可能な改訂を検討できる。

本セクションに基づいて可能になったCAの慣行に対する変更は、法律が適用されなくなった場合、またはS/MIME Baseline Requirements が修正されてS/MIME Baseline Requirements と法律の両方に同時に準拠できるようになった場合には、中止しなければならない (MUST)。適切な慣行の変更、CAのCP/CPSの修正および CA/ブラウザフォーラムへの通知は、上記で概説したように、90 日以内に行わなければならない (MUST)。

9.16.4 Enforcement (attorneys' fees and waiver of rights)

9.16.4 強制執行条項

本サービスに関する紛争は東京地方裁判所を管轄裁判所とするものとし、セコムトラストシステムズは、各規制文書の契約条項から生じる紛争、当事者の行為に関連する損害、損失、費用について、当事者に対し、賠償金および弁護士費用を請求できるものとする。

9.16.5 Force Majeure

9.16.5 不可抗力条項

セコムトラストシステムズは、予見可能か否かを問わず、自然災害、地震、噴火、火災、津波、洪水、落雷、騒乱、テロ行為、その他不可抗力により生じた損害について一切責任を負わないものとする。本CAの提供が不可能となった場合、セコムトラストシステムズは、その事態が収束するまで本CAの提供を停止することがある。

9.17 Other provisions

9.17 その他条項

規定しない。

APPENDIX A – CAA Contact Tag

付録 A – CAA連絡先タグ

これらの方法により、ドメイン所有者はドメイン制御を検証する目的で DNS に連絡先情報を公開できる。

A.1. CAA Methods

A.1 CAAメソッド

A.1.1. CAA contactemail Property

A.1.1 contactemail プロパティ

SYNTAX: contactemail <rfc6532emailaddress>

CAA contactemail プロパティは、Emailアドレスをパラメーターとして受け取る。パラメーター値全体は、RFC 6532 のSection 3.2 で定義されている有効なEmailアドレスでなければならず (MUST)、追加のパディングや構造は含まれない。そうでない場合、使用できない。

以下は、ドメインの所有者がEmailアドレスを使用して連絡先プロパティを指定した例である。

$ORIGIN example.com.
               CAA 0 contactemail "domainowner@example.com"

ドメイン所有者が、contactemail プロパティを理解していないCAがドメインの証明書を発行することを望まない場合、contactemail プロパティは重要になる可能性がある (MAY)。

A.2. DNS TXT Methods

A.2 DNS TXT メソッド

A.2.1. DNS TXT Record Email Contact

A.2.1 DNS TXT Record Email連絡先

DNS TXT レコードは、検証対象のドメインの「_validation-contactemail」サブドメインに配置しなければならない (MUST)。この TXT レコードの RDATA 値全体は、RFC 6532 のSection 3.2 で定義されている有効なEmailアドレスでなければならず (MUST)、追加のパディングや構造は含まれない。そうでない場合、使用できない。

APPENDIX B – Certificate profile

付録 B – 証明書プロファイル

Table : "Security Communication RootCA2" and Subordinate CAs

Root CA 証明書 SHA256 フィンガープリント: 513B2CECB810D4CDE5DD85391ADFC6C2DD60D87BB736D2B521484AA47A0EBEF6

Table : "Security Communication RootCA3" and Subordinate CAs

Root CA 証明書 SHA256 フィンガープリント: 24A55C2AB051442D0617766541239A4AD032D7C55175AA34FFDE2FBC4F5C5294

Table : "SECOM RSA Root CA 2023" and Subordinate CAs

Root CA 証明書 SHA256 フィンガープリント: 2C154235528D701790B675AFF6E1970827B10ED665E913835BF46E3460FD5C84

Table : "SECOM Document Signing RSA Root CA 2023" and Subordinate CAs

Root CA 証明書 SHA256 フィンガープリント: 46219BBF9148F00E8B7A4C619B57CF7602701FF81348400718870FABD31FC5BE

Table : "SECOM SMIME RSA Root CA 2024" and Subordinate CA

Root CA 証明書 SHA256 フィンガープリント: 3629E7188E00A7CB3232C4426BC84912F1218B1A9AE676C0B0ABE1DBFE2182B5

Table : Subscriber Certificates (Client Authentication Certificate and Document Signing Certificates)

表：利用者証明書（クライアント認証証明書およびドキュメントサイニング証明書）

Table : Subscriber Certificates (Code Signing Certificates, Not be issued after 2024-05-01)

表：利用者証明書（コードサイニング証明書：2024年5月1日以降発行しない）

Table: Subscriber Certificates (AATL Document Signing Certificates)

表：利用者証明書（AATLドキュメントサイニング証明書）

Table: Subscriber Certificates (S/MIME Certificates)

表：利用者証明書（S/MIME証明書）

このプロファイルは、S/MIME Baseline Requirements strict mailbox-validated profile {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) smime-baseline(5) mailbox-validated (1) strict (3)} (2.23.140.1.5.1.3) に準拠している。

Table: Security Communication RootCA2 TSA, TA Certificates (Issued before 2018-09-26)

表： Security Communication RootCA2 から発行する TSA・TA証明書（2018年9月26日以前）

Table: Security Communication RootCA3 TSA, TA Certificates (Issued before 2018-09-26)

表： Security Communication RootCA3 から発行する TSA・TA証明書（2018年9月26日以降）

Table: Security Communication RootCA3 TimeStamping Subordinate CA Certificates (Issued after 2018-06-07)

表： Security Communication RootCA3 から発行する タイムスタンプ下位CA証明書（2018年6月7日以降）

Table: SECOM TimeStamping CA2 TSA, TA Certificates

表： SECOM TimeStamping CA2 から発行する TSA・TA証明書

Table: SECOM TimeStamping CA3 TSA, TA Certificates

表： SECOM TimeStamping CA3 から発行する TSA・TA証明書

Table: SECOM TimeStamping CA4 TSA Certificates (Not issued after 2025-04-15)

表： SECOM TimeStamping CA4 から発行する TSA証明書（2025年4月15日以降発行しない）

Table: SECOM TimeStamping Service TSA Certificates

表： SECOM TimeStamping Service TSA証明書