**JPRSサーバー証明書**

**認証局証明書ポリシー/認証局運用規程**

**（Certificate Policy/Certification Practice Statement）**

**Version 2.11**

2026年3月31日

株式会社日本レジストリサービス

<table>
<colgroup>
<col style="width: 12%" />
<col style="width: 17%" />
<col style="width: 69%" />
</colgroup>
<thead>
<tr>
<th colspan="3" style="text-align: center;">改版履歴</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: center;">版数</td>
<td style="text-align: center;">日付</td>
<td style="text-align: center;">内容</td>
</tr>
<tr>
<td style="text-align: center;">1.00</td>
<td style="text-align: center;">2019.06.17</td>
<td style="text-align: left;">初版発行</td>
</tr>
<tr>
<td style="text-align: center;">1.10</td>
<td style="text-align: center;">2020.04.01</td>
<td style="text-align: left;">Mozilla Root Store Policy(v2.7)への準拠に伴う改訂</td>
</tr>
<tr>
<td style="text-align: center;">1.11</td>
<td style="text-align: center;">2021.04.01</td>
<td style="text-align: left;">表紙の日付及びVersionを更新</td>
</tr>
<tr>
<td style="text-align: center;">1.12</td>
<td style="text-align: center;">2022.04.01</td>
<td style="text-align: left;">表紙の日付及びVersionを更新</td>
</tr>
<tr>
<td style="text-align: center;">1.20</td>
<td style="text-align: center;">2022.09.30</td>
<td style="text-align: left;">「6.3.2 私有鍵および公開鍵の有効期間」のタイトル変更および現状に合わせて記述を追加・修正</td>
</tr>
<tr>
<td style="text-align: center;">1.30</td>
<td style="text-align: center;">2023.06.08</td>
<td style="text-align: left;">Baseline Requirementsへの準拠に関する記述の修正</td>
</tr>
<tr>
<td style="text-align: center;">1.40</td>
<td style="text-align: center;">2023.08.28</td>
<td style="text-align: left;"><p>Baseline Requirementsの各要件への準拠を明確にするた</p>
<p>め記述見直し</p></td>
</tr>
<tr>
<td style="text-align: center;">1.50</td>
<td style="text-align: center;">2024.02.22</td>
<td style="text-align: left;">Baseline Requirementsの正式名称に関する記述の修正</td>
</tr>
<tr>
<td style="text-align: center;">1.51</td>
<td style="text-align: center;">2024.06.05</td>
<td style="text-align: left;">「1.6 定義と略語」の修正</td>
</tr>
<tr>
<td style="text-align: center;">1.52</td>
<td style="text-align: center;">2024.08.26</td>
<td style="text-align: left;">「5.4 監査ログの手続」の修正</td>
</tr>
<tr>
<td style="text-align: center;">1.53</td>
<td style="text-align: center;">2024.11.07</td>
<td style="text-align: left;">「6.1.1 鍵ペアの生成」、「8.4 監査で扱われる事項」を更新</td>
</tr>
<tr>
<td style="text-align: center;">1.54</td>
<td style="text-align: center;">2025.05.20</td>
<td style="text-align: left;">「5.4.1 記録されるイベントの種類」、「8.7 内部監査」を更新</td>
</tr>
<tr>
<td style="text-align: center;">2.00</td>
<td style="text-align: center;">2025.08.22</td>
<td style="text-align: left;"><p>CPS Version 1.54とCP Version 3.80を統合し、本CP/CPS Version 2.00として改訂</p>
<p>Baseline Requirementsの各要件への準拠を明確にするた</p>
<p>め記述見直し</p></td>
</tr>
<tr>
<td style="text-align: center;">2.10</td>
<td style="text-align: center;">2025.11.28</td>
<td style="text-align: left;">「1.6 定義と略語」、「3.2.2.4 ドメイン名の認証」、「3.2.2.8 CAAレコード」、「4.2.1 本人性確認と認証の実施」、「5.7.1 事故および危殆化時の手続」、「6.3.2 証明書の有効期間と私有鍵および公開鍵の有効期間」、「6.7 ネットワークセキュリティ管理」、「8.6 監査結果の開示」を更新</td>
</tr>
<tr>
<td style="text-align: center;">2.11</td>
<td style="text-align: center;">2026.03.31</td>
<td style="text-align: left;">「1.1 概要」、「1.6 定義と略語」、「3.2.2.4 ドメイン名の認証」、「4.2.2 証明書申請の承認または却下」を更新</td>
</tr>
</tbody>
</table>

# 目次

- [目次](#目次)
- [1. はじめに](#1-はじめに)
  - [1.1 概要](#11-概要)
  - [1.2 文書名と識別](#12-文書名と識別)
  - [1.3 PKI の関係者](#13-pki-の関係者)
    - [1.3.1 CA](#131-ca)
    - [1.3.2 RA](#132-ra)
    - [1.3.3 証明書利用者](#133-証明書利用者)
    - [1.3.4 検証者](#134-検証者)
    - [1.3.5 その他関係者](#135-その他関係者)
  - [1.4 証明書の用途](#14-証明書の用途)
    - [1.4.1 適切な証明書の用途](#141-適切な証明書の用途)
    - [1.4.2 禁止される証明書の用途](#142-禁止される証明書の用途)
  - [1.5 ポリシー管理](#15-ポリシー管理)
    - [1.5.1 文書を管理する組織](#151-文書を管理する組織)
    - [1.5.2 連絡先](#152-連絡先)
    - [1.5.3 ポリシー適合性を決定する者](#153-ポリシー適合性を決定する者)
    - [1.5.4 承認手続](#154-承認手続)
  - [1.6 定義と略語](#16-定義と略語)
- [2. 公開とリポジトリの責任](#2-公開とリポジトリの責任)
  - [2.1 リポジトリ](#21-リポジトリ)
  - [2.2 情報の公開](#22-情報の公開)
  - [2.3 公開の時期または頻度](#23-公開の時期または頻度)
  - [2.4 リポジトリへのアクセス管理](#24-リポジトリへのアクセス管理)
- [3. 識別と認証](#3-識別と認証)
  - [3.1 名前決定](#31-名前決定)
    - [3.1.1 名前の種類](#311-名前の種類)
    - [3.1.2 名前が意味を持つことの必要性](#312-名前が意味を持つことの必要性)
    - [3.1.3 証明書利用者の匿名性または仮名性](#313-証明書利用者の匿名性または仮名性)
    - [3.1.4 様々な名前形式を解釈するための規則](#314-様々な名前形式を解釈するための規則)
    - [3.1.5 名前の一意性](#315-名前の一意性)
    - [3.1.6 商標の認識、認証および役割](#316-商標の認識認証および役割)
  - [3.2 初回の本人性確認](#32-初回の本人性確認)
    - [3.2.1 私有鍵の所持を証明する方法](#321-私有鍵の所持を証明する方法)
    - [3.2.2 組織とドメイン名の認証](#322-組織とドメイン名の認証)
      - [3.2.2.1 組織の認証](#3221-組織の認証)
      - [3.2.2.2 DBA/Tradename（屋号）](#3222-dbatradename屋号)
      - [3.2.2.3 Countryの確認](#3223-countryの確認)
      - [3.2.2.4 ドメイン名の認証](#3224-ドメイン名の認証)
        - [3.2.2.4.1 Validating the Applicant as a Domain Contact](#32241-validating-the-applicant-as-a-domain-contact)
        - [3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact](#32242-email-fax-sms-or-postal-mail-to-domain-contact)
        - [3.2.2.4.3 Phone Contact with Domain Contact](#32243-phone-contact-with-domain-contact)
        - [3.2.2.4.4 Constructed Email to Domain Contact](#32244-constructed-email-to-domain-contact)
        - [3.2.2.4.5 Domain Authorization Document](#32245-domain-authorization-document)
        - [3.2.2.4.6 Agreed-Upon Change to Website](#32246-agreed-upon-change-to-website)
        - [3.2.2.4.7 DNS Change](#32247-dns-change)
        - [3.2.2.4.8 IP Address](#32248-ip-address)
        - [3.2.2.4.9 Test Certificate](#32249-test-certificate)
        - [3.2.2.4.10 TLS Using a Random Value](#322410-tls-using-a-random-value)
        - [3.2.2.4.11 Any Other Method](#322411-any-other-method)
        - [3.2.2.4.12 Validating Applicant as a Domain Contact](#322412-validating-applicant-as-a-domain-contact)
        - [3.2.2.4.13 Email to DNS CAA Contact](#322413-email-to-dns-caa-contact)
        - [3.2.2.4.14 Email to DNS TXT Contact](#322414-email-to-dns-txt-contact)
        - [3.2.2.4.15 Phone Contact with Domain Contact](#322415-phone-contact-with-domain-contact)
        - [3.2.2.4.16 Phone Contact with DNS TXT Record Phone Contact](#322416-phone-contact-with-dns-txt-record-phone-contact)
        - [3.2.2.4.17 Phone Contact with DNS CAA Phone Contact](#322417-phone-contact-with-dns-caa-phone-contact)
        - [3.2.2.4.18 Agreed-Upon Change to Website v2](#322418-agreed-upon-change-to-website-v2)
        - [3.2.2.4.19 Agreed-Upon Change to Website - ACME](#322419-agreed-upon-change-to-website---acme)
        - [3.2.2.4.20 TLS Using ALPN](#322420-tls-using-alpn)
        - [3.2.2.4.21 DNS Labeled with Account ID - ACME](#322421-dns-labeled-with-account-id---acme)
        - [3.2.2.4.22 DNS TXT Record with Persistent Value](#322422-dns-txt-record-with-persistent-value)
      - [3.2.2.5 IPアドレスの認証](#3225-ipアドレスの認証)
      - [3.2.2.6 ワイルドカードドメイン名の認証](#3226-ワイルドカードドメイン名の認証)
      - [3.2.2.7 データ情報源の正確性](#3227-データ情報源の正確性)
      - [3.2.2.8 CAAレコード](#3228-caaレコード)
      - [3.2.2.8.1 CAAレコードのDNSSEC検証](#32281-caaレコードのdnssec検証)
      - [3.2.2.9 Multi-Perspective Issuance Corroboration](#3229-multi-perspective-issuance-corroboration)
    - [3.2.3 個人の認証](#323-個人の認証)
    - [3.2.4 検証されない証明書利用者の情報](#324-検証されない証明書利用者の情報)
    - [3.2.5 権限の正当性確認](#325-権限の正当性確認)
    - [3.2.6 相互運用の基準](#326-相互運用の基準)
  - [3.3 鍵更新申請時の本人性確認と認証](#33-鍵更新申請時の本人性確認と認証)
    - [3.3.1 通常の鍵更新時における本人性確認と認証](#331-通常の鍵更新時における本人性確認と認証)
    - [3.3.2 証明書失効後の鍵更新時における本人性確認と認証](#332-証明書失効後の鍵更新時における本人性確認と認証)
  - [3.4 失効申請時の本人性確認と認証](#34-失効申請時の本人性確認と認証)
- [4. 証明書のライフサイクルに対する運用上の要件](#4-証明書のライフサイクルに対する運用上の要件)
  - [4.1 証明書申請](#41-証明書申請)
    - [4.1.1 証明書申請を提出することができる者](#411-証明書申請を提出することができる者)
    - [4.1.2 申請手続および責任](#412-申請手続および責任)
  - [4.2 証明書申請手続](#42-証明書申請手続)
    - [4.2.1 本人性確認と認証の実施](#421-本人性確認と認証の実施)
    - [4.2.2 証明書申請の承認または却下](#422-証明書申請の承認または却下)
    - [4.2.3 証明書申請の処理時間](#423-証明書申請の処理時間)
    - [4.2.4 CAAレコードの確認](#424-caaレコードの確認)
  - [4.3 証明書の発行](#43-証明書の発行)
    - [4.3.1 証明書発行時の処理手続](#431-証明書発行時の処理手続)
      - [4.3.1.1 ルート CA の証明書発行の手動承認](#4311-ルート-ca-の証明書発行の手動承認)
      - [4.3.1.2 署名前の証明書のリンティング](#4312-署名前の証明書のリンティング)
      - [4.3.1.3 発行済み証明書のリンティング](#4313-発行済み証明書のリンティング)
    - [4.3.2 証明書利用者への証明書発行通知](#432-証明書利用者への証明書発行通知)
  - [4.4 証明書の受領確認](#44-証明書の受領確認)
    - [4.4.1 証明書の受領確認手続](#441-証明書の受領確認手続)
    - [4.4.2 認証局による証明書の公開](#442-認証局による証明書の公開)
    - [4.4.3 他のエンティティに対する認証局の証明書発行通知](#443-他のエンティティに対する認証局の証明書発行通知)
  - [4.5 鍵ペアおよび証明書の用途](#45-鍵ペアおよび証明書の用途)
    - [4.5.1 証明書利用者の私有鍵および証明書の用途](#451-証明書利用者の私有鍵および証明書の用途)
    - [4.5.2 検証者の公開鍵および証明書の用途](#452-検証者の公開鍵および証明書の用途)
  - [4.6 鍵更新を伴わない証明書の更新](#46-鍵更新を伴わない証明書の更新)
    - [4.6.1 鍵更新を伴わない証明書の更新事由](#461-鍵更新を伴わない証明書の更新事由)
    - [4.6.2 証明書の更新申請を行うことができる者](#462-証明書の更新申請を行うことができる者)
    - [4.6.3 証明書の更新申請の処理手続](#463-証明書の更新申請の処理手続)
    - [4.6.4 証明書利用者に対する新しい証明書発行通知](#464-証明書利用者に対する新しい証明書発行通知)
    - [4.6.5 更新された証明書の受領確認手続](#465-更新された証明書の受領確認手続)
    - [4.6.6 認証局による更新された証明書の公開](#466-認証局による更新された証明書の公開)
    - [4.6.7 他のエンティティに対する認証局の証明書発行通知](#467-他のエンティティに対する認証局の証明書発行通知)
  - [4.7 鍵更新を伴う証明書の更新](#47-鍵更新を伴う証明書の更新)
    - [4.7.1 鍵更新を伴う証明書の更新事由](#471-鍵更新を伴う証明書の更新事由)
    - [4.7.2 新しい証明書の申請を行うことができる者](#472-新しい証明書の申請を行うことができる者)
    - [4.7.3 鍵更新を伴う証明書の更新申請の処理手続](#473-鍵更新を伴う証明書の更新申請の処理手続)
    - [4.7.4 証明書利用者に対する新しい証明書の通知](#474-証明書利用者に対する新しい証明書の通知)
    - [4.7.5 鍵更新された証明書の受領確認手続](#475-鍵更新された証明書の受領確認手続)
    - [4.7.6 認証局による鍵更新済みの証明書の公開](#476-認証局による鍵更新済みの証明書の公開)
    - [4.7.7 他のエンティティに対する認証局の証明書発行通知](#477-他のエンティティに対する認証局の証明書発行通知)
  - [4.8 証明書の変更](#48-証明書の変更)
    - [4.8.1 証明書の変更事由](#481-証明書の変更事由)
    - [4.8.2 証明書の変更申請を行うことができる者](#482-証明書の変更申請を行うことができる者)
    - [4.8.3 証明書の変更申請の処理手続](#483-証明書の変更申請の処理手続)
    - [4.8.4 証明書利用者に対する新しい証明書発行通知](#484-証明書利用者に対する新しい証明書発行通知)
    - [4.8.5 変更された証明書の受領確認手続](#485-変更された証明書の受領確認手続)
    - [4.8.6 認証局による変更された証明書の公開](#486-認証局による変更された証明書の公開)
    - [4.8.7 他のエンティティに対する認証局の証明書発行通知](#487-他のエンティティに対する認証局の証明書発行通知)
  - [4.9 証明書の失効と一時停止](#49-証明書の失効と一時停止)
    - [4.9.1 証明書失効事由](#491-証明書失効事由)
    - [4.9.2 証明書失効を申請することができる者](#492-証明書失効を申請することができる者)
    - [4.9.3 失効申請手続](#493-失効申請手続)
    - [4.9.4 失効申請の猶予期間](#494-失効申請の猶予期間)
    - [4.9.5 認証局が失効申請を処理しなければならない期間](#495-認証局が失効申請を処理しなければならない期間)
    - [4.9.6 失効調査の要求](#496-失効調査の要求)
    - [4.9.7 証明書失効リストの発行頻度](#497-証明書失効リストの発行頻度)
    - [4.9.8 証明書失効リストの発行最大遅延時間](#498-証明書失効リストの発行最大遅延時間)
    - [4.9.9 オンラインでの失効/ステータス確認の利用可能性](#499-オンラインでの失効ステータス確認の利用可能性)
    - [4.9.10 オンラインでの失効/ステータス確認を行うための要件](#4910-オンラインでの失効ステータス確認を行うための要件)
    - [4.9.11 利用可能な失効情報の他の形式](#4911-利用可能な失効情報の他の形式)
    - [4.9.12 鍵の危殆化に対する特別要件](#4912-鍵の危殆化に対する特別要件)
    - [4.9.13 証明書の一時停止事由](#4913-証明書の一時停止事由)
    - [4.9.14 証明書の一時停止を申請することができる者](#4914-証明書の一時停止を申請することができる者)
    - [4.9.15 証明書の一時停止申請手続](#4915-証明書の一時停止申請手続)
    - [4.9.16 一時停止を継続することができる期間](#4916-一時停止を継続することができる期間)
  - [4.10 証明書のステータス確認サービス](#410-証明書のステータス確認サービス)
    - [4.10.1 運用上の特徴](#4101-運用上の特徴)
    - [4.10.2 サービスの利用可能性](#4102-サービスの利用可能性)
    - [4.10.3 オプショナルな仕様](#4103-オプショナルな仕様)
  - [4.11 加入（登録）の終了](#411-加入登録の終了)
  - [4.12 キーエスクローと鍵回復](#412-キーエスクローと鍵回復)
    - [4.12.1 キーエスクローと鍵回復ポリシーおよび実施](#4121-キーエスクローと鍵回復ポリシーおよび実施)
    - [4.12.2 セッションキーのカプセル化と鍵回復のポリシーおよび実施](#4122-セッションキーのカプセル化と鍵回復のポリシーおよび実施)
- [5. 設備上、運営上、運用上の管理](#5-設備上運営上運用上の管理)
  - [5.1 物理的セキュリティ管理](#51-物理的セキュリティ管理)
    - [5.1.1 立地場所および構造](#511-立地場所および構造)
    - [5.1.2 物理的アクセス](#512-物理的アクセス)
    - [5.1.3 電源および空調](#513-電源および空調)
    - [5.1.4 水害対策](#514-水害対策)
    - [5.1.5 火災対策](#515-火災対策)
    - [5.1.6 媒体保管](#516-媒体保管)
    - [5.1.7 廃棄処理](#517-廃棄処理)
    - [5.1.8 オフサイトバックアップ](#518-オフサイトバックアップ)
  - [5.2 手続的管理](#52-手続的管理)
    - [5.2.1 信頼される役割](#521-信頼される役割)
    - [5.2.2 職務ごとに必要とされる人数](#522-職務ごとに必要とされる人数)
    - [5.2.3 個々の役割に対する本人性確認と認証](#523-個々の役割に対する本人性確認と認証)
    - [5.2.4 職務分割が必要となる役割](#524-職務分割が必要となる役割)
  - [5.3 人事的管理](#53-人事的管理)
    - [5.3.1 資格、経験および身分証明の要件](#531-資格経験および身分証明の要件)
    - [5.3.2 適性調査](#532-適性調査)
    - [5.3.3 教育要件](#533-教育要件)
    - [5.3.4 再教育の頻度および要件](#534-再教育の頻度および要件)
    - [5.3.5 仕事のローテーションの頻度および順序](#535-仕事のローテーションの頻度および順序)
    - [5.3.6 認められていない行動に対する制裁](#536-認められていない行動に対する制裁)
    - [5.3.7 業務委託先の管理](#537-業務委託先の管理)
    - [5.3.8 要員へ提供される資料](#538-要員へ提供される資料)
  - [5.4 監査ログの手続](#54-監査ログの手続)
    - [5.4.1 記録されるイベントの種類](#541-記録されるイベントの種類)
      - [5.4.1.1 ルーターおよびファイアウォールのアクティビティのログ](#5411-ルーターおよびファイアウォールのアクティビティのログ)
    - [5.4.2 監査ログを処理する頻度　](#542-監査ログを処理する頻度)
    - [5.4.3 監査ログを保持する期間](#543-監査ログを保持する期間)
    - [5.4.4 監査ログの保護](#544-監査ログの保護)
    - [5.4.5 監査ログのバックアップ手続](#545-監査ログのバックアップ手続)
    - [5.4.6 監査ログの収集システム](#546-監査ログの収集システム)
    - [5.4.7 イベントを起こした者への通知](#547-イベントを起こした者への通知)
    - [5.4.8 脆弱性評価](#548-脆弱性評価)
  - [5.5 記録の保管](#55-記録の保管)
    - [5.5.1 アーカイブの種類](#551-アーカイブの種類)
    - [5.5.2 アーカイブ保存期間](#552-アーカイブ保存期間)
    - [5.5.3 アーカイブの保護](#553-アーカイブの保護)
    - [5.5.4 アーカイブのバックアップ手続](#554-アーカイブのバックアップ手続)
    - [5.5.5 記録にタイムスタンプを付与する要件](#555-記録にタイムスタンプを付与する要件)
    - [5.5.6 アーカイブ収集システム](#556-アーカイブ収集システム)
    - [5.5.7 アーカイブの検証手続](#557-アーカイブの検証手続)
  - [5.6 鍵の切り替え](#56-鍵の切り替え)
  - [5.7 危殆化および災害からの復旧](#57-危殆化および災害からの復旧)
    - [5.7.1 事故および危殆化時の手続](#571-事故および危殆化時の手続)
      - [5.7.1.1 インシデント対応および災害復旧計画](#5711-インシデント対応および災害復旧計画)
      - [5.7.1.2 大量失効計画](#5712-大量失効計画)
    - [5.7.2 ハードウェア、ソフトウェアまたはデータが破損した場合の手続](#572-ハードウェアソフトウェアまたはデータが破損した場合の手続)
    - [5.7.3 私有鍵が危殆化した場合の手続](#573-私有鍵が危殆化した場合の手続)
    - [5.7.4 災害後の事業継続性](#574-災害後の事業継続性)
  - [5.8 認証局または登録局の終了](#58-認証局または登録局の終了)
- [6. 技術的セキュリティ管理](#6-技術的セキュリティ管理)
  - [6.1 鍵ペアの生成およびインストール](#61-鍵ペアの生成およびインストール)
    - [6.1.1 鍵ペアの生成](#611-鍵ペアの生成)
    - [6.1.2 証明書利用者に対する私有鍵の交付](#612-証明書利用者に対する私有鍵の交付)
    - [6.1.3 認証局への公開鍵の交付](#613-認証局への公開鍵の交付)
    - [6.1.4 検証者へのCA公開鍵の交付](#614-検証者へのca公開鍵の交付)
    - [6.1.5 鍵サイズ](#615-鍵サイズ)
    - [6.1.6 公開鍵のパラメータの生成および品質検査](#616-公開鍵のパラメータの生成および品質検査)
    - [6.1.7 鍵の用途　](#617-鍵の用途)
  - [](#)
  - [6.2 私有鍵の保護および暗号モジュール技術の管理](#62-私有鍵の保護および暗号モジュール技術の管理)
    - [6.2.1 暗号モジュールの標準および管理](#621-暗号モジュールの標準および管理)
    - [6.2.2 私有鍵の複数人管理](#622-私有鍵の複数人管理)
    - [6.2.3 私有鍵のエスクロー](#623-私有鍵のエスクロー)
    - [6.2.4 私有鍵のバックアップ](#624-私有鍵のバックアップ)
    - [6.2.5 私有鍵のアーカイブ](#625-私有鍵のアーカイブ)
    - [6.2.6 私有鍵の暗号モジュールへのまたは暗号モジュールからの転送](#626-私有鍵の暗号モジュールへのまたは暗号モジュールからの転送)
    - [6.2.7 暗号モジュールへの私有鍵の格納](#627-暗号モジュールへの私有鍵の格納)
    - [6.2.8 私有鍵の活性化方法](#628-私有鍵の活性化方法)
    - [6.2.9 私有鍵の非活性化方法](#629-私有鍵の非活性化方法)
    - [6.2.10 私有鍵の破棄方法](#6210-私有鍵の破棄方法)
    - [6.2.11 暗号モジュールの評価](#6211-暗号モジュールの評価)
  - [6.3 鍵ペアのその他の管理方法](#63-鍵ペアのその他の管理方法)
    - [6.3.1 公開鍵のアーカイブ](#631-公開鍵のアーカイブ)
    - [6.3.2 証明書の有効期間と私有鍵および公開鍵の有効期間](#632-証明書の有効期間と私有鍵および公開鍵の有効期間)
  - [6.4 活性化データ](#64-活性化データ)
    - [6.4.1 活性化データの生成および設定](#641-活性化データの生成および設定)
    - [6.4.2 活性化データの保護](#642-活性化データの保護)
    - [6.4.3 活性化データの他の考慮点](#643-活性化データの他の考慮点)
  - [6.5 コンピュータのセキュリティ管理](#65-コンピュータのセキュリティ管理)
    - [6.5.1 コンピュータセキュリティに関する技術的要件](#651-コンピュータセキュリティに関する技術的要件)
    - [6.5.2 コンピュータセキュリティ評価](#652-コンピュータセキュリティ評価)
  - [6.6 ライフサイクルの技術的管理](#66-ライフサイクルの技術的管理)
    - [6.6.1 システム開発管理](#661-システム開発管理)
    - [6.6.2 セキュリティ運用管理](#662-セキュリティ運用管理)
    - [6.6.3 ライフサイクルセキュリティ管理](#663-ライフサイクルセキュリティ管理)
  - [6.7 ネットワークセキュリティ管理](#67-ネットワークセキュリティ管理)
  - [6.8 タイムスタンプ](#68-タイムスタンプ)
- [7. 証明書および証明書失効リストのプロファイル](#7-証明書および証明書失効リストのプロファイル)
  - [7.1 証明書のプロファイル](#71-証明書のプロファイル)
    - [7.1.1 バージョン番号](#711-バージョン番号)
    - [7.1.2 証明書の内容と拡張](#712-証明書の内容と拡張)
    - [7.1.3 アルゴリズムオブジェクト識別子](#713-アルゴリズムオブジェクト識別子)
    - [7.1.4 名前形式](#714-名前形式)
    - [7.1.5 名前制約](#715-名前制約)
    - [7.1.6 証明書ポリシーオブジェクト識別子](#716-証明書ポリシーオブジェクト識別子)
    - [7.1.7 ポリシー制約拡張の使用](#717-ポリシー制約拡張の使用)
    - [7.1.8 ポリシー修飾子の構文および意味](#718-ポリシー修飾子の構文および意味)
    - [7.1.9 クリティカルな証明書ポリシー拡張に対する解釈の方法](#719-クリティカルな証明書ポリシー拡張に対する解釈の方法)
  - [7.2 CRLのプロファイル](#72-crlのプロファイル)
    - [7.2.1 バージョン番号](#721-バージョン番号)
    - [7.2.2 CRLとCRLエントリー拡張](#722-crlとcrlエントリー拡張)
  - [7.3 OCSPのプロファイル](#73-ocspのプロファイル)
    - [7.3.1 バージョン番号](#731-バージョン番号)
    - [7.3.2 OCSP拡張](#732-ocsp拡張)
- [8. 準拠性監査と他の評価](#8-準拠性監査と他の評価)
  - [8.1 監査の頻度](#81-監査の頻度)
  - [8.2 監査者の身元／資格](#82-監査者の身元資格)
  - [8.3 監査者と被監査者の関係](#83-監査者と被監査者の関係)
  - [8.4 監査で扱われる事項](#84-監査で扱われる事項)
  - [8.5 不備の結果としてとられる処置](#85-不備の結果としてとられる処置)
  - [8.6 監査結果の開示](#86-監査結果の開示)
  - [8.7 内部監査](#87-内部監査)
- [9. 他の業務上および法的事項](#9-他の業務上および法的事項)
  - [9.1 料金](#91-料金)
    - [9.1.1 証明書の発行/更新手数料](#911-証明書の発行更新手数料)
    - [9.1.2 証明書アクセス料金](#912-証明書アクセス料金)
    - [9.1.3 失効またはステータス情報アクセス料金](#913-失効またはステータス情報アクセス料金)
    - [9.1.4 その他のサービス料金](#914-その他のサービス料金)
    - [9.1.5 返金ポリシー](#915-返金ポリシー)
  - [9.2 財務的責任](#92-財務的責任)
    - [9.2.1 保険適用範囲](#921-保険適用範囲)
    - [9.2.2 その他の資産](#922-その他の資産)
    - [9.2.3 エンドエンティティに対する保険または保証範囲](#923-エンドエンティティに対する保険または保証範囲)
  - [9.3 企業情報の機密性](#93-企業情報の機密性)
    - [9.3.1 機密情報の範囲](#931-機密情報の範囲)
    - [9.3.2 機密情報の範囲外の情報](#932-機密情報の範囲外の情報)
    - [9.3.3 機密情報を保護する責任](#933-機密情報を保護する責任)
  - [9.4 個人情報の保護](#94-個人情報の保護)
    - [9.4.1 個人情報保護プラン](#941-個人情報保護プラン)
    - [9.4.2 個人情報として扱われる情報](#942-個人情報として扱われる情報)
    - [9.4.3 個人情報とみなされない情報](#943-個人情報とみなされない情報)
    - [9.4.4 個人情報の保護責任](#944-個人情報の保護責任)
    - [9.4.5 個人情報利用に関する通知と同意](#945-個人情報利用に関する通知と同意)
    - [9.4.6 司法または行政手続に基づく情報開示](#946-司法または行政手続に基づく情報開示)
    - [9.4.7 その他の情報開示要件](#947-その他の情報開示要件)
  - [9.5 知的財産権](#95-知的財産権)
  - [9.6 表明保証](#96-表明保証)
    - [9.6.1 CA業務の表明保証](#961-ca業務の表明保証)
    - [9.6.2 RA業務の表明保証](#962-ra業務の表明保証)
    - [9.6.3 証明書利用者の表明保証](#963-証明書利用者の表明保証)
    - [9.6.4 検証者の表明保証](#964-検証者の表明保証)
    - [9.6.5 その他関係者の表明保証](#965-その他関係者の表明保証)
  - [9.7 無保証](#97-無保証)
  - [9.8 責任の制限](#98-責任の制限)
  - [9.9 補償](#99-補償)
  - [9.10 有効期間と終了](#910-有効期間と終了)
    - [9.10.1 有効期間](#9101-有効期間)
    - [9.10.2 終了](#9102-終了)
    - [9.10.3 終了の効果と効果継続](#9103-終了の効果と効果継続)
  - [9.11 関係者間の個別通知と連絡](#911-関係者間の個別通知と連絡)
  - [9.12 改訂](#912-改訂)
    - [9.12.1 改訂手続](#9121-改訂手続)
    - [9.12.2 通知方法および期間](#9122-通知方法および期間)
    - [9.12.3 オブジェクト識別子が変更されなければならない場合](#9123-オブジェクト識別子が変更されなければならない場合)
  - [9.13 紛争解決手続](#913-紛争解決手続)
  - [9.14 準拠法](#914-準拠法)
  - [9.15 適用法の遵守](#915-適用法の遵守)
  - [9.16 雑則](#916-雑則)
    - [9.16.1 完全合意条項](#9161-完全合意条項)
    - [9.16.2 権利譲渡条項](#9162-権利譲渡条項)
    - [9.16.3 分離条項](#9163-分離条項)
    - [9.16.4 強制執行条項](#9164-強制執行条項)
    - [9.16.5 不可抗力条項](#9165-不可抗力条項)
  - [9.17 その他の条項](#917-その他の条項)

# 1. はじめに

## 1.1 概要

JPRSサーバー証明書認証局証明書ポリシー/認証局運用規程（以下「本CP/CPS」という）は、JPRSサーバー証明書発行サービス（以下「本サービス」という）を提供するために、株式会社日本レジストリサービス（以下「当社」という）が認証局（以下「本CA」という）として発行する電子証明書の用途、利用目的、適用範囲等、電子証明書に関するポリシー、および当社が構築する本CAの運用と維持に関する諸手続を規定した文書である。

本CAは、セコムトラストシステムズ株式会社（以下「セコムトラストシステムズ」という）が運営する認証局であるSecurity Communication RootCA2、Security Communication ECC RootCA1またはSECOM TLS RSA Root CA 2024より、片方向相互認証証明書の発行を受けており、証明書利用者に対する証明書発行を行う。

本CAが発行する証明書は、サーバー認証および通信経路で情報の暗号化を行うことに利用する。また、発行対象は、「JPRSサーバー証明書発行サービスご利用条件」および「JPRSサーバー証明書発行サービス ACME対応版ご利用条件」（以下併せて「ご利用条件」という）により定める。

本CAから証明書の発行を受ける者は、証明書の発行を受ける前に自己の利用目的とご利用条件および本CP/CPSとを照らし合わせて評価し、ご利用条件および本CP/CPSを承諾する必要がある。

本CAは、CA/Browser Forumが https://www.cabforum.org/ で公開する「Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates」（以下「Baseline Requirements」という）およびアプリケーションソフトウェアサプライヤーの規準の最新版に準拠する。

表1.1 規準一覧

<table>
<colgroup>
<col style="width: 42%" />
<col style="width: 57%" />
</colgroup>
<thead>
<tr>
<th style="text-align: center;">本CAが発行する証明書種類</th>
<th style="text-align: center;">準拠するべき規準</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: center;">TLSサーバー証明書</td>
<td><ul>
<li><p>Baseline Requirements for the Issuance and Management of Publicly‐Trusted TLS Server Certificates</p></li>
<li><p>Apple Root Certificate Program</p></li>
<li><p>Chrome Root Program Policy</p></li>
<li><p>Microsoft Trusted Root Program</p></li>
<li><p>Mozilla Root Store Policy</p></li>
<li><p>CCADB Policy</p></li>
</ul></td>
</tr>
</tbody>
</table>

なお、本CP/CPSとご利用条件の内容に矛盾がある場合は、ご利用条件が本CP/CPSに優先して適用される。また、本CP/CPSの日本語版と[英語版](https://jprs.jp/pubcert/info/repository/JPRS-CPCPS-en.pdf)の内容に矛盾がある場合は、[英語版](https://jprs.jp/pubcert/info/repository/JPRS-CPCPS-en.pdf)が日本語版に優先して適用される。本サービスに関して当社の定める規定とBaseline Requirementsの間に矛盾がある場合、Baseline Requirementsが当社の定める規定に優先して適用される。

本CP/CPSは、IETFが認証局運用のフレームワークとして提唱するRFC 3647「Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework」に準拠している。

本CP/CPSは、本CAおよび認証業務に関する技術面、運用面、サービス面の発展や改良に伴い、それらを反映するために必要に応じ改訂されるものとする。

## 1.2 文書名と識別

本CP/CPSの正式名称は、「JPRSサーバー証明書認証局証明書ポリシー/認証局運用規程」という。

本CAが本CP/CPSに基づき割り当て、証明書を発行する際に使用するオブジェクト識別子（以下「OID」という）は、次のとおりである。

| 名称                                    | OID                     |
|-----------------------------------------|-------------------------|
| JPRS サーバー証明書認証局証明書ポリシー | 1.3.6.1.4.1.53827.1.1.4 |

##  1.3 PKI の関係者

### 1.3.1 CA

証明書の発行、失効、失効情報の開示、OCSP（Online Certificate Status Protocol）サーバーによる証明書ステータス情報の提供および保管、CA私有鍵の生成・保護および証明書利用者の登録等を行う主体のことをいう。

### 1.3.2 RA

CAの業務のうち、証明書の発行、取消を申請する申請者の実在性確認、本人性確認の審査、証明書発行に必要な情報の登録、CAに対する証明書発行要求等を行う主体のことをいう。RAは、本CAが担う。

### 1.3.3 証明書利用者

証明書利用者とは、本CAより証明書の発行を受け、発行された証明書を利用する個人、法人または組織とする。また、本CAが証明書利用者に対して発行した証明書を、「利用者向け証明書」とする。

### 1.3.4 検証者

検証者とは、本CAにより発行された証明書の有効性を検証する個人、法人または組織とする。

### 1.3.5 その他関係者

規定しない。

## 1.4 証明書の用途

### 1.4.1 適切な証明書の用途

本CAが発行する証明書は、サーバー認証および通信経路で情報の暗号化を行うことに利用する。

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

本CAが発行する証明書の用途は本CP/CPS「1.4.1 適切な証明書の用途」のとおりであり、証明書をそれ以外の目的に利用することはできないものとする。

## 1.5 ポリシー管理

### 1.5.1 文書を管理する組織

本CP/CPSの維持、管理は、本CAが行う。

### 1.5.2 連絡先

本CP/CPSに関する連絡先は、次のとおりである。

窓口：株式会社日本レジストリサービス お問い合わせ窓口

住所：〒101-0065 東京都千代田区西神田3-8-1 千代田ファーストビル東館

電子メール：info@jprs.jp

なお、本CAが発行した証明書について私有鍵の危殆化や不正利用などが発覚した場合の連絡は、以下のWebフォームより行うものとする。

　https://jprs.jp/pubcert/f_mail/

### 1.5.3 ポリシー適合性を決定する者

本CP/CPSの内容については、本CAのサーバー証明書発行サービス運営会議において決定される。

### 1.5.4 承認手続

本CP/CPSは、本CAのサーバー証明書発行サービス運営会議の承認によって発効する。

## 1.6 定義と略語

<u>ACME（Automated Certificate Management Environment）</u>

証明書の発行や審査などに関するプロセスを自動化するためのプロトコルのことをいう。本プロトコルはRFC 8555で規定されている。

<u>Archive ： アーカイブ</u>

法的またはその他の事由により、履歴の保存を目的に取得する情報のことをいう。

<u>Audit Log ： 監査ログ</u>

認証局システムへのアクセスや不正操作の有無を検査するために記録される認証局システムの動作履歴やアクセス履歴等をいう。

<u>Authorization Domain Name ： 認証ドメイン名</u>

特定のFQDNに対して、証明書発行のための認証を取得するために使用されるドメイン

名のことをいう。本CAはDNS CNAMEルックアップから返されたFQDNをドメイン名の認証の目的でFQDNとして使用することができる。FQDNにワイルドカード文字が含まれている場合、本CAは要求されたFQDNの左端部分からすべてのワイルドカードラベルを削除する必要がある。本CAはベースドメイン名に遭遇するまで、左から右へ0個以上のラベルを削除し、中間の値のいずれかをドメイン名の認証に使用することができる。

<u>CA（Certification Authority）：認証局</u>

証明書の発行・更新・失効、失効情報の開示、OCSP（Online Certificate Status Protocol）サーバーによる証明書ステータス情報の提供および保管、CA私有鍵の生成・保護および証明書利用者の登録等を行う主体のことをいう。

<u>CAA (Certificate Authority Authorization)</u>

ドメインを使用する権限において、DNSレコードの中にドメインに対して証明書を発行できる認証局情報を記述し、意図しない認証局からの証明書誤発行を防ぐ機能のことをいう。本機能はRFC 8659で規定されている。

<u>CP（Certificate Policy）：証明書ポリシー</u>

CAが発行する証明書の種類、発行対象、用途、申込手続、発行基準等、証明書に関する事項を規定する文書のことをいう。

<u>CPS（Certification Practices Statement）：認証局運用規程</u>

CAを運用する上での諸手続、セキュリティ基準等、CAの運用を規定する文書のことをいう。

<u>CRL（Certificate Revocation List）：証明書失効リスト</u>

証明書の有効期間中に、証明書記載内容の変更、私有鍵の危殆化等の事由により失効された証明書情報が記載されたリストのことをいう。

<u>CT（Certificate Transparency）</u>

RFC 6962で規定された、発行された証明書の情報を監視・監査するためにログサーバー（CTログサーバー）に証明書の情報を登録し、公開する仕組みのことをいう。

<u>Digital Certificates ： 電子証明書</u>

ある公開鍵を、記載された者が保有することを証明する電子データのことをいう。CAが電子署名を施すことで、その正当性が保証される。

<u>DNS TXT Record Email Contact</u>

Baseline RequirementsのAppendix A.2.1項で定義される、「\_validation-contactemail」ラベルを前置きしたFQDNのDNSゾーンにおけるTXTリソースレコードに含まれるメールアドレスのことをいう。

<u>ECDSA（Elliptic Curve Digital Signature Algorithm）</u>

公開鍵暗号方式として普及している最も標準的な暗号技術のひとつである。

<u>Escrow ： エスクロー</u>

第三者に預けること（寄託）をいう。

<u>FIPS140-2</u>

米国NIST（National Institute of Standards and Technology）が策定した暗号モジュールに関するセキュリティ認定基準のことをいう。最低レベル１から最高レベル4まで定義されている。

<u>FQDN（Fully-Qualified Domain Name）：完全修飾ドメイン名</u>

インターネットドメイン名システムにおけるすべての上位ノードのラベルを含むドメイン名のことをいう。

<u>HSM（Hardware Security Module）</u>

私有鍵の生成、保管、利用などにおいて、セキュリティを確保する目的で使用する耐タンパー機能を備えた暗号装置のことをいう。

<u>JPRS Partners ： 指定事業者</u>

当社が提供するサーバー証明書発行サービスに関して、当社の認定する事業者のことをいう。

<u>Key Pair ： 鍵ペア</u>

公開鍵暗号方式において、私有鍵と公開鍵から構成される鍵の対のことをいう。

<u>Linting：リンティング</u>

事前証明書（RFC 6962）、証明書、CRL、OCSP レスポンスなどの電子署名されたデータの内容、またはRFC5280の4.1.1.1項に記述されているtbs証明書などの今後署名されるデータオブジェクトの内容が、Baseline Requirementsに定義されるプロファイルおよび要件に準拠しているか確認するプロセスのことをいう。

<u>Multi-Perspective Issuance Corroboration（MPIC）</u>

証明書発行前に、プライマリー・ネットワーク・パースペクティブによるドメイン名の認証およびCAA チェックで行われた確認が、他のネットワーク・パースペクティブによって裏付けされるプロセスのことをいう。

<u>Network Perspective：ネットワーク・パースペクティブ</u>

Multi-Perspective Issuance Corroborationに関連する。ドメイン名利用権の認証方法またはCAAチェックに関連するアウトバウンド・インターネット・トラフィックを送信するためのシステム（例えば、クラウド・ホスト・サーバー・インスタンス）またはネットワーク・コンポーネントの集合体（例えば、VPNおよび対応するインフラストラクチャ）のことをいう。ネットワーク・パースペクティブの場所は、カプセル化されていないアウトバウンド・インターネット・トラフィックが、そのパースペクティブへのインターネット接続を提供するネットワークインフラストラクチャに最初に引き渡される通常のポイントによって決定される。

<u>NTP（Network Time Protocol）</u>

コンピュータの内部時計を、ネットワークを介して正しく調整するプロトコルのことをいう。

<u>OCSP（Online Certificate Status Protocol）</u>

証明書のステータス情報をリアルタイムに提供するプロトコルのことをいう。

<u>OID（Object Identifier）：オブジェクト識別子</u>

ネットワークの相互接続性やサービス等の一意性を維持管理するための枠組みであり、国際的な登録機関に登録された、世界中のネットワーク間で一意となる数字のことをいう。

<u>PKI（Public Key Infrastructure）：公開鍵基盤</u>

電子署名、暗号化、認証といったセキュリティ技術を実現するための、公開鍵暗号方式という暗号技術を用いる基盤のことをいう。

<u>Primary Network Perspective：プライマリー・ネットワーク・パースペクティブ</u>

CAが、1)申請されたドメインまたは IP アドレスに証明書を発行する CA の権限、および、2)申請されたドメイン名または IP アドレスに対する申請者の権限またはドメイン名の利用権を判断する際に使用するネットワーク・パースペクティブをいう。

<u>Private Key ： 私有鍵</u>

公開鍵暗号方式において用いられる鍵ペアの一方をいい、公開鍵に対応する本人のみが保有する鍵のことをいう。「秘密鍵」ともいう。

<u>Public Key ： 公開鍵</u>

公開鍵暗号方式において用いられる鍵ペアの一方をいい、私有鍵に対応し、通信相手の相手方に公開される鍵のことをいう。

<u>RA（登録局）（Registration Authority）：登録機関</u>

CAの業務のうち、証明書の発行、取消を申請する申請者の実在性確認、本人性確認の審査、証明書発行に必要な情報の登録、CAに対する証明書発行要求等を行う主体のことをいう。

<u>Random Value ： ランダム値</u>

本CAが申請者に指定した、少なくとも112ビットのエントロピーを示す値のことをいう。

<u>Repository ： リポジトリ</u>

CA証明書およびCRL等を格納し公表するデータベースのことをいう。

<u>RFC 3647（Request For Comments 3647）</u>

インターネットに関する技術の標準を定める団体であるIETF（Internet Engineering Task Force）が発行する文書であり、CP/CPSのフレームワークを規定した文書のことをいう。

<u>RFC 5280（Request For Comments 5280）</u>

インターネットに関する技術の標準を定める団体であるIETF（Internet Engineering Task Force）が発行する文書であり、公開鍵基盤について規定した文書のことをいう。

<u>RSA</u>

公開鍵暗号方式として普及している最も標準的な暗号技術のひとつである。

<u>SHA-1（Secure Hash Algorithm 1）</u>

電子署名に使われるハッシュ関数（要約関数）のひとつである。ハッシュ関数とは、与えられた原文から固定長のビット列を生成する演算手法をいう。

ビット長は160ビット。データの送信側と受信側でハッシュ値を比較することで、通信途中で原文が改ざんされていないかを検出することができる。

<u>SHA-256（Secure Hash Algorithm 256）</u>

電子署名に使われるハッシュ関数（要約関数）のひとつである。ビット長は256ビット。データの送信側と受信側でハッシュ値を比較することで、通信途中で原文が改ざんされていないかを検出することができる。

<u>Subject ： 主体者</u>

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

<u>Subject Identity Information ： 主体者識別情報</u>

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

<u>Time Stamp ： タイムスタンプ</u>

電子ファイルの作成日時やシステムが処理を実行した日時等を記録したデータのことをいう。

<u>Top-Level Domain： トップレベルドメイン</u>

RFC 8499 (https://tools.ietf.org/html/rfc8499) より: 「トップレベルドメインは、"com"や"jp"等のように、ルートの一つ下のレイヤーに位置するゾーンである。」

<u>Wildcard Certificate ： ワイルドカード証明書</u>

Subject Alt Name拡張領域内に少なくともひとつのワイルドカードドメイン名を含む証明書のことをいう。

<u>Wildcard Domain Name ： ワイルドカードドメイン名</u>

”\*.” (U+002A ASTERISK, U+002E FULL STOP)で始まる文字列の直後にFQDNが続く文字列のことをいう。

# 2. 公開とリポジトリの責任

## 2.1 リポジトリ

本CAは、リポジトリを24時間365日利用できるように維持管理を行う。ただし、利用可能な時間内においてもシステム保守等により利用できない場合がある。

## 2.2 情報の公開

本CAは、CRLおよび本CP/CPSをリポジトリ上に公開し、証明書利用者および検証者がオンラインによって閲覧できるようにする。

## 2.3 公開の時期または頻度

本CP/CPSは、少なくとも365日に1回改訂するものとし、改訂の都度、リポジトリ上に公開する。本CP/CPSには、Baseline Requirementsの最新バージョンをどのように履行するか詳細に規定するものとする。CRLの発行頻度は、「4.9.7 証明書失効リストの発行頻度」に規定する。

## 2.4 リポジトリへのアクセス管理

本CAは、リポジトリでの公開情報に関して、特段のアクセスコントロールは行わない。証明書利用者および検証者は、本CAのCRLを、リポジトリを通じて入手することを可能とする。リポジトリへのアクセスは、一般的なWebインターフェースを通じて可能とする。

# 3. 識別と認証

## 3.1 名前決定

### 3.1.1 名前の種類

本CAが発行する証明書に記載される証明書利用者の名前は、X.500シリーズ（ITU-T(国際電気通信連合/電気通信標準化部門)が発行する勧告）の識別名規定に従い設定する。

### 3.1.2 名前が意味を持つことの必要性

本CAが発行する証明書に含まれる情報項目とその意味は、「7.1.1 サーバー証明書プロファイル」に規定する。

### 3.1.3 証明書利用者の匿名性または仮名性

本CAが発行する証明書のコモンネームには、匿名や仮名での登録は行わないものとする。

### 3.1.4 様々な名前形式を解釈するための規則

様々な名前の形式を解釈する規則は、X.500シリーズの識別名規定に従う。

### 3.1.5 名前の一意性

本CAが発行する証明書に記載される識別名(DN)の属性は、発行対象となるサーバーに対して一意なものとする。

### 3.1.6 商標の認識、認証および役割

本CAは、証明書申請に記載される名称について知的財産権を有しているかどうかの検証を行わない。証明書利用者は、第三者の登録商標や関連する名称を、本CAに申請してはならない。本CAは、登録商標等を理由に証明書利用者と第三者間で紛争が起こった場合、仲裁や紛争解決は行わない。また、本CAは紛争を理由に証明書利用者からの証明書申請の拒絶や発行された証明書の失効をする権利を有する。

## 3.2 初回の本人性確認

### 3.2.1 私有鍵の所持を証明する方法

証明書利用者が私有鍵を所持していることの証明は、証明書発行要求（以下「CSR」という）の署名の検証を行い、当該CSRが、公開鍵に対応する私有鍵で署名されていることを確認することで行う。

### 3.2.2 組織とドメイン名の認証

本CAは、本項に基づき依拠するすべての書類について、改ざんまたは偽造がないか検査する。

#### 3.2.2.1 組織の認証

（1）ドメイン認証型

本CAは、組織の実在性を確認しない。

（2）組織認証型

本CAは、国や地方公共団体が発行する公的書類、国や地方公共団体のWebページもしくはそのデータベース、または本CAが信頼する第三者による調査もしくはそのデータベースを用いて組織の実在性確認を行う。

#### 3.2.2.2 DBA/Tradename（屋号）

本CAが発行する証明書の情報項目「Organization（組織名）」にDBA/Tradenameを記載する場合は、「3.2.2.1 組織の認証（2）組織認証型」と同様の確認を行う。

#### 3.2.2.3 Countryの確認

本CAが発行する証明書の情報項目「Country（国）」については、「3.2.2.1 組織の認証」と同様の確認を行う。

#### 3.2.2.4 ドメイン名の認証

本CAは、証明書を発行する前に、以下に示す少なくとも一つの方法で、発行する証明書のSubject Alt Name拡張領域内に含めるすべてのFQDNを認証する。

本項のサブセクション3.2.2.4.1項から3.2.2.4.21項は、Baseline Requirementsにおけるセクション番号に対応する。

本CAでは、「RFC 7686 - The ".onion" Special-Use Domain Name」によるFQDNが証明書に含まれている場合、証明書を発行しない。

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

- RFC 4035 Section 5で定義されるアルゴリズムを使用してDNSSEC検証を実施すること

- RFC 5155で定義されるNSEC3をサポートすること

- RFC 4509およびRFC 5702で定義されるSHA-2をサポートすること

- RFC 6840 Section 4に列挙されているセキュリティ上の懸念事項を適切に処理すること

本CP/CPSの3.2.2.4.4項および3.2.2.4.14項に記載されているメールによるドメイン名の認証方法において、本CAはプライマリー・ネットワーク・パースペクティブによるドメイン名の認証または管理権限の検証に関連する認証ドメイン名を取得しようとするすべてのDNS CNAME、CAA、TXTクエリに対して、IANA DNSSEC RootトラストアンカーまでのDNSSEC検証を実施し、また本CAはDNSSEC検証を無効化するためにローカルポリシーを使用しない。その他のDNSクエリにおいても、本CAはIANA DNSSEC RootトラストアンカーまでのDNSSEC検証を実施するものとし、また本CAはDNSSEC検証を無効化するためにローカルポリシーを使用しない。

その他のすべてのドメイン名の認証方法において、本CAはプライマリー・ネットワーク・パースペクティブによるドメイン名の認証または管理権限の検証に関連するすべてのDNSクエリに対して、IANA DNSSEC RootトラストアンカーまでのDNSSEC検証を実施し、また本CAはドメイン名の認証または管理権限の検証に関連するDNSクエリに対してDNSSEC検証を無効化するためにローカルポリシーを使用しない。

IANA DNSSEC RootトラストアンカーまでのDNSSEC検証は、本CP/CPS「8.7 内部監査」の要件を満たすために実施される内部監査の対象外とする。

IANA DNSSEC RootトラストアンカーまでのDNSSEC検証は、本CP/CPS「5.4.1 記録されるイベントの種類」のログ要件の対象外とする。

本CAは、すべてのドメイン名の認証に使用した認証方法（関連するBaseline Requirementsのバージョン番号を含む）を記録する。

##### 3.2.2.4.1 Validating the Applicant as a Domain Contact

適用外とする。

##### 3.2.2.4.2 Email, Fax, SMS, or Postal Mail to Domain Contact

ランダム値をメール送信し、そのランダム値を利用した確認応答を受け取ることによって、申請者にFQDNの利用権があることを確認する。ランダム値は、WHOISに表示されているメールアドレス宛に送信する。

本CAは、ランダム値の送信に、FAX、SMS、郵便を使用しない。

ランダム値は各メールで一意とし、その発行の時から25日以内の確認応答につき有効なものとする。

2025年7月10日以降に発行する証明書より、この方法を適用外とする。

##### 3.2.2.4.3 Phone Contact with Domain Contact

適用外とする。

##### 3.2.2.4.4 Constructed Email to Domain Contact

以下の方法で、申請者にFQDNの利用権があることを確認する。

1.  管理者を表す一般的な電子メールアドレス（※）へメールを送信する

2.  メールにはランダム値を含める

3.  そのランダム値を利用した確認応答を受け取る

ランダム値は各メールで一意とし、その発行の時から25日以内の確認応答につき有効なものとする。

※：管理者を表す一般的な電子メールアドレス

例：admin@example.jp、hostmaster@sub.example.co.jp など

- ＠の左側はadmin、administrator、webmaster、hostmaster、postmasterのいずれかとする。

- ＠の右側は以下のいずれかとする。

  - FQDNのうちレジストリに登録されているドメイン名部分（「example.jp」、「example.co.jp」など）

  - FQDNそのもの  
    （先頭ラベルが"*"（ワイルドカード）や"www"の場合は、そのラベルを取り除く。ただし、"www."がレジストリに登録されているドメイン名部分に含まれる場合は取り除かない。）

##### 3.2.2.4.5 Domain Authorization Document

適用外とする。

##### 3.2.2.4.6 Agreed-Upon Change to Website 

適用外とする。

##### 3.2.2.4.7 DNS Change 

ランダム値がアンダースコアで始まるラベルを前置きしたFQDNのDNSゾーンにおけるTXTリソースレコードが含まれていることを検証することで、申請者にFQDNの利用権があることを確認する。

「アンダースコアで始まるラベル」は、"\_acme-challenge”とする。

先頭ラベルが"\*"（ワイルドカード）の場合は、"\*"（ワイルドカード）ラベルそのものを"\_acme-challenge”ラベルに置き換える。

ランダム値は各証明書発行申請で一意とし、その発行の時から25日以内の確認応答につき有効なものとする。

本CAは、本CP/CPS「3.2.2.9 Multi-Perspective Issuance Corroboration」で規定されているとおり、Multi-Perspective Issuance Corroborationを実装する。裏付けとしてカウントされるためには、ネットワーク・パースペクティブは、プライマリー・ネットワーク・パースペクティブと同じランダム値を確認する。

##### 3.2.2.4.8 IP Address 

適用外とする。

##### 3.2.2.4.9 Test Certificate 

適用外とする。

##### 3.2.2.4.10 TLS Using a Random Value 

適用外とする。

##### 3.2.2.4.11 Any Other Method 

適用外とする。

##### 3.2.2.4.12 Validating Applicant as a Domain Contact

申請者がドメイン名の登録者であることを検証することをもって、申請者にFQDNの利用権があることを確認する。ただし、本CAをレジストリ/レジストラとするドメイン名を含むFQDNである場合に限る。

##### 3.2.2.4.13 Email to DNS CAA Contact 

適用外とする。

##### 3.2.2.4.14 Email to DNS TXT Contact 

ランダム値をメール送信し、そのランダム値を利用した確認応答を受け取ることによって、申請者にFQDNの利用権があることを確認する。ランダム値は、FQDNを認証するために選択された認証ドメイン名のDNS TXT Record Email Contact宛に送信する。

各メールは、そのメールアドレスが認証される各認証ドメイン名のDNS TXT Record Email Contactである場合、複数のFQDNの利用権を確認することができる。すべての受信者が認証される各認証ドメイン名のDNS TXT Record Email Contactである限り、同じメールを複数の受信者に送信できる。

ランダム値はそれぞれのメールに一意のものとする。メールはランダム値の再利用を含めて全体を再送できるが、全体内容と受信者が変更されないことを条件とする。ランダム値はその生成より25日以内のレスポンス確認の使用に有効とする。

2025年5月29日以降に発行する証明書より、この方法を適用対象とする。本CAは、本CP/CPS「3.2.2.9 Multi-Perspective Issuance Corroboration」で規定されているとおり、Multi-Perspective Issuance Corroborationを実装する。裏付けとしてカウントされるためには、ネットワーク・パースペクティブは、ドメイン名の認証に用いられたプライマリー・ネットワーク・パースペクティブと同じメール連絡先を確認する。

##### 3.2.2.4.15 Phone Contact with Domain Contact 

適用外とする。

##### 3.2.2.4.16 Phone Contact with DNS TXT Record Phone Contact 

適用外とする。

##### 3.2.2.4.17 Phone Contact with DNS CAA Phone Contact 

適用外とする。

##### 3.2.2.4.18 Agreed-Upon Change to Website v2

ランダム値がWebコンテンツのファイルに含まれていることを検証することをもって、申請者がFQDNを管理していることを確認する。

1.  ランダム値は、ファイルを取得する本CAによるリクエスト自体に記載しない

2.  本CAは、ファイルの取得において、成功を意味するHTTPステータスコード(2xx)を確認する。

ランダム値を含むファイルは、以下全てを満たす必要がある。

1.  FQDNをホスト名としたURI下に配置されていなければならない

2.  "/.well-known/pki-validation"ディレクトリに置かなければならない

3.  httpまたはhttpsのスキームにより取得されなければならない

4.  80 (http) もしくは、443 (https)のポートでアクセスされなければならない

本CAがリダイレクトに従いファイルを取得する場合は、以下全てを満たす必要がある。

1.  HTTPプロトコルレイヤーから開始されるリダイレクトである

    - HTTPステータスコードは以下のいずれかとする

      - 301, 302, 307（RFC 7231に規定）

      - 308（RFC 7538に規定）

    - RFC 7231の7.1.2項で定義された、Locationヘッダの"the final value"をリダイレクト先とする

2.  リダイレクトする際は、httpまたはhttpsのスキームを用いる

3.  リダイレクトする際は、80 (http) もしくは、443 (https)のポートにアクセスする

ランダム値は各証明書発行申請で一意とし、その発行の時から25日以内の確認応答につき有効なものとする。

2021年11月18日以降に発行する証明書について、ワイルドカードドメイン名の認証に対してこの方法を適用外とする。

Onionドメイン名を除き、本CAは、本 CP/CPS「3.2.2.9 Multi-Perspective Issuance Corroboration」で規定されているとおり、Multi-Perspective Issuance Corroborationを実装する。裏付けとしてカウントされるためには、ネットワーク・パースペクティブは、プライマリー・ネットワーク・パースペクティブと同じランダム値を確認する。

##### 3.2.2.4.19 Agreed-Upon Change to Website - ACME 

RFC 8555の8.3項で定義されたACME HTTP Challengeメソッドを用いて、申請者がFQDNを管理していることを確認する。以下は、RFC 8555からの追加要求である。

1.  本CAは、検証におけるリクエストに対するレスポンスとして、成功を意味するHTTPステータスコード(2xx)を確認する。

2.  ランダム値は各証明書発行申請で一意とし、その発行の時から25日以内の確認応答につき有効なものとする。

3.  本CAがリダイレクトに従いファイルを取得する場合は、以下全てを満たす必要がある。

    1.  HTTPプロトコルレイヤーから開始されるリダイレクトである

        - HTTPステータスコードは以下のいずれかとする

          - 301, 302, 307（RFC 7231に規定）

          - 308（RFC 7538に規定）

        - RFC 7231の7.1.2項で定義された、Locationヘッダの"the final value"をリダイレクト先とする

      1.  リダイレクトする際は、httpまたはhttpsのスキームを用いる

      2.  リダイレクトする際は、80 (http) もしくは、443 (https)のポートにアクセスする

ワイルドカードドメイン名の認証に対してこの方法を適用外とする。

Onionドメイン名を除き、本CAは、本CP/CPS「3.2.2.9 Multi-Perspective Issuance Corroboration」で規定されているとおり、Multi-Perspective Issuance Corroborationを実装する。裏付けとしてカウントされるためには、ネットワーク・パースペクティブは、プライマリー・ネットワーク・パースペクティブと同じランダム値を確認する。

##### 3.2.2.4.20 TLS Using ALPN 

適用外とする。

##### 3.2.2.4.21 DNS Labeled with Account ID - ACME 

適用外とする。

##### 3.2.2.4.22 DNS TXT Record with Persistent Value

適用外とする。

#### 3.2.2.5 IPアドレスの認証

本CAは、IPアドレスを認証するための証明書を発行しない。

#### 3.2.2.6 ワイルドカードドメイン名の認証

本CAは、ワイルドカード証明書を発行する前に、ワイルドカードドメイン名におけるFQDN部分が「レジストリ管理」または「パブリックサフィックス」（例: 「\* .com」、 「\* .co.uk」、詳細はRFC 6454 8.2項を参照）であるかを判断する文書化された手順を確立し履践する。

ワイルドカードドメイン名におけるFQDN部分が「レジストリ管理」または「パブリックサフィックス」である場合、本CAは、ドメイン名空間全体の正当な管理を確認できない限り、発行を拒否する（たとえば、「\* .co.uk」または「\* .local」を発行してはならないが、Example Co.に対して「\* .example.com」を発行することはできる）。

ドメイン名空間全体のうち、何が「レジストリ管理」であり、何が登録可能な国別トップレベルドメイン名空間の部分であるかの判断は、Baseline Requirementsの記載に従うものとする。

#### 3.2.2.7 データ情報源の正確性

本CAは、データ情報源を信頼できるデータ情報源として使用する前に、データ情報源の信頼性、正確性、および改ざんや偽造への耐性を評価する。本CAは、データ情報源の評価中、下記を考慮する。

1. 情報の提供時期

2. 情報源の更新頻度

3. データ提供者とデータ収集の目的

4. データの利用可能性の公開性

5. データの改ざんまたは偽造の困難性

#### 3.2.2.8 CAAレコード

発行プロセスの一部として、本CAは、RFC 8659で指定されているように、発行される証明書のSubject Alt Name拡張領域内の各dNSNameについて、CAAレコードをチェックし、見つかった処理指示に従う。本CAは発行する場合、CAAレコードのTTL(有効期限内)または8時間のうち、いずれか長い方の範囲内で発行する。

証明書に記載される対象のドメイン名に対する申請者の利用権を認証するために依拠される方法（本CP/CPS 3.2.2.4項を参照）の中には、証明書の発行前に追加のリモート・ネットワーク・パースペクティブからCAA レコードを取得して処理する必要があるものがある （本CP/CPS 3.2.2.9項 を参照）。プライマリー・ネットワーク・パースペクティブを裏付けるためには、リモート・ネットワーク・パースペクティブのCAAチェック応答は、両方のネットワーク・パースペクティブからの応答がバイト単位で同一であるか否かに関わらず、発行許可として解釈される必要がある。また、本CA は、このセクションで定義されているとおり、プライマリー・ネットワーク・パースペクティブおよびリモート・ネットワーク・パースペクティブのいずれか、またはその双方において許容可能なCAA レコード検索エラーが発生した場合は、リモート・ネットワーク・パースペクティブにより応答が裏付けられたものと見なすことができる。

CAAレコードを処理する際、本CAは、RFC 8659で指定されているとおり、issue、issuewild、およびiodefプロパティタグを処理する。 ただし、iodefプロパティタグの内容に対する処理は行わない。他のプロパティタグもサポートする場合は、Baseline Requirementsに規定されている必須プロパティタグと衝突を避け、必須プロパティタグより優先することがないようにする。

本CAはcriticalフラグを尊重し、このフラグセットを持つ不明なプロパティタグに遭遇した場合は証明書を発行しない。

本CAは、以下のすべてに該当する場合、レコードルックアップの失敗を発行許可

と扱うことができる。

・失敗がCAのインフラストラクチャ外である

・ルックアップが少なくとも1回再試行されている

・本CAが、RFC 4035 Section 4.3で定義される「Insecure」であることを確認している

本CAは、処理実務の一環として取られたアクションがあればすべてログで記録するものとする。

#### 3.2.2.8.1 CAAレコードのDNSSEC検証

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

- RFC 4035 Section 5で定義されるアルゴリズムを使用してDNSSEC検証を実施

- RFC 5155で定義されるNSEC3をサポート

- RFC 4509およびRFC 5702で定義されるSHA-2をサポート

- RFC 6840 Section 4に列挙されているセキュリティ上の懸念事項を適切に処理

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

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

本CAはMulti-Perspective Issuance Corroborationの一環として、リモート・ネットワーク・パースペクティブによって実施されるCAAレコードのルックアップに関連するすべてのDNSクエリに対して、IANA DNSSEC RootトラストアンカーまでのDNSSEC検証を実施してもよい。

IANA DNSSEC RootトラストアンカーまでのDNSSEC検証は、本CP/CPS「8.7 内部監査」の要件を満たすために実施される内部監査の対象外とする。

#### 3.2.2.9 Multi-Perspective Issuance Corroboration

2025年3月15日以降、本CAは、Baseline Requirements の3.2.2.9項に従い、Multi-Perspective Issuance Corroborationを実施する。

本CAは、証明書発行前に、複数のリモート・ネットワーク・パースペクティブによって、プライマリー・ネットワーク・パースペクティブが行う次の確認結果の裏付けを行う。

- 本CP/CPS「3.2.2.4 ドメイン名の認証」に規定されるところにより求められる以下の値の存在。

  - 1)ランダム値、2)リクエストトークン、3)コンタクトアドレス（連絡先）。

- 本CP/CPS「3.2.2.8 CAAレコード」に規定される、要求されたドメインに対して発行するCAの権限。

クォーラム要件の表はMulti-Perspective Issuance Corroborationに関するクォーラムの要件を説明したものである。本CAがドメイン名利用権とCAAレコードのチェックの両方において同じネットワーク・パースペクティブのセットを使用していない場合、両方のネットワーク・パースペクティブのセット（すなわち、ドメイン名利用権のセットとCAAレコードのチェックのセット）に対してクォーラム要件を満たす必要がある。ネットワーク・パースペクティブはそれらの間の直線距離が500km以上である場合、異なるものとみなされる。ネットワーク・パースペクティブは、プライマリー・ネットワーク・パースペクティブ及びクォーラムで表される他のネットワーク・パースペクティブとは異なる場合、「リモート」とみなされる。

本CA は、CAA レコードに関して、クォーラム要件への適合を満たすための証拠を最大398 日間再利用することができる。あるドメイン名に証明書を発行した後、リモート・ネットワーク・パースペクティブは、同じ申請者からの証明書発行申請において、同ドメイン名またはそのサブドメインに対する CAA レコードの取得および処理を最大 398 日間省略することができる。

表 3.2.2.9-1 クォーラム要件の表

| 使用されるリモート・ネットワーク・パースペクティブの数 | 許容される失敗数 |
|--------------------------------------------------------|------------------|
| 2～5                                                   | 1                |
| 6以上                                                  | 2                |

実装タイムライン

- 2025年3月15日以降、本CAは、少なくとも2つのリモート・ネットワーク・パースペクティブを使用してMulti-Perspective Issuance Corroborationを実施する。  
  本CAは、プライマリー・ネットワーク・パースペクティブが行った確認の裏付けに失敗したリモート・ネットワーク・パースペクティブの数が、クォーラム要件の表で許容される数より多い場合でも、証明書の発行を続行できるものとする。

- 2025年9月15日以降、本CAは、少なくとも5つのリモート・ネットワーク・パースペクティブを使用して、Multi-Perspective Issuance Corroborationを実施する。  
  本CA は、クォーラム要件の表の要件が満たされていること、およびプライマリー・ネットワーク・パースペクティブの裏付けを行うリモート・ネットワーク・パースペクティブが少なくとも2つの異なる地域インターネット・レジストリのサービス地域内にあることを確認する必要がある。これら要件が満たされない場合、本CA は証明書の発行を続行しない。

### 3.2.3 個人の認証

本CAは、個人を認証するための証明書を発行しない。

### 3.2.4 検証されない証明書利用者の情報

（1）ドメイン認証型

本CAは、検証されない証明書利用者の情報を規定しない。

（2）組織認証型

本CAは、検証されない証明書利用者の情報を規定しない。

### 3.2.5 権限の正当性確認

（1）ドメイン認証型

本CAは、証明書を発行する時点において、証明書利用者が証明書に記載されるドメイン名の登録者であるか、あるいはその登録者より排他的な利用権を許諾されていることを確認する。

（2）組織認証型

本CAは、証明書の申込を行う者が、その申請を行うための正当な権限を有していることを、本CP/CPS「3.2.2 組織とドメイン名の認証」で利用する書類やデータベース等で確認できる連絡先に連絡することによって確認する。

### 3.2.6 相互運用の基準

本CAは、セコムトラストシステムズが運営する認証局であるSecurity Communication RootCA2、Security Communication ECC RootCA1またはSECOM TLS RSA Root CA 2024より、片方向相互認証証明書を発行されている。

## 3.3 鍵更新申請時の本人性確認と認証

### 3.3.1 通常の鍵更新時における本人性確認と認証

鍵更新時における証明書利用者の本人性確認および認証は、本CP/CPS「3.2 初回の本人性確認」と同様とする。

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

鍵更新時における証明書利用者の本人性確認および認証は、本CP/CPS「3.2 初回の本人性確認」と同様とする。

## 3.4 失効申請時の本人性確認と認証

本CAは、次のいずれかを確認することにより失効申請時の本人性確認を行う。

1.  証明書発行申請時または本サービス利用の申込時に証明書利用者からの申請または申込を取り次いだ指定事業者を経由した失効申請であること

2.  失効申請の署名が、証明書利用者に付与したアカウントに関連付けられた秘密鍵によるものであること（ACMEプロトコルを介して発行した証明書に限る）

3.  失効申請の署名が、証明書の秘密鍵によるものであること（ACMEプロトコルを介して発行した証明書に限る）

# 4. 証明書のライフサイクルに対する運用上の要件

## 4.1 証明書申請

### 4.1.1 証明書申請を提出することができる者

（1）ドメイン認証型

証明書の申請を行うことができる者は、証明書に記載されるドメイン名の登録者であるか、あるいはその登録者より排他的な利用権を許諾されている者とする。

（2）組織認証型

証明書の申請を行うことができる者は、日本国内に住所を有する個人事業主、または日本国内に本店・主たる事務所、支店・支所、営業所その他これに準じる常設の場所を有する法人格を有しまたは法人格を有さない組織とする。

### 4.1.2 申請手続および責任

証明書の申請を行うことができる者は、証明書の申請を行うにあたり、ご利用条件および本CP/CPSの内容を承諾した上で申請を行うものとする。また、証明書の申請を行う者は、本CAに対する申請内容が正確な情報であることを保証しなければならない。

## 4.2 証明書申請手続

### 4.2.1 本人性確認と認証の実施

本CAは、本CP/CPS「3.2 初回の本人性確認」に記載の情報をもって、申請情報の審査を行う。

証明書要求には、証明書に含めるべき申請者に関するすべての事実に関する情報、および本CAがBaseline Requirements、本CAのCP/CPSに準拠するために申請者から取得する必要がある追加情報を含めてもよい。証明書要求が申請者に関する必要な情報の一部を欠いている場合、本CAは、残りの情報を申請者から取得するか、または信頼できる独立した第三者のデータ情報源から情報を取得して申請者に確認するものとする。本CAは、申請者によって証明書に含めることを要求されたすべてのデータを検証するための文書化された手順を確立し履践する。

申請者情報には、証明書のSubject Alt Name拡張領域に含まれる少なくとも1つのFQDNを含める。

本CP/CPS「6.3.2 証明書の有効期間と私有鍵および公開鍵の有効期間」では、利用者向け証明書の有効期間を制限する。

本CAは、本CP/CPS「3.2 初回の本人性確認」で提供された書類およびデータを証明書情報の認証に使用してもよく、または前回の認証結果を再利用してもよい。ただし、本CAが該当するデータまたは書類を本CP/CPS「3.2 初回の本人性確認」に記載されたソースから入手した場合、または証明書発行前の最大日数以内に自ら認証を完了している場合に限る。この最大日数は以下の表で定義されている。

表 4.2.1-1 主体者識別情報検証データ再利用期間

<table>
<colgroup>
<col style="width: 33%" />
<col style="width: 33%" />
<col style="width: 33%" />
</colgroup>
<thead>
<tr>
<th colspan="2" style="text-align: center;">証明書発行日</th>
<th style="text-align: center;">最大データ再利用期間</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: center;"></td>
<td style="text-align: center;">2026年3月15日より前</td>
<td style="text-align: center;">825日</td>
</tr>
<tr>
<td style="text-align: center;">2026年3月15日以降</td>
<td style="text-align: center;"></td>
<td style="text-align: center;">398日</td>
</tr>
</tbody>
</table>

本CP/CPS「3.2.2.4 ドメイン名の認証」に従うドメイン名に用いるデータ、書類、または完了済みの認証は、証明書発行前の最大日数以内に入手されていなければならない。この最大日数は以下の表で定義されている。

表 4.2.1-2 ドメイン名認証データ再利用期間

<table>
<colgroup>
<col style="width: 33%" />
<col style="width: 33%" />
<col style="width: 33%" />
</colgroup>
<thead>
<tr>
<th colspan="2" style="text-align: center;">証明書発行日</th>
<th style="text-align: center;">最大データ再利用期間</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: center;"></td>
<td style="text-align: center;">2026年3月15日より前</td>
<td style="text-align: center;">398日</td>
</tr>
<tr>
<td style="text-align: center;">2026年3月15日以降</td>
<td style="text-align: center;">2027年3月15日より前</td>
<td style="text-align: center;">200日</td>
</tr>
<tr>
<td style="text-align: center;">2027年3月15日以降</td>
<td style="text-align: center;">2029年3月15日より前</td>
<td style="text-align: center;">100日</td>
</tr>
<tr>
<td style="text-align: center;">2029年3月15日以降</td>
<td style="text-align: center;"></td>
<td style="text-align: center;">10日</td>
</tr>
</tbody>
</table>

いかなる場合においても、以前の認証で使用されたデータまたはドキュメントのいずれかが、証明書の発行前に、データまたはドキュメントの再利用が許可される最大時間を超えて取得されている場合、以前の認証は再利用しない。

Baseline Requirementsに規定される認証方法へ変更した後において、本CA は、Ballotにおいて特段の規定がない限り、本項に規定する期間については、変更前に収集した認証データもしくは文書または認証そのものを引き続き再利用することができる。

本CAは、ハイリスク証明書要求がBaseline Requirementsに従って適切に検証されること確保するために合理的に必要とされる、証明書の承認前にハイリスク証明書要求に対する追加の検証活動を識別し要求する、文書化された手順を作成、保持および実施するものとする。

外部委託先が本項に基づく本CAの義務のいずれかを履行する場合、本CAは外部委託先がハイリスク証明書要求を識別しさらに検証するために用いるプロセスが、本CA自身のプロセスと少なくとも同等の保証レベルを提供していることを確認しなければならない。

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

本CAは、審査の結果、承認を行った申請について証明書の発行登録を行う。

不備がある申請については、申請を却下し、申請を行った者に対し申請の再提出を依頼する。

本CAは、「.arpa」で終わるドメイン名を含む証明書を発行しない。

### 4.2.3 証明書申請の処理時間

本CAは、承認を行った申請について、適時証明書の発行登録を行う。

### 4.2.4 CAAレコードの確認

本CAは、RFC 8659に従い、申請情報の審査時にCAAレコードを確認する。CAAレコードに記載する本CAのドメイン名は「jprs.jp」または「acme.jprs.jp」とする。

FQDNに対して証明書を発行する権限を付与したい証明書利用者は、それぞれのDNS ゾーンのCAAレコードの「issue」または「issuewild」プロパティタグに以下いずれかのドメイン名を含めなければならない。

・「jprs.jp」（ACMEプロトコルを介さずに発行する証明書）

・「acme.jprs.jp」（ACMEプロトコルを介して発行する証明書）

## 4.3 証明書の発行

### 4.3.1 証明書発行時の処理手続

本CAは、証明書申請の審査を完了した後、申請された情報に基づき、第三者が運営する本CA所定のCTログサーバーに証明書発行に必要な情報を登録した上で、証明書を発行する。CTログサーバーに登録する情報は、本CP/CPS「7.1 証明書のプロファイル」に記載する。

#### 4.3.1.1 ルート CA の証明書発行の手動承認

規定しない。

#### 4.3.1.2 署名前の証明書のリンティング

本CAは、発行する証明書の一部の項目に関して、Baseline Requirements に技術的に適合しているかどうか証明書の発行前のリンティングにより確認し、要件を満たしていない場合は発行を拒否する。

#### 4.3.1.3 発行済み証明書のリンティング

本CAは、発行済み証明書をテストするため、リンティングを行うことができる。

### 4.3.2 証明書利用者への証明書発行通知

本CAは、指定事業者または証明書利用者に対し電子メールを送付することにより証明書の発行通知を行う。ただし、ACMEプロトコルを介して証明書が発行された場合は、電子メールによる発行通知は行わない。

## 4.4 証明書の受領確認

### 4.4.1 証明書の受領確認手続

次のいずれかの時点をもって、証明書が受領されたものとする。

1.  証明書利用者が、証明書利用者だけがアクセス可能なホームページから証明書取得を要求し、本CAが証明書を応答した時

2.  証明書利用者が、ACMEプロトコルを介して証明書取得を要求し、本CAが証明書を応答した時（ACMEプロトコルを介して発行された証明書に限る）

3.  証明書利用者が、上記以外の方法によって入手した証明書をサーバーに導入した時

### 4.4.2 認証局による証明書の公開

本CAは、証明書利用者の証明書の公開は行わない。

### 4.4.3 他のエンティティに対する認証局の証明書発行通知

本CAは、第三者（ただし指定事業者は除く）に対する証明書の発行通知は行わない。

## 4.5 鍵ペアおよび証明書の用途

### 4.5.1 証明書利用者の私有鍵および証明書の用途

証明書利用者は、本CAが発行する証明書および対応する私有鍵を、サーバー認証および通信経路で情報の暗号化を行うことにのみ利用するものとする。証明書利用者は、本CAが承認をした用途のみに当該証明書および対応する私有鍵を利用するものとし、その他の用途に利用してはならない。

### 4.5.2 検証者の公開鍵および証明書の用途

検証者は、本CAの証明書を使用することで、本CAが発行した証明書の信頼性を検証することができる。本CAが発行した証明書の信頼性を検証し、信頼する前に、本CP/CPSの内容について理解し、承諾しなければならない。

## 4.6 鍵更新を伴わない証明書の更新

鍵更新を伴わない証明書の更新とは、公開鍵を変更することなく、証明書利用者に新しい証明書を発行することをいう。本CAは、証明書利用者が証明書を更新する場合、新たな鍵ペアを生成することを推奨する。

### 4.6.1 鍵更新を伴わない証明書の更新事由

鍵更新を伴わない証明書の更新は、証明書の有効期間が満了する場合に行う。

### 4.6.2 証明書の更新申請を行うことができる者

本CP/CPS「4.1.1 証明書申請を提出することができる者」と同様とする。

### 4.6.3 証明書の更新申請の処理手続

本CP/CPS「4.3.1 証明書発行時の処理手続」と同様とする。

### 4.6.4 証明書利用者に対する新しい証明書発行通知

本CP/CPS「4.3.2 証明書利用者への証明書発行通知」と同様とする。

### 4.6.5 更新された証明書の受領確認手続

本CP/CPS「4.4.1 証明書の受領確認手続」と同様とする。

### 4.6.6 認証局による更新された証明書の公開

本CP/CPS「4.4.2 認証局による証明書の公開」と同様とする。

### 4.6.7 他のエンティティに対する認証局の証明書発行通知

本CP/CPS「4.4.3 他のエンティティに対する認証局の証明書発行通知」と同様とする。

## 4.7 鍵更新を伴う証明書の更新

鍵更新を伴う証明書の更新とは、新たな鍵ペアを生成した上で証明書利用者に新しい証明書を発行することをいう。

### 4.7.1 鍵更新を伴う証明書の更新事由

鍵更新を伴う証明書の更新は、証明書の有効期間が満了する場合に行う。

### 4.7.2 新しい証明書の申請を行うことができる者

本CP/CPS「4.1.1 証明書申請を提出することができる者」と同様とする。

### 4.7.3 鍵更新を伴う証明書の更新申請の処理手続

本CP/CPS「4.3.1 証明書発行時の処理手続」と同様とする。

### 4.7.4 証明書利用者に対する新しい証明書の通知

本CP/CPS「4.3.2 証明書利用者への証明書発行通知」と同様とする。

### 4.7.5 鍵更新された証明書の受領確認手続

本CP/CPS「4.4.1 証明書の受領確認手続」と同様とする。

### 4.7.6 認証局による鍵更新済みの証明書の公開

本CP/CPS「4.4.2 認証局による証明書の公開」と同様とする。

### 4.7.7 他のエンティティに対する認証局の証明書発行通知

本CP/CPS「4.4.3 他のエンティティに対する認証局の証明書発行通知」と同様とする。

## 4.8 証明書の変更

### 4.8.1 証明書の変更事由

証明書の変更は、証明書に登録された情報（証明書のコモンネームを除く）の変更が必要となった場合に行う。

### 4.8.2 証明書の変更申請を行うことができる者

本CP/CPS「4.1.1 証明書申請を提出することができる者」と同様とする。

### 4.8.3 証明書の変更申請の処理手続

本CP/CPS「4.3.1 証明書発行時の処理手続」と同様とする。

### 4.8.4 証明書利用者に対する新しい証明書発行通知

本CP/CPS「4.3.2 証明書利用者への証明書発行通知」と同様とする。

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

本CP/CPS「4.4.1 証明書の受領確認手続」と同様とする。

### 4.8.6 認証局による変更された証明書の公開

本CP/CPS「4.4.2 認証局による証明書の公開」と同様とする。

### 4.8.7 他のエンティティに対する認証局の証明書発行通知

本CP/CPS「4.4.3 他のエンティティに対する認証局の証明書発行通知」と同様とする。

## 4.9 証明書の失効と一時停止

### 4.9.1 証明書失効事由

証明書利用者は、次の事由が発生した場合、本CAに対しすみやかに証明書の失効申請を行わなければならない。

・証明書記載情報に変更があった場合

・私有鍵の盗難、紛失、漏洩、不正利用等により私有鍵が危殆化したまたは危殆化のおそれがある場合

・証明書の内容、利用目的が正しくない場合

・証明書に含まれる情報項目（本CP/CPS「3.1.1 名前の種類」で記載）に設定される値に、不適切な文字列が指定され、または含まれていることを発見した場合（組織認証型のみ）

・証明書の利用を中止する場合

本CAは、次のいずれかの事由に該当する場合に、24時間以内に証明書を失効させ、対応する失効理由コードを使用するものとする。

1. 証明書利用者が、失効理由コードを指定することなく、書面にて本CAに証明書の失効を要求した場合（CRLReason "unspecified (0)"、これにより CRL にreasonCode拡張領域が記載されない）

2. 証明書利用者が、オリジナルの証明書要求が承認されたものでなく、遡及的に承認を付与しないことを本CAに通知した場合（CRLReason \#9、privilegeWithdrawn）

3. 本CAが、証明書の公開鍵に対応する証明書利用者の私有鍵が危殆化した証拠を入手した場合（CRLReason \#1、keyCompromise）

4. 本CAが、証明書の公開鍵に基づいて証明書利用者の私有鍵を容易に計算できる実証または証明された方法を認識した場合（Baseline Requirements の6.1.1.3項 (5)および本CP/CPS「6.1.1 鍵ペアの生成」で特定されるものを含むが、これらに限定されない）（CRLReason \#1、keyCompromise）

5. 本CAが、証明書に記載されるFQDNのドメイン認証または管理の認証について、依拠すべきでないという証拠を入手した場合（CRLReason \#4、superseded）

本CAは、次のいずれか事由が発生した場合に、24時間以内に証明書を失効させることがあり、また5日以内に証明書を失効させ、対応する失効理由コードを使用するものとする。

6. 証明書がBaseline Requirementsの6.1.5項および6.1.6項の要件に適合しなくなった場合（CRLReason \#4、superseded）

7. 本CAが、証明書が不正に使用されたという証拠を入手した場合（CRLReason \#9、privilegeWithdrawn）

8. 本CAが、証明書利用者が利用契約またはご利用条件に基づく1つ以上の重大な義務に違反していることを認識した場合（CRLReason \#9、privilegeWithdrawn）；

9. 本CAが、証明書に記載されるFQDNの使用が法的に許容されなくなったこと（たとえば、裁判所または仲裁人がドメイン名登録者のドメイン名を使用する権利を取り消したこと、ドメイン名登録者と申請者間の関連するライセンス契約またはサービス契約が終了したこと、またはドメイン名登録者がドメイン名の更新を懈怠したことなど）を示す状況を認識した場合（CRLReason \#5、cessationOfOperation）

10. 本CAが、ワイルドカード証明書が、詐欺的に誤信させる下位のFQDNの認証に使用されたことを認識した場合（CRLReason \#9、privilegeWithdrawn）

11. 本CAが、証明書に含まれる情報に重大な変更があったことを認識した場合（CRLReason \#9、privilegeWithdrawn）

12. 本CAが、証明書がBaseline Requirements、本CP/CPSに従って発行されていないことを認識した場合（CRLReason \#4、superseded）

13. 本CAが、証明書に記載される情報が不正確であると判断し、または不正確であることを認識した場合（CRLReason \#9、privilegeWithdrawn）

14. Baseline Requirementsに基づき証明書を発行する本CAの権利がなくなり、または取り消され、もしくは終了された（ただし、CRL/OCSPリポジトリの管理を継続するための手配を本CAが行った場合を除く）（CRLReason "unspecified (0)" 、これによりCRLにreasonCode拡張領域が記載されない）

15. 本CP/CPSにより、Baseline Requirementsの4.9.9.1項で規定することを要しない理由で失効が要求される場合（CRLReason "unspecified (0)"、これにより、CRLにreasonCode拡張領域が記載されない）

16. 本CAが、証明書利用者の私有鍵が危殆化するような実証または証明された方法を認識し、または私有鍵の生成に使用された特定の方法に欠陥があったことの明確な証拠がある場合（CRLReason \#1、keyCompromise）

### 4.9.2 証明書失効を申請することができる者

証明書の失効の申請を行うことができる者（以下「失効申請者」という）は、次のいずれかとする。

1.  証明書利用者

2.  証明書発行申請時または本サービス利用の申込時に証明書利用者からの申請または申込を取り次いだ指定事業者

3.  証明書の秘密鍵を有する者（ACMEプロトコルを介して発行された証明書に限る）

なお、本CP/CPS「4.9.1 証明書失効事由」に該当すると本CAが判断した場合、本CAが失効申請者となる。

### 4.9.3 失効申請手続

本CAは、次のいずれかの手続によって受け付けた情報を「3.4 失効申請時の本人性確認と認証」に従って確認し、証明書の失効処理を行う。

1.  指定事業者を経由した申請

2.  ACMEプロトコルを介した申請（ACMEプロトコルを介して発行された証明書に限る）

本CAは、失効申請と証明書問題レポートを24時間365日受け付けて応答する。

### 4.9.4 失効申請の猶予期間

失効申請者は、私有鍵が危殆化したまたは危殆化のおそれがあると判断した場合には、すみやかに失効申請を行わなければならない。

### 4.9.5 認証局が失効申請を処理しなければならない期間

本CAは、有効な失効申請を受け付けてからすみやかに証明書の失効処理を行い、CRLへ当該証明書情報を反映させる。

本CAは、証明書問題レポートを受領してから24時間以内に、証明書問題レポートに関する事実と状況を調査し、証明書利用者および証明書問題レポートの報告主体に対して、調査結果についての第一次的な報告書を提供する。

本CAは、事実および状況を検討した後、証明書利用者、証明書問題レポートまたはその他の失効関連通知の報告主体と協力し、証明書が失効されるべきか否か、また、失効する場合は失効する日付を確定させる。

証明書問題レポートまたは失効関連通知の受領から証明書を失効するまでの期間は、本CP/CPS「4.9.1 証明書失効事由」に規定する期間を超えないものとする。

### 4.9.6 失効調査の要求

本CAが発行する証明書には、CRLの格納先であるURLを記載する。検証者は、本CAが発行する証明書について信頼し利用する前に、当該証明書の有効性をCRLにより確認しなければならない。なお、CRLには、有効期限の切れた証明書情報は含まれない。

### 4.9.7 証明書失効リストの発行頻度

本CA は、少なくとも 7 日に一度はCRLを更新し、再発行する。また、発行するCRLのnextUpdateフィールドの値は、 thisUpdateフィールドの値から10 日以内とする。

### 4.9.8 証明書失効リストの発行最大遅延時間

本CAは、発行したCRLを即時にリポジトリに反映させる。

### 4.9.9 オンラインでの失効/ステータス確認の利用可能性

OCSP応答の有効期間は、thisUpdateフィールドとnextUpdateフィールドの時間差（両端を含む）である。その差を算出する目的で、うるう秒を無視すると、3,600秒の差は1時間に等しいものとし、86,400秒の差は1日に等しくなる。

証明書のシリアルナンバーが「assigned」となるのは、次の場合である

- そのシリアルナンバーを持つ証明書または事前証明書 \[RFC 6962\] が発行CAによって発行されている。

- そのシリアルナンバーを持つ事前証明書が、発行CAに関連付けられた事前証明書の署名証明書\[Baseline Requirements 7.1.2.4項\]によって発行されている

証明書のシリアルナンバーは、「assigned」でない場合、「unassigned」となる。

id-ad ocsp accessMethod を使用した Authority Information Access 拡張を含む証明書および事前証明書のステータスを通信する場合は、以下が適用される。

CAが運用するOCSPレスポンダは、RFC 6960やRFC 5019 で説明されているように、HTTP GETメソッドをサポートする。CAは、RFC 8954 に従って Nonce 拡張 (1.3.6.1.5.5.7.48.1.2) を処理する場合がある。

利用者証明書または対応する事前証明書の場合、以下が適用される。

- 2025年1月15日より、証明書または事前証明書が最初に公開された、またはその他の方法で利用可能になってから 15分以内に、信頼できるOCSP応答が利用可能にならなければならない (つまり、応答者は「unknown」ステータスで応答してはならない )。

- 有効期間が16時間未満のOCSP応答の場合、CAは nextUpdate の前の有効期間半分に先立ち更新されたOCSP応答を提供する。

- 有効期間が16時間以上のOCSP応答の場合、CAは nextUpdate の少なくとも8時間前および thisUpdate の4日後までに、更新されたOCSP応答を提供する。

下位CA証明書のステータスの場合、CAは少なくとも12か月ごとおよび証明書の失効後24時間以内に更新されたOCSP 応答を提供する。

OCSPレスポンダが応答する意思がある、または応答する必要があるすべての証明書のステータスを通信するには、以下が適用される。

OCSP応答は、RFC 6960やRFC 5019 に準拠していなければならない。OCSP応答は、次のいずれかでなければならない。

1.  失効ステータスがチェックされている証明書を発行したCAによって署名されている

2.  本CP/CPS「7.1 証明書のプロファイル」$00A0のOCSPレスポンダ証明書プロファイルに準拠しているOCSPレスポンダによって署名されている

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

OCSPレスポンダが「unassigned」の証明書シリアルナンバーのステータスのリクエストを受信した場合、レスポンダは「good」ステータスで応答すべきではない。OCSPレスポンダがBaseline Requirementsの7.1.2.3項または7.1.2.5項に沿って技術的に制約されていないCA向けである場合、レスポンダはそのような要求に対して「good」ステータスで応答してはならない。

### 4.9.10 オンラインでの失効/ステータス確認を行うための要件

規定しない。

### 4.9.11 利用可能な失効情報の他の形式

適用外とする。

### 4.9.12 鍵の危殆化に対する特別要件

本CAが発行した証明書について私有鍵の危殆化が発覚した場合の連絡は、以下のWebフォームより行うものとする。

　https://jprs.jp/pubcert/f_mail/

連絡を行う際には、次のいずれかの情報を提示するものとする。

・危殆化した私有鍵

・危殆化した私有鍵によって署名されたCSR

（ただし、CNに私有鍵が危殆化したことを示す文字列が記されたCSRに限る。

例：CN="This key is compromised"）

本CAは、本CAが発行した証明書について、提示された私有鍵を利用しているものがないか確認する。

提示された私有鍵を利用する証明書を確認した場合、確認した時点から24時間以内に当該証明書を失効する。

### 4.9.13 証明書の一時停止事由

適用外とする。

### 4.9.14 証明書の一時停止を申請することができる者

適用外とする。

### 4.9.15 証明書の一時停止申請手続

適用外とする。

### 4.9.16 一時停止を継続することができる期間

適用外とする。

## 4.10 証明書のステータス確認サービス

### 4.10.1 運用上の特徴

証明書利用者および検証者はOCSPサーバーを通じて証明書ステータス情報を確認することができる。

本CAは、CRLまたはOCSPサーバーの失効エントリーを、失効した証明書の有効期限日が過ぎるまで削除しない。

### 4.10.2 サービスの利用可能性

本CAは、24時間365日、証明書ステータス情報を確認できるようOCSPサーバーを管理する。ただし、保守等により、一時的にOCSPサーバーを利用できない場合もある。

本CAは、通常の運用状況の下で10秒以内のレスポンス時間を提供するために十分なリソースで、CRLおよびOCSP機能を運用および維持するものとする。

本CAは、アプリケーションソフトウェアが、本CAによって発行されたすべての有効期限内証明書の現在のステータスを自動的にチェックするために使用できるオンラインリポジトリを24時間365日体制で維持するものとする。

本CAは、優先度の高い証明書問題レポートを内部で対応し、必要に応じて当該苦情を法執行機関に通報し、または当該苦情の対象となった証明書を失効させる能力を24時間365日維持するものとする。

### 4.10.3 オプショナルな仕様

規定しない。

## 4.11 加入（登録）の終了

証明書利用者が証明書の利用を終了する、または本サービスを解約する場合、証明書の失効申請を行わなければならない。なお、証明書の更新手続を行わず、該当する証明書の有効期間が満了した場合にも終了となる。ただし、本CAは、ACMEプロトコルを介して発行された証明書利用者について、上記と異なる取扱いをすることができる。

その他の証明書利用者による本サービスの解約に関する詳細は、ご利用条件で定める。

## 4.12 キーエスクローと鍵回復

### 4.12.1 キーエスクローと鍵回復ポリシーおよび実施

本CAは、証明書利用者の私有鍵のエスクローは行わない。

### 4.12.2 セッションキーのカプセル化と鍵回復のポリシーおよび実施

適用外とする。

# 5. 設備上、運営上、運用上の管理

CA/Browser Forumの「Network and Certificate System Security Requirements」は、参照することにより本書に完全に組み込まれる。

本CAは、以下の目的で設計された包括的なセキュリティプログラムを開発、実装、維持する。

1. 証明書データおよび証明書管理プロセスの機密性、完全性、および可用性を保護する。

2. 証明書データおよび証明書管理プロセスの機密性、完全性、および可用性にとっての潜在的な脅威または危険から保護する。

3. 証明書データおよび証明書管理プロセスに対する不正または違法なアクセス、使用、開示、改変、または破壊から保護する。

4. 証明書データおよび証明書管理プロセスの不慮の損失、破壊、または損傷から保護する。

5. 法律によって本CAに適用されるその他のセキュリティ要件すべてに準拠する。

証明書管理プロセスは、以下を含む必要がある。

1. 物理的なセキュリティ制御や環境制御。

2. 構成管理、信頼済みコードの整合性メンテナンス、マルウェア検出/防止を含む、システム整合性制御。

3. ポート制限やIPアドレスフィルタリングを含む、ネットワークセキュリティおよびファイアウォール管理。

4. ユーザー管理、信頼済みロールの分担、教育、意識向上、トレーニング。

5. 個々の責任を明確にするための論理的なアクセス制御、アクティビティロギング、およびアイドル時のタイムアウト。

本CAのセキュリティプログラムには、以下のような年次リスクアセスメントを含める必要がある。

1. 証明書データまたは証明書管理プロセスに対する不正なアクセス、開示、不正使用、改変、または破壊につながる、予測可能な内外の脅威を特定する。

2. これらの脅威がもたらす可能性があるダメージについて、証明書データや証明書管理プロセスの秘密度を考慮に入れて評価する。

3. このような脅威に対抗するために本CAが配備したポリシー、手順、情報システム、技術、その他の手配の充実度に関して評価する。

リスクアセスメントに基づき、本CAは、上述の目的を実現するべく設計されたセキュリティ手順、対策、および製品で構成されるセキュリティ計画を開発、実装、および維持し、リスクアセスメント中に識別されたリスクを、証明書データおよび証明書管理プロセスの重要度に応じて管理するものとする。セキュリティ計画には、証明書データおよび証明書管理プロセスの秘密度に適した管理上、組織的、技術的、および物理的な保護対策を含めなければならない。また、セキュリティ計画では、その時点で利用可能な技術および特定の対策の実装コストを考慮に入れなければならず、セキュリティの侵害から生じる可能性がある損害および保護対象のデータの性質に適した合理的な水準のセキュリティを実装するものとする。

## 5.1 物理的セキュリティ管理

### 5.1.1 立地場所および構造

当社は、本CAのシステムをセキュアなデータセンター内に設置する。データセンターは、水害、地震、火災、その他の災害の被害を容易に受けない場所に建設されており、かつ建物の構造上も、これら災害防止のための対策を講じている。

### 5.1.2 物理的アクセス

当社は、本CAのシステムの重要性に応じて、物理的なアクセス制御および電子的なアクセス制御を組み合わせた適切なセキュリティコントロールを構築する。また、監視カメラ、各種センサーを設置し、認証基盤システムへのアクセスを監視する。

### 5.1.3 電源および空調

データセンターでは、瞬断および長時間の停電時においても本CAのシステムの運用を可能とするために、無停電電源装置および自家発電装置による電源対策を施している。

また、本CAのシステムは、空気調和機により最適な温度、湿度を一定に保つことが可能な環境下に設置する。

### 5.1.4 水害対策

本CAは、水害対策として、本CAのシステムを建物の二階以上に設置する。また、防水対策として、本CAのシステムを設置する室には漏水検知器を設置する。

### 5.1.5 火災対策

本CAのシステムを設置する室は、防火壁によって区画された防火区画とし、火災報知機および消火設備を設置する。

### 5.1.6 媒体保管

本CAは、アーカイブデータ、バックアップデータを含む認証業務を行ううえで必要な情報を、適切な入退管理が行われた室内の保管庫に保存するとともに、毀損、滅失防止のための措置を施す。

### 5.1.7 廃棄処理

本CAは、機密情報を含む書類および電子媒体の廃棄を、情報の初期化、裁断等により行う。

### 5.1.8 オフサイトバックアップ

本CAは、本CAのシステムの運用のために必要なデータ、機器等を、遠隔地に保管するかまたは調達できる手段を講ずる。

## 5.2 手続的管理

### 5.2.1 信頼される役割

本CAのシステムの運用に関わる役割を以下に示す。

\(1\) サービス責任者

・CA全体の統括

・サービス管理者の任命

\(2\) サービス管理者

・CA業務責任者、RA業務責任者の任命

\(3\) CA業務責任者

・CA業務の統括

・CAのシステムの変更、運用手続変更の承認

\(4\) CA業務管理者

・CA業務担当者への作業指示

・CA私有鍵に関する作業立会い

・CA業務の全般管理

\(5\) CA業務担当者

・CAサーバ、リポジトリサーバ等CAのシステムの維持管理

・CA私有鍵の活性化、非活性化等の操作

\(6\) RA業務責任者

・RA業務の統括

\(7\) RA業務管理者

・RA業務担当者への作業指示

・RA業務の遂行管理

\(8\) RA業務担当者

・証明書申請における情報の検証

・証明書申請、失効要求、更新要求の承認、拒絶その他の処理

・その他、RA業務管理者の指示に基づく証明書発行審査の遂行

\(9\) ログ検査者

・入退室ログ、システムログ等の検査

### 5.2.2 職務ごとに必要とされる人数

本CAは、サービス提供に支障をきたさないよう、サービス責任者、サービス管理者、CA業務責任者、RA業務責任者を除く本CP/CPS「5.2.1.信頼される役割」に記載する役割に関し、役割ごとに1名以上の要員を配置する。なお、CA私有鍵の操作等の重要な業務については複数名の要員で行う。

なお、CA私有鍵の操作等の重要な業務については複数名の要員で行う。 CA私有鍵のバックアップ、保管、回復は、信頼される役割を持つ担当者が、少なくとも物理的に安全な環境で、二重制御を用いながら行うものとする。

### 5.2.3 個々の役割に対する本人性確認と認証

本CAは、本CAのシステムへのアクセスに関し、物理的または論理的な方法によってアクセス権限者の識別と認証、および認可された権限の操作であることを確認する。

### 5.2.4 職務分割が必要となる役割

本CP/CPS「5.2.1.信頼される役割」に記載する役割は、原則として異なる要員がその役割を担う。なお、CA業務管理者およびRA業務管理者については、ログ検査者との兼務を可能とする。

## 5.3 人事的管理

### 5.3.1 資格、経験および身分証明の要件

本CP/CPS「5.2.1.信頼される役割」に記載する役割を担う者は、当社の定めた採用基準に基づき採用された従業員等とする。

本CAのシステムを直接操作する担当者には、専門のトレーニングを受け、PKIの概要とシステムの操作方法等を理解している者を配置する。

### 5.3.2 適性調査

本CAは、本CP/CPS「5.2.1.信頼される役割」に記載する役割を担う者の信頼性と適性を任命時および定期的に評価する。

### 5.3.3 教育要件

本CP/CPS「5.2.1.信頼される役割」に記載する役割を担う者は、役割に就く前に本CAのシステムの運用に必要な教育を受け、以降、必要に応じ、役割に応じた教育・訓練を受ける。また、業務手順に変更がある場合はその変更に関わる教育・訓練を受ける。

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

本CA は、かかる訓練の記録を維持し、検証スペシャリスト業務を委託された要員が、かかる業務を十分に遂行できるスキルレベルを維持することを保証しなければならない。

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

本CA は、すべての検証スペシャリストに対し、Baseline Requirementsに概説されている情報検証要件についてCAが提供する試験に合格することを要求しなければならない。

### 5.3.4 再教育の頻度および要件

本CP/CPS「5.2.1.信頼される役割」に記載する役割を担う者は、必要に応じ再トレーニングを受ける。

信頼される役割のすべての要員は、本CAのトレーニングおよびパフォーマンスプログラムと一致したスキルレベルを維持するものとする。

### 5.3.5 仕事のローテーションの頻度および順序

本CAは、サービス品質の維持、向上および不正防止の観点から、必要に応じて要員のジョブローテーションを行う。

### 5.3.6 認められていない行動に対する制裁

就業規則に従い、処罰が課せられる。

### 5.3.7 業務委託先の管理

当社は、本CAのシステムの運用の一部を外部組織に委託する場合、業務委託先との契約によって、業務委託先のもとで運用業務が適切に行われていることを確認する。

本CA は、証明書の発行に携わる外部委託先の担当者が本 CP/CPS「5.3.3 教育要件」および に本CP/CPS「5.4.1記録されるイベントの種類」を満たしていることを検証するものとする。

### 5.3.8 要員へ提供される資料

要員は、関連する業務上必要な文書のみの閲覧をすることができる。

## 5.4 監査ログの手続

### 5.4.1 記録されるイベントの種類

本CAは、監査ログとして以下の記録を収集する。

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

    1. 鍵の生成、バックアップ、保管、回復、アーカイブ化、破棄。

    2. 証明書の要求、更新、鍵の再生成の要求、および失効

    3. 証明書要求の承認と拒否。

    4. 暗号化デバイスライフサイクル管理イベント。

    5. 証明書失効リストの生成。

    6. OCSP応答の署名。

    7. 新しい証明書プロファイルの導入と既存の証明書プロファイルの廃止。

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

    1. 証明書の要求、更新、鍵の再生成要求、および失効化。

    2. Baseline Requirementsおよび本CP/CPSで定められたすべての検証アクション。

    3. 証明書要求の承認と拒否。

    4. 証明書の発行。

    5. 証明書失効リストの生成。

    6. OCSP応答の署名。

    7. 各ネットワーク パースペクティブからのMulti-Perspective Issuance Corroborationの試行では、少なくとも次の情報を記録する。

        1. 使用されたネットワーク・パースペクティブを一意に識別する識別子。

        2. 試行されたドメイン名

        3. 試行の結果 (例:「ドメイン名の認証の合格/不合格」、「CAA の許可/禁止」)。

    8. 証明書申請試行されたドメイン名ごとのマルチ・パースペクティブ発行検証のクォーラムの結果。

3. 以下を含むセキュリティイベント

    1. 成功および失敗したPKIシステムアクセス試行。

    2. 実行されたPKIおよびセキュリティシステムアクション。

    3. セキュリティプロファイルの変更。

    4. 証明書システムへのソフトウェアのインストール、更新、および削除。

    5. システムクラッシュ、ハードウェア障害、およびその他の異常。

    6. 関連するルーターおよびファイアウォールのアクティビティ。

    7. CA 施設への出入記録。

ログ記録には、以下の要素を含める必要がある。

1. 記録の日時。

2. ジャーナルレコードを作成する人の身元。

3. 記録の詳細。

#### 5.4.1.1 ルーターおよびファイアウォールのアクティビティのログ

本CP/CPS「5.4.1 記録されるイベントの種類」3.6の要件を満たすために必要なルーターおよびファイアウォールのアクティビティのログには、少なくとも次のものを含める必要がある。

1. ルーターおよびファイアウォールへのログイン試行の成功と失敗。

2. 構成の変更、ファームウェアの更新、アクセス制御の変更を含む、ルーターおよびファイアウォール上で実行されたすべての管理アクションのログ。

3. 追加、変更、削除を含む、ファイアウォールルールに対して行われたすべての変更のログ。

4. ハードウェアの障害、ソフトウェアのクラッシュ、システムの再起動を含む、すべてのシステムのイベントとエラーのログ。

### 5.4.2 監査ログを処理する頻度　

本CAは、監査ログを定期的に確認する。

### 5.4.3 監査ログを保持する期間

本CAは、本CAのシステムに関する監査ログを、アーカイブとして最低10年保存する。入退室、ネットワークに関するログについては最低１年間保存する。

ただし、Baseline Requirements に関連する場合、本CA は、少なくとも 2 年間、以下を保持するものとする。

1. CA証明書および鍵のライフサイクル管理イベント記録（本 CP/CPS「5.4.1 記録されるイベントの種類」に記載）は、以下のいずれかが発生した後に保持する。

    1. CA 私有鍵の破壊

    2. cA フィールドが true に設定された X.509v3 basicConstraints 拡張を持ち、CA 私有鍵に対応する共通の公開鍵を共有する一連の証明書のうち、最後のCA 証明書の失効または有効期限切れ。

2. 利用者向け証明書の失効または満了後の利用者向け証明書ライフサイクル管理イベントレコード（本 CP/CPS「5.4.1 記録されるイベントの種類」に記載）。

3. イベント発生後のセキュリティイベントレコード（本CP/ CPS「5.4.1 記録されるイベントの種類」に記載）

なお、RAシステム上の監査ログについては、アーカイブとして最低7年間保存する。

### 5.4.4 監査ログの保護

本CAは、認可された者のみが監査ログにアクセスすることができるよう、適切なアクセスコントロールを採用し、許可されていない者が閲覧できないようにする。

### 5.4.5 監査ログのバックアップ手続

監査ログはオフラインの記録媒体にバックアップとして取得し、それらの媒体を安全な場所に保管する。

### 5.4.6 監査ログの収集システム

監査ログの収集システムは、本CAのシステムの機能に含まれている。

### 5.4.7 イベントを起こした者への通知

本CAは、監査ログの収集を、事象を発生させた人、システムまたはアプリケーションに対して通知することなく行う。

### 5.4.8 脆弱性評価

本CAは、監査ログの検査結果をもとに、運用面およびシステム動作面におけるセキュリティ上の脆弱性を評価するとともに、必要に応じて最新の実装可能なセキュリティテクノロジの導入等、セキュリティ対策の見直しを行う。

さらに CA のセキュリティプログラムには、以下のような年次リスクアセスメントを含める必要がある。

1. 証明書データまたは証明書管理プロセスに対する不正なアクセス、開示、不正使用、 改変、または破壊につながる、予測可能な内外の脅威を特定する。

2. 証明書データおよび証明書管理プロセスの機密性を考慮して、これらの脅威の可能性及び潜在的な損害を評価する。

3. このような脅威に対抗するために CA が導入しているポリシー、手順、情報システム、技術、およびその他の取り決めが十分であるかどうかを評価する。

## 5.5 記録の保管

### 5.5.1 アーカイブの種類

本CAは、本CP/CPS「5.4.1.記録されるイベントの種類」の本CAのシステムに関するログに加えて、次の情報をアーカイブとして保存する。

・発行した証明書およびCRL

・CRL の発行に関する処理履歴

・本CP/CPS

・本CP/CPSに基づき作成された認証局の業務運用を規定する文書

・認証業務を他に委託する場合においては、委託契約に関する書類

・監査の実施結果に関する記録および監査報告書

・証明書利用者からの申請書類

・証明書利用者からの申請情報およびその処理履歴

・OCSP レスポンダーへのアクセスログ（OCSP レスポンダーを使用しているCAの場合）

### 5.5.2 アーカイブ保存期間

本CAは、アーカイブを最低10年間保存する。

ただし、Baseline Requirements に関連する場合、アーカイブされた監査ログ（本 CP/CPS「5.5.1 アーカイブの種類」で規定）は、記録作成タイムスタンプから少なくとも2年間、または本CP/CPS「5.4.3 監査ログを保持する期間」に従って保持する必要がある限り、いずれか長い方の期間保持する。

なお、次の情報のアーカイブについては、最低7年間保存する。

・証明書利用者からの申請情報およびその処理履歴

### 5.5.3 アーカイブの保護

アーカイブは、許可された者以外がアクセスできないよう制限された施設において保管する。

### 5.5.4 アーカイブのバックアップ手続

証明書発行、取消またはCRLの発行等、本CAのシステムに関する重要なデータに変更がある場合は、適時、アーカイブのバックアップを取得する。

### 5.5.5 記録にタイムスタンプを付与する要件

本CAは、NTP（Network Time Protocol）を使用して本CAのシステムの時刻同期を行い、本CAのシステム内で記録される重要な情報に対しタイムスタンプを付与する。

### 5.5.6 アーカイブ収集システム

アーカイブの収集システムは、本CAのシステムの機能に含まれている。

### 5.5.7 アーカイブの検証手続

アーカイブは、セキュアな保管庫からアクセス権限者が入手し、定期的に媒体の保管状況の確認を行う。また必要に応じ、アーカイブの完全性および機密性の維持を目的として、新しい媒体への複製を行う。

## 5.6 鍵の切り替え

本CAの私有鍵は、私有鍵に対する証明書の有効期間が証明書利用者に発行した証明書の最大有効期間よりも短くなる前に新たな私有鍵の生成および証明書の発行を行う。新しい私有鍵が生成された後は、新しい私有鍵を使って証明書およびCRLの発行を行う。

## 5.7 危殆化および災害からの復旧

### 5.7.1 事故および危殆化時の手続

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

CA 私有鍵が危殆化または危殆化のおそれがある場合および災害等により本サービスの中断、停止につながるような状況が発生した場合には、予め定められた計画、手順に従い、安全にサービスを再開させる。

本CA は、インシデント対応計画および災害復旧計画を準備するものとする。

本CA は、災害、セキュリティの危殆化、または企業倒産が発生した場合にアプリケーションソフトウェアサプライヤー、証明書利用者、および依拠当事者に通知し、それらを合理的に保護するように設計された、事業継続および災害復旧手順を文書化するものとする。本CA は事業継続計画を公開する必要はないが、本CA の監査人が要求した時には事業継続計画とセキュリティ計画を提供できるようにするものとする。本CA は、年1回これらの手順をテスト、レビュー、および更新するものとする。

事業継続計画には以下を含めなければならない。

1. 計画を始動するための条件

2. 緊急対応手順

3. フォールバック手順

4. 再開手順

5. 計画の保守スケジュール

6. 意識向上および教育要件

7. 個人の責任範囲

8. 目標復旧時間（RTO）

9. 緊急対策計画の定期的なテスト

10. 重要な事業プロセスの中断または障害発生後、タイムリーにCAの事業運営を維持または復元するための計画

11. 重要な暗号化資材（つまり、セキュリティ保護された暗号化装置やアクティベーション資材）を代替場所に保管するための要件

12. 容認可能なシステム停止期間および回復時間

13. 必須の事業情報およびソフトウェアのバックアップコピーの作成頻度

14. 復旧施設からCAのメインサイトまでの距離

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

#### 5.7.1.2 大量失効計画

本CAは大量失効事象に備えた包括的かつ実行可能な計画を維持し、大量失効計画の年次テストを実施し、テストや実際の事象から得られた教訓を計画に反映し、継続的に対応力を向上させる。

2025年9月1日より、本CAは、Mozilla Root Store Policyの規定に従い、大量失効イベントに対処するための包括的かつ実行可能な計画を策定し、維持する。

### 5.7.2 ハードウェア、ソフトウェアまたはデータが破損した場合の手続

本CAは、本CAのシステムのハードウェア、ソフトウェアまたはデータが破損した場合、バックアップ用として保管しているハードウェア、ソフトウェアまたはデータを使用して、すみやかに本CAのシステムの復旧作業を行う。

### 5.7.3 私有鍵が危殆化した場合の手続

本CAは、本CAの私有鍵が危殆化したまたは危殆化のおそれがあると判断した場合、および災害等により本CAのシステムの運用が中断、停止につながるような状況が発生した場合には、予め定められた計画、手順に従い、安全に運用を再開させる。

### 5.7.4 災害後の事業継続性

本CAは、不測の事態が発生した場合にすみやかに復旧作業を実施できるよう、予め本CAのシステムの代替機の確保、復旧に備えたバックアップデータの確保、復旧手続の策定等、可能な限りすみやかに本CAのシステムを復旧するための対策を行う。

## 5.8 認証局または登録局の終了

本CAは、業務停止する必要がある場合、その旨を事前に本CP/CPS「9.11 関係者間の個別通知と連絡」に定められた方法で証明書利用者に通知する

# 6. 技術的セキュリティ管理

## 6.1 鍵ペアの生成およびインストール

本項について、証明書利用者を含むその他関係者に関する鍵管理および本CAの鍵管理に関して規定する。

### 6.1.1 鍵ペアの生成

本 CA の鍵ペアに対しては以下の管理を行う。

1. 鍵生成スクリプトを用意して、スクリプトに従って実施する。

2. 公認監査人に CA 鍵ペア生成プロセスに立ち会わせる、または CA 鍵ペア生成プロセス全体を録画する。

本 CA は以下を実施するものとする。

1. 本CP/CPSの内容に従って物理的に保護された環境でCA 鍵ペアを生成する。

2. 複数人物による統制および知識分割の原則に基づく信頼された役割の担当者によりCA 鍵ペアを生成する。

3. 本CP/CPSで公開されている適切な技術および事業要件を満たす暗号化モジュール内でCA 鍵ペアを生成する。本 CA の鍵ペアは FIPS140-2 レベル 3 の認定を取得したハードウェアセキュリティモジュール（Hardware Security Module：以下、「HSM」という）上で生成する。

4. CA 鍵ペア生成アクティビティをログ記録する。

5. 私有鍵が本CP/CPSおよび鍵生成スクリプトに記載されている手順に従って生成および保護されたことを合理的に保証する効果的な統制を維持する。

Baseline Requirementsに準拠した利用者向け証明書の鍵ペア生成に関しては、次の条件の1つ以上が満たされた場合、本CAは証明書要求を拒否する必要がある。

1. 鍵ペアが本CP/CPS「6.1.5 鍵サイズ」または本CP/CPS「6.1.6 公開鍵のパラメータの生成および品質検査」に記載されている要件を満たしていない。

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

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

4. 本CAは、本CP/CPS「4.9.3 失効申請手続」および本CP/CPS「4.9.12 鍵の危殆化に対する特別要件」の失効要求手続を用いて申請者の私有鍵が危殆化したことを事前に通知されている。

5. 公開鍵が、業界で実証された脆弱な私有鍵に対応している。本CAは、2024年11月15日以降の申請については、少なくとも以下の予防措置を講じる。

    1.  Debian weak keys脆弱性（ https://wiki.debian.org/SSLkeys ）の場合、本CAは、リポジトリに記載される鍵の種類（RSA、ECDSA等）およびサイズごとに https://github.com/cabforum/Debian-weak-keys/ で発見されたすべての鍵を拒否する。8192ビットを超えるRSA鍵サイズを除き、本CP/CPS「6.1.5 鍵サイズ」の要件を満たすその他の鍵について、本CAは、Debian weak keysを拒否する。

    2.  ROCA脆弱性の場合、本CAは、https://github.com/crocs-muni/roca で入手可能なツールまたは同等のツールによって識別される鍵を拒否する。

    3.  Close Primes脆弱性（ https://fermatattack.secvuln.info/ ）の場合、本CAは、フェルマーの因数分解法を用いて100ラウンド以内に因数分解できる脆弱な鍵を拒否する。

### 6.1.2 証明書利用者に対する私有鍵の交付

証明書利用者の私有鍵は、証明書利用者自身が生成するものとし、本CAは証明書利用者の私有鍵生成および交付は行わない。

### 6.1.3 認証局への公開鍵の交付

本CAに対する証明書利用者の公開鍵の交付は、証明書の申請時にオンラインによって行われる。このときの通信経路はTLSにより暗号化を行う。

### 6.1.4 検証者へのCA公開鍵の交付

検証者は、本CAのリポジトリにアクセスすることによって、本CAの公開鍵を入手することができる。

### 6.1.5 鍵サイズ

本CAは、Baseline Requirementsに準拠した利用者向け証明書を発行するにあたって、次のことを確認するものとする。

RSA鍵ペアの場合

・エンコードされる時点でのモジュラス・サイズは、少なくとも2048 ビットであること

・モジュラス・サイズ（ビット単位）が8で割り切れること

ECDSA鍵ペアの場合

・キーが NIST P-256、NIST P-384 楕円曲線上の有効な点を表していること

他のアルゴリズムや鍵サイズは許可しない。

### 6.1.6 公開鍵のパラメータの生成および品質検査

本CAのシステムで使用するHSMは、暗号機能の品質検査機能を有する。公開鍵のパラメータは、品質検査の行われた暗号機能を用いて生成される。

RSAについて、本 CA は、公開指数の値が 3 以上の奇数であることを確認する。加えて、公開指数は2^16+1 および 2^256-1 の範囲内であるべきとする。法の特性として、奇数であること、素数の累乗ではないこと、752 より小さい因数がないこととする。\[参照: Section 5.3.3, NIST SP 800-89\]

ECDSAについて、本CAは、ECDSA 完全公開鍵検証ルーチンまたは ECDSA 部分公開鍵検証ルーチンを使用して、すべての鍵の有効性を確認する。\[参照: NIST SP800-56A: Revision2のSection 5.6.2.3.2 と 5.6.2.3.3\]

なお、証明書利用者の公開鍵のパラメータの生成および品質検査について規定しない。

### 6.1.7 鍵の用途　

本CAおよび本CAが発行する証明書の鍵の用途は以下の通りとする。

表6.1 鍵の用途

<table>
<colgroup>
<col style="width: 33%" />
<col style="width: 30%" />
<col style="width: 35%" />
</colgroup>
<thead>
<tr>
<th style="text-align: left;"></th>
<th style="text-align: left;">本CA</th>
<th style="text-align: left;">本CAが発行する証明書</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: left;">digitalSignature</td>
<td style="text-align: left;">―</td>
<td style="text-align: left;">yes</td>
</tr>
<tr>
<td style="text-align: left;">nonRepudiation</td>
<td style="text-align: left;">―</td>
<td style="text-align: left;">―</td>
</tr>
<tr>
<td style="text-align: left;">keyEncipherment</td>
<td style="text-align: left;">―</td>
<td style="text-align: left;"><p>yes</p>
<p>（ただし、ECDSA鍵を利用した証明書を除く）</p></td>
</tr>
<tr>
<td style="text-align: left;">dataEncipherment</td>
<td style="text-align: left;">―</td>
<td style="text-align: left;">―</td>
</tr>
<tr>
<td style="text-align: left;">keyAgreement</td>
<td style="text-align: left;">―</td>
<td style="text-align: left;">―</td>
</tr>
<tr>
<td style="text-align: left;">keyCertSign</td>
<td style="text-align: left;">yes</td>
<td style="text-align: left;">―</td>
</tr>
<tr>
<td style="text-align: left;">cRLSign</td>
<td style="text-align: left;">yes</td>
<td style="text-align: left;">―</td>
</tr>
<tr>
<td style="text-align: left;">encipherOnly</td>
<td style="text-align: left;">―</td>
<td style="text-align: left;">―</td>
</tr>
<tr>
<td style="text-align: left;">decipherOnly</td>
<td style="text-align: left;">―</td>
<td style="text-align: left;">―</td>
</tr>
</tbody>
</table>

## 

## 6.2 私有鍵の保護および暗号モジュール技術の管理

本 CA は、不正な証明書発行を防止するための物理的および論理的な保護対策を実装する。前述の検証済みのシステムまたはデバイス外部での CA私有鍵の保護は、CA私有鍵の開示を防止する方法で実装された、物理セキュリティ、暗号化、またはその両方の組み合わせから構成する。CAは、暗号化された鍵または鍵の一部の残存期間中、暗号解読攻撃に耐えることができる最先端技術のアルゴリズムおよび鍵長によって、私有鍵を暗号化する。

### 6.2.1 暗号モジュールの標準および管理

本CAの私有鍵の生成、保管、署名操作は、FIPS140-2レベル3準拠のHSMを用いて行う。

### 6.2.2 私有鍵の複数人管理

本CAの私有鍵の活性化、非活性化、バックアップ等の操作は、安全な環境において複数人の権限者によって行う。

### 6.2.3 私有鍵のエスクロー

本CAの私有鍵のエスクローは行わない。

### 6.2.4 私有鍵のバックアップ

本CAの私有鍵のバックアップは、複数名の権限者によって行われ、暗号化された状態で、セキュアな室に保管される。

### 6.2.5 私有鍵のアーカイブ

本CA私有鍵のアーカイブは行わない。

### 6.2.6 私有鍵の暗号モジュールへのまたは暗号モジュールからの転送

本CAの私有鍵のHSMへの転送またはHSMからの転送は、セキュアな室において、私有鍵を暗号化した状態で行う。

### 6.2.7 暗号モジュールへの私有鍵の格納

本CAの私有鍵は、暗号化された状態でHSM内に格納する。

### 6.2.8 私有鍵の活性化方法

本CAの私有鍵の活性化は、セキュアな室において複数名の権限者によって行う。

### 6.2.9 私有鍵の非活性化方法

本CAの私有鍵の非活性化は、セキュアな室において複数名の権限者によって行う。

### 6.2.10 私有鍵の破棄方法

本CAの私有鍵の廃棄は、複数名の権限者によって完全に初期化または物理的に破壊することによって行う。バックアップについても同様の手続によって行う。

### 6.2.11 暗号モジュールの評価

本CAのシステムで使用するHSMの品質基準については、本CP/CPS「6.2.1.暗号モジュールの標準および管理」のとおりである。

## 6.3 鍵ペアのその他の管理方法

### 6.3.1 公開鍵のアーカイブ

本CAの公開鍵のアーカイブは、本CP/CPS「5.5.1 アーカイブの種類」に含まれる。

### 6.3.2 証明書の有効期間と私有鍵および公開鍵の有効期間

本CAの鍵ペアの有効期間は定めないが、CA証明書の有効期間は20年以下を想定している。

2026年3月15日以前に発行された利用者向け証明書は、有効期間が397日を超えるべきではなく、398日を超えてはならない。

2026年3月15日以降かつ2027年3月15日以前に発行された利用者向け証明書は、有効期間が199日を超えるべきではなく、200日を超えてはならない。

2027年3月15日以降かつ2029年3月15日以前に発行された利用者向け証明書は、有効期間が99日を超えるべきではなく、100日を超えてはならない。

2029年3月15日以降に発行された利用者向け証明書は、有効期間が46日を超えるべきではなく、47日を超えてはならない。

表6.3.2 利用者向け証明書の最大有効期間の参考

<table>
<colgroup>
<col style="width: 33%" />
<col style="width: 33%" />
<col style="width: 33%" />
</colgroup>
<thead>
<tr>
<th colspan="2" style="text-align: center;">証明書の発行日</th>
<th style="text-align: center;">最大有効期間</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: center;"></td>
<td style="text-align: center;">2026年3月15日より前</td>
<td style="text-align: center;">398日</td>
</tr>
<tr>
<td style="text-align: center;">2026年3月15日以降</td>
<td style="text-align: center;">2027年3月15日より前</td>
<td style="text-align: center;">200日</td>
</tr>
<tr>
<td style="text-align: center;">2027年3月15日以降</td>
<td style="text-align: center;">2029年3月15日より前</td>
<td style="text-align: center;">100日</td>
</tr>
<tr>
<td style="text-align: center;">2029年3月15日以降</td>
<td style="text-align: center;"></td>
<td style="text-align: center;">47日</td>
</tr>
</tbody>
</table>

計算上、1日は 86,400 秒となる。これを超える時間は、小数点以下の秒数やうるう秒を含めて、追加の1日を意味する。

## 6.4 活性化データ

### 6.4.1 活性化データの生成および設定

本CAの私有鍵を操作するために必要な活性化データは、複数名の権限者によって生成され、電子媒体に格納する。

### 6.4.2 活性化データの保護

本CAの私有鍵の活性化に必要なデータが格納された電子媒体は、セキュアな室において保管管理を行う。

### 6.4.3 活性化データの他の考慮点

本CAの私有鍵の活性化データの生成や設定等の管理は、本CP/CPS「5.2.1.信頼される役割」に記載された者が行う。

## 6.5 コンピュータのセキュリティ管理

### 6.5.1 コンピュータセキュリティに関する技術的要件

本CAは、本CAのシステムに導入するハードウェア、ソフトウェアに対して、その品質、安定性、安全性等について十分に検討を行い、導入を決定する。

本CA は、証明書を直接発行させることができるすべてのアカウントに対して、多要素認証を実施するものとする。

### 6.5.2 コンピュータセキュリティ評価

本CAは、本CAのシステムにおいて使用するすべてのソフトウェア、ハードウェアに対して事前にシステムテストを行い、本CAのシステムの信頼性の確保に努める。また、本CAのシステムのセキュリティ上の脆弱性についての情報収集、評価を継続的に行い、脆弱性が発見された場合には、すみやかに必要な対処を行う。

## 6.6 ライフサイクルの技術的管理

### 6.6.1 システム開発管理

本CAのシステムの構築およびメンテナンスは、安全な環境下で行う。本CAのシステムの変更を行う場合は、十分に安全性の評価、確認を行う。また、本CAのシステムに対して、適切なサイクルで最新のセキュリティ技術を導入するためにセキュリティチェックを行い、セキュリティを確保する。

### 6.6.2 セキュリティ運用管理

本CAは、情報資産管理、要員管理、権限管理等の運用管理の実施、不正侵入対策、ウイルス対策等のセキュリティ対策ソフトウェアの適時更新等を行い、セキュリティを確保する。

### 6.6.3 ライフサイクルセキュリティ管理

本CAは、本CAのシステムのシステム開発、運用、保守が適切に行われていることを適時評価し、必要に応じ改善を行う。

## 6.7 ネットワークセキュリティ管理

本CAは、本CAのシステムへのネットワークからの不正アクセス対策として、ファイアウォール、IDS等を設置する。

脆弱性管理要件：

- ペネトレーションテストは、少なくとも年1回、資格のある第三者によって実施する。

- 脆弱性識別プロセスには、関連するセキュリティアドバイザリの継続的な監視を含める。

- 重大と評価された脆弱性については、発見から96時間以内に対応計画を策定する。

- その他のレベルと評価された脆弱性については、本CAがリスクアセスメントに基づき定めた期間内（通常60日を超えない）に修正を完了する。

- 脆弱性は、もはや存在しないように修正された場合、または影響が本CAのセキュリティ体制に影響しないと確認された場合に、修正済みとみなす。

- すべての対応と結果は文書化し、監査対象とする

## 6.8 タイムスタンプ

タイムスタンプに関する要件は、本CP/CPS「5.5.5 記録にタイムスタンプを付与する要件」と同様とする。

# 7. 証明書および証明書失効リストのプロファイル

## 7.1 証明書のプロファイル

本CAは、本 CP/CPS「2.2 証明書情報の公開」、本CP/CPS「6.1.5 鍵サイズ」、本CP/CPS「6.1.6 公開鍵のパラメータの生成および品質検査」に規定された技術要件を満たすものとする。

本CAが利用者向け証明書を発行する際、CSPRNGからの64ビット以上の出力を含む1 以上かつ2^159未満の連番ではない証明書シリアル番号を生成するものとする。

本CAが発行する証明書は RFC5280に準拠している。プロファイルは、次表のとおりである。

表 7.1 - 1 利用者向け証明書プロファイル（IssuerがJPRS Domain Validation Authority $2013 G4またはJPRS Organization Validation Authority $2013 G4の証明書に適用）

<table>
<colgroup>
<col style="width: 15%" />
<col style="width: 24%" />
<col style="width: 48%" />
<col style="width: 11%" />
</colgroup>
<thead>
<tr>
<th colspan="2">基本領域</th>
<th>設定内容</th>
<th>critical</th>
</tr>
</thead>
<tbody>
<tr>
<td colspan="2">Version</td>
<td>Version 3</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Serial Number</td>
<td>CAが証明書に割り当てる整数のシリアル番号</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Signature Algorithm</td>
<td>sha256 With RSA Encryption</td>
<td>-</td>
</tr>
<tr>
<td rowspan="3">Issuer</td>
<td>Country</td>
<td>C=JP</td>
<td>-</td>
</tr>
<tr>
<td>Organization</td>
<td>O=Japan Registry Services Co., Ltd.</td>
<td>-</td>
</tr>
<tr>
<td>Common Name</td>
<td><p>（1）ドメイン認証型</p>
<p>CN=JPRS Domain Validation Authority $2013 G4</p>
<p>（2）組織認証型</p>
<p>CN=JPRS Organization Validation Authority $2013 G4</p></td>
<td>-</td>
</tr>
<tr>
<td rowspan="2">Validity</td>
<td>NotBefore</td>
<td>例) 2008/3/1 00:00:00 GMT</td>
<td>-</td>
</tr>
<tr>
<td>NotAfter</td>
<td>例) 2009/3/1 00:00:00 GMT</td>
<td>-</td>
</tr>
<tr>
<td rowspan="6">Subject</td>
<td>Country</td>
<td><p>（1）ドメイン認証型</p>
<p>記載しない</p>
<p>（2）組織認証型</p>
<p>証明書利用者の住所（国）として、「C=JP」を記載する</p></td>
<td>-</td>
</tr>
<tr>
<td>State Or Province</td>
<td><p>（1）ドメイン認証型</p>
<p>記載しない</p>
<p>（2）組織認証型</p>
<p>証明書利用者の住所（都道府県名）（必須）</p></td>
<td>-</td>
</tr>
<tr>
<td>Locality</td>
<td><p>（1）ドメイン認証型</p>
<p>記載しない</p>
<p>（2）組織認証型</p>
<p>証明書利用者の住所（市区町村名）（必須）</p></td>
<td>-</td>
</tr>
<tr>
<td>Organization</td>
<td><p>（1）ドメイン認証型</p>
<p>記載しない</p>
<p>（2）組織認証型</p>
<p>証明書利用者の名称（必須）</p></td>
<td>-</td>
</tr>
<tr>
<td>Organizational Unit</td>
<td><p>（1）ドメイン認証型</p>
<p>記載しない</p>
<p>（2）組織認証型</p>
<p>証明書利用者の部署名（任意）</p>
<p>（ただし、2021年11月18日以降に発行する証明書には記載しない）</p>
<p>本項目には「記号のみおよびスペースのみで構成される文字列」を指定してはならない</p>
<p>本項目には以下の文字列を含めてはならない</p>
<p>申請組織以外の情報と誤解される恐れのある名称・社名・商号・商標</p>
<p>法人格を示す文字列（「Co., Ltd」など）</p>
<p>特定の自然人を参照させる文字列</p>
<p>住所を示す文字列</p>
<p>電話番号</p>
<p>ドメイン名およびIPアドレス</p>
<p>「空欄」「該当なし」などの意味を示す文字列（「null」、「N/A」など）</p></td>
<td>-</td>
</tr>
<tr>
<td>Common Name</td>
<td><p>証明書をインストールする予定のサーバーのDNS内で使われるホスト名（必須）</p>
<p>証明書のSubject Alt Name拡張領域に含まれるdNSnameの値の1つを文字単位のコピーとしてエンコードする</p></td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Subject Public Key Info</td>
<td>Subjectの公開鍵RSA 2048ビット</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">拡張領域</td>
<td>設定内容</td>
<td>critical</td>
</tr>
<tr>
<td colspan="2">Key Usage</td>
<td><p>digitalSignature,</p>
<p>keyEncipherment</p></td>
<td>y</td>
</tr>
<tr>
<td colspan="2">Extended Key Usage</td>
<td>TLS Web Server Authentication</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Subject Alt Name</td>
<td>dNSName=サーバー名（複数の場合あり）</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Certificate Policies</td>
<td><p>[1] Certificate Policy</p>
<p>1.3.6.1.4.1.53827.1.1.4</p>
<p>CPS</p>
<p>http://jprs.jp/pubcert/info/repository/</p>
<p>[2] Certificate Policy</p>
<p>（1）ドメイン認証型</p>
<p>2.23.140.1.2.1</p>
<p>（2）組織認証型</p>
<p>2.23.140.1.2.2</p></td>
<td>n</td>
</tr>
<tr>
<td colspan="2">CRL Distribution Points</td>
<td><p>（1）ドメイン認証型</p>
<p>http://repo.pubcert.jprs.jp/sppca/jprs/dvca_g4/fullcrl.crl</p>
<p>（2）組織認証型</p>
<p>http://repo.pubcert.jprs.jp/sppca/jprs/ovca_g4/fullcrl.crl</p></td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Authority Information Access</td>
<td><p>[1] ocsp（1.3.6.1.5.5.7.48.1)</p>
<p>（1）ドメイン認証型</p>
<p>http://dv.g4.ocsp.pubcert.jprs.jp</p>
<p>（2）組織認証型</p>
<p>http://ov.g4.ocsp.pubcert.jprs.jp</p>
<p>[2] ca issuers（1.3.6.1.5.5.7.48.2）</p>
<p>（1）ドメイン認証型</p>
<p>http://repo.pubcert.jprs.jp/sppca/jprs/dvca_g4/JPRS_DVCA_G4_DER.cer</p>
<p>（2）組織認証型</p>
<p>http://repo.pubcert.jprs.jp/sppca/jprs/ovca_g4/JPRS_OVCA_G4_DER.cer</p></td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Authority Key Identifier</td>
<td>Issuer公開鍵のSHA-1ハッシュ値（160ビット）</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Subject Key Identifier</td>
<td>Subject公開鍵のSHA-1ハッシュ値（160ビット）</td>
<td>n</td>
</tr>
<tr>
<td colspan="2"><p>Certificate Transparency</p>
<p>Timestamp List</p>
<p>（1.3.6.1.4.1.11129.2.4.2）</p></td>
<td>エンコードされたSignedCertificateTimestampList を含むOCTET STRINGとする</td>
<td>n</td>
</tr>
</tbody>
</table>

表 7.1 - 2 利用者向け証明書プロファイル（IssuerがJPRS DV RSA CA 2024 G1またはJPRS OV RSA CA 2024 G1の証明書に適用）

<table>
<colgroup>
<col style="width: 15%" />
<col style="width: 24%" />
<col style="width: 48%" />
<col style="width: 11%" />
</colgroup>
<thead>
<tr>
<th colspan="2">基本領域</th>
<th>設定内容</th>
<th>critical</th>
</tr>
</thead>
<tbody>
<tr>
<td colspan="2">Version</td>
<td>Version 3</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Serial Number</td>
<td>CAが証明書に割り当てる整数のシリアル番号</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Signature Algorithm</td>
<td>sha256 With RSA Encryption</td>
<td>-</td>
</tr>
<tr>
<td rowspan="3">Issuer</td>
<td>Country</td>
<td>C=JP</td>
<td>-</td>
</tr>
<tr>
<td>Organization</td>
<td>O=Japan Registry Services Co., Ltd.</td>
<td>-</td>
</tr>
<tr>
<td>Common Name</td>
<td style="text-align: left;"><p>（1）ドメイン認証型</p>
<p>CN= JPRS DV RSA CA 2024 G1</p>
<p>（2）組織認証型</p>
<p>CN= JPRS OV RSA CA 2024 G1</p></td>
<td>-</td>
</tr>
<tr>
<td rowspan="2">Validity</td>
<td>NotBefore</td>
<td>例) 2008/3/1 00:00:00 GMT</td>
<td>-</td>
</tr>
<tr>
<td>NotAfter</td>
<td>例) 2009/3/1 00:00:00 GMT</td>
<td>-</td>
</tr>
<tr>
<td rowspan="5">Subject</td>
<td>Country</td>
<td><p>（1）ドメイン認証型</p>
<p>記載しない</p>
<p>（2）組織認証型</p>
<p>証明書利用者の住所（国）として、「C=JP」を記載する</p></td>
<td>-</td>
</tr>
<tr>
<td>State Or Province</td>
<td><p>（1）ドメイン認証型</p>
<p>記載しない</p>
<p>（2）組織認証型</p>
<p>証明書利用者の住所（都道府県名）（必須）</p></td>
<td>-</td>
</tr>
<tr>
<td>Locality</td>
<td><p>（1）ドメイン認証型</p>
<p>記載しない</p>
<p>（2）組織認証型</p>
<p>証明書利用者の住所（市区町村名）（必須）</p></td>
<td>-</td>
</tr>
<tr>
<td>Organization</td>
<td><p>（1）ドメイン認証型</p>
<p>記載しない</p>
<p>（2）組織認証型</p>
<p>証明書利用者の名称（必須）</p></td>
<td>-</td>
</tr>
<tr>
<td>Common Name</td>
<td><p>証明書をインストールする予定のサーバーのDNS内で使われるホスト名（必須）</p>
<p>証明書のSubject Alt Name拡張領域に含まれるdNSnameの値の1つを文字単位のコピーとしてエンコードする</p></td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Subject Public Key Info</td>
<td><p>Subjectの公開鍵 RSA2048 ビット、</p>
<p>RSA3072 ビット、RSA4096 ビットの</p>
<p>いずれか</p></td>
<td>-</td>
</tr>
<tr>
<td colspan="2">拡張領域</td>
<td>設定内容</td>
<td>critical</td>
</tr>
<tr>
<td colspan="2">Key Usage</td>
<td><p>digitalSignature,</p>
<p>keyEncipherment</p></td>
<td>y</td>
</tr>
<tr>
<td colspan="2">Extended Key Usage</td>
<td><p>TLS Web Server Authentication、</p>
<p>TLS Web Client Authentication（任意）</p></td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Subject Alt Name</td>
<td>dNSName=サーバー名（複数の場合あり）</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Certificate Policies</td>
<td><p>Certificate Policy</p>
<p>（1）ドメイン認証型</p>
<p>2.23.140.1.2.1</p>
<p>（2）組織認証型</p>
<p>2.23.140.1.2.2</p></td>
<td>n</td>
</tr>
<tr>
<td colspan="2">CRL Distribution Points</td>
<td><p>（1）ドメイン認証型</p>
<p>http://repo.pubcert.jprs.jp/sppca/jprs/dvca_rsa2024g1/fullcrl.crl</p>
<p>（2）組織認証型</p>
<p>http://repo.pubcert.jprs.jp/sppca/jprs/ovca_rsa2024g1/fullcrl.crl</p></td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Authority Information Access</td>
<td><p>[1] ocsp（1.3.6.1.5.5.7.48.1)</p>
<p>（1）ドメイン認証型</p>
<p>http://dv.rsa2024g1.ocsp.pubcert.jprs.jp</p>
<p>（2）組織認証型</p>
<p>http://ov.rsa2024g1.ocsp.pubcert.jprs.jp</p>
<p>[2] ca issuers（1.3.6.1.5.5.7.48.2）</p>
<p>（1）ドメイン認証型</p>
<p>http://repo.pubcert.jprs.jp/sppca/jprs/dvca_rsa2024g1/JPRS_DVCA_RSA2024G1_DER.cer</p>
<p>（2）組織認証型</p>
<p>http://repo.pubcert.jprs.jp/sppca/jprs/ovca_rsa2024g1/JPRS_OVCA_RSA2024G1_DER.cer</p></td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Authority Key Identifier</td>
<td>Issuer公開鍵のSHA-1ハッシュ値（160ビット）</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Subject Key Identifier</td>
<td>Subject公開鍵のSHA-1ハッシュ値（160ビット）</td>
<td>n</td>
</tr>
<tr>
<td colspan="2"><p>Certificate Transparency</p>
<p>Timestamp List</p>
<p>（1.3.6.1.4.1.11129.2.4.2）</p></td>
<td>エンコードされたSignedCertificateTimestampList を含むOCTET STRINGとする（任意）</td>
<td>n</td>
</tr>
</tbody>
</table>

表 7.1 - 3 利用者向け証明書プロファイル（IssuerがJPRS DV ECC CA 2024 G1またはJPRS OV ECC CA 2024 G1の証明書に適用）

<table>
<colgroup>
<col style="width: 15%" />
<col style="width: 24%" />
<col style="width: 48%" />
<col style="width: 11%" />
</colgroup>
<thead>
<tr>
<th colspan="2">基本領域</th>
<th>設定内容</th>
<th>critical</th>
</tr>
</thead>
<tbody>
<tr>
<td colspan="2">Version</td>
<td>Version 3</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Serial Number</td>
<td>CAが証明書に割り当てる整数のシリアル番号</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Signature Algorithm</td>
<td>ecdsa-with-SHA384</td>
<td>-</td>
</tr>
<tr>
<td rowspan="3">Issuer</td>
<td>Country</td>
<td>C=JP</td>
<td>-</td>
</tr>
<tr>
<td>Organization</td>
<td>O=Japan Registry Services Co., Ltd.</td>
<td>-</td>
</tr>
<tr>
<td>Common Name</td>
<td style="text-align: left;"><p>（1）ドメイン認証型</p>
<p>CN= JPRS DV ECC CA 2024 G1</p>
<p>（2）組織認証型</p>
<p>CN= JPRS OV ECC CA 2024 G1</p></td>
<td>-</td>
</tr>
<tr>
<td rowspan="2">Validity</td>
<td>NotBefore</td>
<td>例) 2008/3/1 00:00:00 GMT</td>
<td>-</td>
</tr>
<tr>
<td>NotAfter</td>
<td>例) 2009/3/1 00:00:00 GMT</td>
<td>-</td>
</tr>
<tr>
<td rowspan="5">Subject</td>
<td>Country</td>
<td><p>（1）ドメイン認証型</p>
<p>記載しない</p>
<p>（2）組織認証型</p>
<p>証明書利用者の住所（国）として、「C=JP」を記載する</p></td>
<td>-</td>
</tr>
<tr>
<td>State Or Province</td>
<td><p>（1）ドメイン認証型</p>
<p>記載しない</p>
<p>（2）組織認証型</p>
<p>証明書利用者の住所（都道府県名）（必須）</p></td>
<td>-</td>
</tr>
<tr>
<td>Locality</td>
<td><p>（1）ドメイン認証型</p>
<p>記載しない</p>
<p>（2）組織認証型</p>
<p>証明書利用者の住所（市区町村名）（必須）</p></td>
<td>-</td>
</tr>
<tr>
<td>Organization</td>
<td><p>（1）ドメイン認証型</p>
<p>記載しない</p>
<p>（2）組織認証型</p>
<p>証明書利用者の名称（必須）</p></td>
<td>-</td>
</tr>
<tr>
<td>Common Name</td>
<td><p>証明書をインストールする予定のサーバーのDNS内で使われるホスト名（必須）</p>
<p>証明書のSubject Alt Name拡張領域に含まれるdNSnameの値の1つを文字単位のコピーとしてエンコードする</p></td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Subject Public Key Info</td>
<td><p>Subjectの公開鍵 RSA2048 ビット、</p>
<p>RSA3072 ビット、RSA4096 ビット、P-256、P-384のいずれか</p></td>
<td>-</td>
</tr>
<tr>
<td colspan="2">拡張領域</td>
<td>設定内容</td>
<td>critical</td>
</tr>
<tr>
<td colspan="2">Key Usage</td>
<td><p>digitalSignature</p>
<p>keyEncipherment（ECDSA鍵を利用した証明書には記載しない）</p></td>
<td>y</td>
</tr>
<tr>
<td colspan="2">Extended Key Usage</td>
<td><p>TLS Web Server Authentication、</p>
<p>TLS Web Client Authentication（任意）</p></td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Subject Alt Name</td>
<td>dNSName=サーバー名（複数の場合あり）</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Certificate Policies</td>
<td><p>Certificate Policy</p>
<p>（1）ドメイン認証型</p>
<p>2.23.140.1.2.1</p>
<p>（2）組織認証型</p>
<p>2.23.140.1.2.2</p></td>
<td>n</td>
</tr>
<tr>
<td colspan="2">CRL Distribution Points</td>
<td><p>（1）ドメイン認証型</p>
<p>http://repo.pubcert.jprs.jp/sppca/jprs/dvca_ecc2024g1/fullcrl.crl</p>
<p>（2）組織認証型</p>
<p>http://repo.pubcert.jprs.jp/sppca/jprs/ovca_ecc2024g1/fullcrl.crl</p></td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Authority Information Access</td>
<td><p>[1] ocsp（1.3.6.1.5.5.7.48.1)</p>
<p>（1）ドメイン認証型</p>
<p>http://dv.ecc2024g1.ocsp.pubcert.jprs.jp</p>
<p>（2）組織認証型</p>
<p>http://ov.ecc2024g1.ocsp.pubcert.jprs.jp</p>
<p>[2] ca issuers（1.3.6.1.5.5.7.48.2）</p>
<p>（1）ドメイン認証型</p>
<p>http://repo.pubcert.jprs.jp/sppca/jprs/dvca_ecc2024g1/JPRSDVCA_ECC2024G1_DER.cer</p>
<p>（2）組織認証型</p>
<p>http://repo.pubcert.jprs.jp/sppca/jprs/ovca_ecc2024g1/JPRS_OVCA_ECC2024G1_DER.cer</p></td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Authority Key Identifier</td>
<td>Issuer公開鍵のSHA-1ハッシュ値（160ビット）</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Subject Key Identifier</td>
<td>Subject公開鍵のSHA-1ハッシュ値（160ビット）</td>
<td>n</td>
</tr>
<tr>
<td colspan="2"><p>Certificate Transparency</p>
<p>Timestamp List</p>
<p>（1.3.6.1.4.1.11129.2.4.2）</p></td>
<td>エンコードされたSignedCertificateTimestampList を含むOCTET STRINGとする（任意）</td>
<td>n</td>
</tr>
</tbody>
</table>

表 7.1 - 4 中間証明書プロファイル（IssuerがSecurity Communication RootCA2の証明書に適用）

<table>
<colgroup>
<col style="width: 15%" />
<col style="width: 24%" />
<col style="width: 48%" />
<col style="width: 11%" />
</colgroup>
<thead>
<tr>
<th colspan="2">基本領域</th>
<th>設定内容</th>
<th>critical</th>
</tr>
</thead>
<tbody>
<tr>
<td colspan="2">Version</td>
<td>Version 3</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Serial Number</td>
<td>CAが証明書に割り当てる整数のシリアル番号</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Signature Algorithm</td>
<td>sha256 With RSA Encryption</td>
<td>-</td>
</tr>
<tr>
<td rowspan="3">Issuer</td>
<td>Country</td>
<td>C=JP</td>
<td>-</td>
</tr>
<tr>
<td>Organization</td>
<td>O=SECOM Trust Systems CO.,LTD.</td>
<td>-</td>
</tr>
<tr>
<td>Common Name</td>
<td>OU=Security Communication RootCA2</td>
<td>-</td>
</tr>
<tr>
<td rowspan="2">Validity</td>
<td>NotBefore</td>
<td>例) 2008/3/1 00:00:00 GMT</td>
<td>-</td>
</tr>
<tr>
<td>NotAfter</td>
<td>例) 2009/3/1 00:00:00 GMT</td>
<td>-</td>
</tr>
<tr>
<td rowspan="3">Subject</td>
<td>Country</td>
<td>C=JP</td>
<td>-</td>
</tr>
<tr>
<td>Organization</td>
<td>O=Japan Registry Services Co., Ltd.</td>
<td>-</td>
</tr>
<tr>
<td>Common Name</td>
<td><p>（1）組織認証型</p>
<p>CN=JPRS Organization Validation Authority - G4</p>
<p>（2）ドメイン認証型</p>
<p>CN=JPRS Domain Validation Authority - G4</p></td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Subject Public Key Info</td>
<td>Subjectの公開鍵 2048 ビット</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">拡張領域</td>
<td>設定内容</td>
<td>critical</td>
</tr>
<tr>
<td colspan="2">Authority Key Identifier</td>
<td>Issuer公開鍵の SHA-1 ハッシュ値（160 ビット）</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Subject Key Identifier</td>
<td>Subject公開鍵の SHA-1 ハッシュ値（160 ビット）</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Key Usage</td>
<td><p>Certificate Signing</p>
<p>Off-line CRL Signing</p>
<p>CRL Signing (06)</p></td>
<td>y</td>
</tr>
<tr>
<td colspan="2">Certificate Policies</td>
<td><p>Certificate Policy</p>
<p>1.2.392.200091.100.901.4</p>
<p>CPS</p>
<p>http://repository.secomtrust.net/SC-Root2/</p></td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Basic Constraints</td>
<td><p>Subject Type=CA</p>
<p>Path Length Constraint=0</p></td>
<td>y</td>
</tr>
<tr>
<td colspan="2">Extended Key Usage</td>
<td>TLS Web Server Authentication</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">CRL Distribution Points</td>
<td>http://repository.secomtrust.net/SC-Root2/SCRoot2CRL.crl</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Authority Information Access</td>
<td><p>[1] ocsp（1.3.6.1.5.5.7.48.1）</p>
<p>http://scrootca2.ocsp.secomtrust.net</p>
<p>[2] ca issuers（1.3.6.1.5.5.7.48.2）</p>
<p>http://repository.secomtrust.net/SC-Root2/SCRoot2ca.cer</p></td>
<td>n</td>
</tr>
</tbody>
</table>

表 7.1 - 5 中間証明書プロファイル（IssuerがSECOM TLS RSA Root CA 2024の証明書に適用）

<table>
<colgroup>
<col style="width: 15%" />
<col style="width: 24%" />
<col style="width: 48%" />
<col style="width: 11%" />
</colgroup>
<thead>
<tr>
<th colspan="2">基本領域</th>
<th>設定内容</th>
<th>critical</th>
</tr>
</thead>
<tbody>
<tr>
<td colspan="2">Version</td>
<td>Version 3</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Serial Number</td>
<td>CAが証明書に割り当てる整数のシリアル番号</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Signature Algorithm</td>
<td>Sha384 With RSA Encryption</td>
<td>-</td>
</tr>
<tr>
<td rowspan="3">Issuer</td>
<td>Country</td>
<td>C=JP</td>
<td>-</td>
</tr>
<tr>
<td>Organization</td>
<td>O=SECOM Trust Systems Co., Ltd.</td>
<td>-</td>
</tr>
<tr>
<td>Common Name</td>
<td>CN=SECOM TLS RSA Root CA 2024</td>
<td>-</td>
</tr>
<tr>
<td rowspan="2">Validity</td>
<td>NotBefore</td>
<td>例) 2008/3/1 00:00:00 GMT</td>
<td>-</td>
</tr>
<tr>
<td>NotAfter</td>
<td>例) 2009/3/1 00:00:00 GMT</td>
<td>-</td>
</tr>
<tr>
<td rowspan="3">Subject</td>
<td>Country</td>
<td>C=JP</td>
<td>-</td>
</tr>
<tr>
<td>Organization</td>
<td>O=Japan Registry Services Co., Ltd.</td>
<td>-</td>
</tr>
<tr>
<td>Common Name</td>
<td><p>（1）組織認証型</p>
<p>CN= JPRS OV RSA CA 2024 G1</p>
<p>（2）ドメイン認証型</p>
<p>CN= JPRS DV RSA CA 2024 G1</p></td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Subject Public Key Info</td>
<td>Subjectの公開鍵 4096 ビット</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">拡張領域</td>
<td>設定内容</td>
<td>critical</td>
</tr>
<tr>
<td colspan="2">Authority Key Identifier</td>
<td>Issuer公開鍵の SHA-1 ハッシュ値（160 ビット）</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Subject Key Identifier</td>
<td>Subject公開鍵の SHA-1 ハッシュ値（160 ビット）</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Key Usage</td>
<td><p>Certificate Signing</p>
<p>Off-line CRL Signing</p>
<p>CRL Signing (06)</p></td>
<td>y</td>
</tr>
<tr>
<td colspan="2">Certificate Policies</td>
<td><p>[1] Certificate Policy</p>
<p>（1）ドメイン認証型</p>
<p>2.23.140.1.2.1</p>
<p>（2）組織認証型</p>
<p>2.23.140.1.2.2</p>
<p>[2] Certificate Policy</p>
<p>1.2.392.200091.100.901.11</p></td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Basic Constraints</td>
<td><p>Subject Type=CA</p>
<p>Path Length Constraint=0</p></td>
<td>y</td>
</tr>
<tr>
<td colspan="2">Extended Key Usage</td>
<td><p>TLS Web Server Authentication</p>
<p>TLS Web Client Authentication</p></td>
<td>n</td>
</tr>
<tr>
<td colspan="2">CRL Distribution Points</td>
<td>http://repo1.secomtrust.net/root/tlsrsa/tlsrsarootca2024.crl</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Authority Information Access</td>
<td><p>[1] ocsp（1.3.6.1.5.5.7.48.1）</p>
<p>http://tlsrsarootca2024.ocsp.secom-cert.jp</p>
<p>[2] ca issuers（1.3.6.1.5.5.7.48.2）</p>
<p>http://repo2.secomtrust.net/root/tlsrsa/tlsrsarootca2024.cer</p></td>
<td>n</td>
</tr>
</tbody>
</table>

表 7.1 - 6 中間証明書プロファイル（IssuerがSecurity Communication ECC RootCA1の証明書に適用）

<table>
<colgroup>
<col style="width: 15%" />
<col style="width: 24%" />
<col style="width: 48%" />
<col style="width: 11%" />
</colgroup>
<thead>
<tr>
<th colspan="2">基本領域</th>
<th>設定内容</th>
<th>critical</th>
</tr>
</thead>
<tbody>
<tr>
<td colspan="2">Version</td>
<td>Version 3</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Serial Number</td>
<td>CAが証明書に割り当てる整数のシリアル番号</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Signature Algorithm</td>
<td>ecdsa-with-SHA384</td>
<td>-</td>
</tr>
<tr>
<td rowspan="3">Issuer</td>
<td>Country</td>
<td>C=JP</td>
<td>-</td>
</tr>
<tr>
<td>Organization</td>
<td>O=SECOM Trust Systems CO.,LTD.</td>
<td>-</td>
</tr>
<tr>
<td>Common Name</td>
<td>CN=Security Communication ECC RootCA1</td>
<td>-</td>
</tr>
<tr>
<td rowspan="2">Validity</td>
<td>NotBefore</td>
<td>例) 2008/3/1 00:00:00 GMT</td>
<td>-</td>
</tr>
<tr>
<td>NotAfter</td>
<td>例) 2009/3/1 00:00:00 GMT</td>
<td>-</td>
</tr>
<tr>
<td rowspan="3">Subject</td>
<td>Country</td>
<td>C=JP</td>
<td>-</td>
</tr>
<tr>
<td>Organization</td>
<td>O=Japan Registry Services Co., Ltd.</td>
<td>-</td>
</tr>
<tr>
<td>Common Name</td>
<td><p>（1）組織認証型</p>
<p>CN= JPRS OV ECC CA 2024 G1</p>
<p>（2）ドメイン認証型</p>
<p>CN= JPRS DV ECC CA 2024 G1</p></td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Subject Public Key Info</td>
<td>Subjectの公開鍵 384 ビット</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">拡張領域</td>
<td>設定内容</td>
<td>critical</td>
</tr>
<tr>
<td colspan="2">Authority Key Identifier</td>
<td>Issuer公開鍵の SHA-1 ハッシュ値（160 ビット）</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Subject Key Identifier</td>
<td>Subject公開鍵の SHA-1 ハッシュ値（160 ビット）</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Key Usage</td>
<td><p>Certificate Signing</p>
<p>Off-line CRL Signing</p>
<p>CRL Signing (06)</p></td>
<td>y</td>
</tr>
<tr>
<td colspan="2">Certificate Policies</td>
<td><p>[1] Certificate Policy</p>
<p>（1）ドメイン認証型</p>
<p>2.23.140.1.2.1</p>
<p>（2）組織認証型</p>
<p>2.23.140.1.2.2</p>
<p>[2] Certificate Policy</p>
<p>1.2.392.200091.100.902.1</p></td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Basic Constraints</td>
<td><p>Subject Type=CA</p>
<p>Path Length Constraint=0</p></td>
<td>y</td>
</tr>
<tr>
<td colspan="2">Extended Key Usage</td>
<td><p>TLS Web Server Authentication</p>
<p>TLS Web Client Authentication</p></td>
<td>n</td>
</tr>
<tr>
<td colspan="2">CRL Distribution Points</td>
<td>http://repository.secomtrust.net/SC-ECC-Root1/SCECCRoot1CRL.crl</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Authority Information Access</td>
<td><p>[1] ocsp（1.3.6.1.5.5.7.48.1）</p>
<p>http://sceccrootca1.ocsp.secomtrust.net [2] ca issuers（1.3.6.1.5.5.7.48.2）</p>
<p>http://repository.secomtrust.net/SC-ECC-Root1/SCECCRoot1ca.cer</p></td>
<td>n</td>
</tr>
</tbody>
</table>

表 7.1 - 7 事前証明書プロファイル（発行日が2020年7月29日以降の証明書に適用）

<table>
<colgroup>
<col style="width: 15%" />
<col style="width: 24%" />
<col style="width: 48%" />
<col style="width: 11%" />
</colgroup>
<thead>
<tr>
<th colspan="2">基本領域</th>
<th>設定内容</th>
<th>critical</th>
</tr>
</thead>
<tbody>
<tr>
<td colspan="2">Version</td>
<td>利用者向け証明書の同項目とバイト単位で同一</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Serial Number</td>
<td>同上</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Signature Algorithm</td>
<td>同上</td>
<td>-</td>
</tr>
<tr>
<td rowspan="3">Issuer</td>
<td>Country</td>
<td>同上</td>
<td>-</td>
</tr>
<tr>
<td>Organization</td>
<td>同上</td>
<td>-</td>
</tr>
<tr>
<td>Common Name</td>
<td>同上</td>
<td>-</td>
</tr>
<tr>
<td rowspan="2">Validity</td>
<td>NotBefore</td>
<td>同上</td>
<td>-</td>
</tr>
<tr>
<td>NotAfter</td>
<td>同上</td>
<td>-</td>
</tr>
<tr>
<td rowspan="5">Subject</td>
<td>Country</td>
<td>同上</td>
<td>-</td>
</tr>
<tr>
<td>State Or Province</td>
<td>同上</td>
<td>-</td>
</tr>
<tr>
<td>Locality</td>
<td>同上</td>
<td>-</td>
</tr>
<tr>
<td>Organization</td>
<td>同上</td>
<td>-</td>
</tr>
<tr>
<td>Common Name</td>
<td>同上</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Subject Public Key Info</td>
<td>同上</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">拡張領域</td>
<td>設定内容</td>
<td>critical</td>
</tr>
<tr>
<td colspan="2">Precertificate Poison</td>
<td><p>extnValue OCTET STRING</p>
<ul>
<li><p>RFC 6962の3.1項で規定されているASN.1 NULL値の符号化表現である0500バイトを正確に16進符号化したものとする。</p></li>
</ul></td>
<td>y</td>
</tr>
<tr>
<td colspan="2">Key Usage</td>
<td>利用者向け証明書の同項目とバイト単位で同一</td>
<td>y</td>
</tr>
<tr>
<td colspan="2">Extended Key Usage</td>
<td>同上</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Subject Alt Name</td>
<td>同上</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Certificate Policies</td>
<td>同上</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">CRL Distribution Points</td>
<td>同上</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Authority Information Access</td>
<td>同上</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Authority Key Identifier</td>
<td>同上</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Subject Key Identifier</td>
<td>同上</td>
<td>n</td>
</tr>
</tbody>
</table>

※事前証明書からPrecertificate Poison拡張領域を削除し、利用者向け証明書からSigned Certificate Timestamp拡張領域を削除した場合、事前証明書と利用者向け証明書の拡張領域の内容は、バイト単位で同一になる。

表 7.1 - 8 OCSPレスポンダ証明書プロファイル（IssuerがJPRS Domain Validation Authority $2013 G4またはJPRS Organization Validation Authority $2013 G4の証明書に適用）

<table>
<colgroup>
<col style="width: 15%" />
<col style="width: 24%" />
<col style="width: 48%" />
<col style="width: 11%" />
</colgroup>
<thead>
<tr>
<th colspan="2">基本領域</th>
<th>設定内容</th>
<th>critical</th>
</tr>
</thead>
<tbody>
<tr>
<td colspan="2">Version</td>
<td>Version 3</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Serial Number</td>
<td>CSPRNG から出力される少なくとも 64 ビットを含む、ゼロ(0)より大きく 2^159より小さい非連続的な数値でなければならない</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Signature Algorithm</td>
<td>sha256 With RSA Encryption</td>
<td>-</td>
</tr>
<tr>
<td rowspan="3">Issuer</td>
<td>Country</td>
<td>C=JP</td>
<td>-</td>
</tr>
<tr>
<td>Organization</td>
<td>O= Japan Registry Services Co., Ltd.</td>
<td>-</td>
</tr>
<tr>
<td>Common Name</td>
<td><p>（1）ドメイン認証型</p>
<p>CN=JPRS Domain Validation Authority - G4</p>
<p>（2）組織認証型</p>
<p>CN=JPRS Organization Validation Authority $2013 G4</p></td>
<td>-</td>
</tr>
<tr>
<td rowspan="2">Validity</td>
<td>NotBefore</td>
<td>例) 2008/3/1 00:00:00 GMT</td>
<td>-</td>
</tr>
<tr>
<td>NotAfter</td>
<td>例) 2008/3/5 00:00:00 GMT</td>
<td>-</td>
</tr>
<tr>
<td rowspan="3">Subject</td>
<td>Country</td>
<td>C=JP（固定値）</td>
<td>-</td>
</tr>
<tr>
<td>Organization</td>
<td><p>Japan Registry Services Co., Ltd.</p>
<p>（固定値）</p></td>
<td>-</td>
</tr>
<tr>
<td>Common Name</td>
<td>OCSPサーバー名（必須）</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Subject Public Key Info</td>
<td>Subjectの公開鍵RSA 2048ビット</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">拡張領域</td>
<td>設定内容</td>
<td>critical</td>
</tr>
<tr>
<td colspan="2">Authority Key Identifier</td>
<td>Issuer公開鍵のSHA-1ハッシュ値（160ビット）</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Subject Key Identifier</td>
<td>Subject公開鍵のSHA-1ハッシュ値（160ビット）</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">KeyUsage</td>
<td>digitalSignature</td>
<td>y</td>
</tr>
<tr>
<td colspan="2">ExtendedKeyUsage</td>
<td>OCSPSigning</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">OCSP No Check</td>
<td>null</td>
<td>n</td>
</tr>
</tbody>
</table>

表 7.1 $2013 9 OCSPレスポンダ証明書プロファイル（IssuerがJPRS DV RSA CA 2024 G1またはJPRS OV RSA CA 2024 G1の証明書に適用）

<table>
<colgroup>
<col style="width: 15%" />
<col style="width: 24%" />
<col style="width: 48%" />
<col style="width: 11%" />
</colgroup>
<thead>
<tr>
<th colspan="2">基本領域</th>
<th>設定内容</th>
<th>critical</th>
</tr>
</thead>
<tbody>
<tr>
<td colspan="2">Version</td>
<td>Version 3</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Serial Number</td>
<td>CSPRNG から出力される少なくとも 64 ビットを含む、ゼロ(0)より大きく 2^159より小さい非連続的な数値でなければならない</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Signature Algorithm</td>
<td>sha256 With RSA Encryption</td>
<td>-</td>
</tr>
<tr>
<td rowspan="3">Issuer</td>
<td>Country</td>
<td>C=JP</td>
<td>-</td>
</tr>
<tr>
<td>Organization</td>
<td>O= Japan Registry Services Co., Ltd.</td>
<td>-</td>
</tr>
<tr>
<td>Common Name</td>
<td style="text-align: left;"><p>（1）ドメイン認証型</p>
<p>CN= JPRS DV RSA CA 2024 G1</p>
<p>（2）組織認証型</p>
<p>CN= JPRS OV RSA CA 2024 G1</p></td>
<td>-</td>
</tr>
<tr>
<td rowspan="2">Validity</td>
<td>NotBefore</td>
<td>例) 2008/3/1 00:00:00 GMT</td>
<td>-</td>
</tr>
<tr>
<td>NotAfter</td>
<td>例) 2008/3/5 00:00:00 GMT</td>
<td>-</td>
</tr>
<tr>
<td rowspan="3">Subject</td>
<td>Country</td>
<td>C=JP（固定値）</td>
<td>-</td>
</tr>
<tr>
<td>Organization</td>
<td><p>Japan Registry Services Co., Ltd.</p>
<p>（固定値）</p></td>
<td>-</td>
</tr>
<tr>
<td>Common Name</td>
<td>OCSPサーバー名（必須）</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Subject Public Key Info</td>
<td><p>Subjectの公開鍵 RSA2048 ビット、</p>
<p>RSA3072 ビット、RSA4096 ビットの</p>
<p>いずれか</p></td>
<td>-</td>
</tr>
<tr>
<td colspan="2">拡張領域</td>
<td>設定内容</td>
<td>critical</td>
</tr>
<tr>
<td colspan="2">Authority Key Identifier</td>
<td>Issuer公開鍵のSHA-1ハッシュ値（160ビット）</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Subject Key Identifier</td>
<td>Subject公開鍵のSHA-1ハッシュ値（160ビット）</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">KeyUsage</td>
<td>digitalSignature</td>
<td>y</td>
</tr>
<tr>
<td colspan="2">ExtendedKeyUsage</td>
<td>OCSPSigning</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">OCSP No Check</td>
<td>null</td>
<td>n</td>
</tr>
</tbody>
</table>

表 7.1 - 10 OCSPレスポンダ証明書プロファイル（IssuerがJPRS DV ECC CA 2024 G1またはJPRS OV ECC CA 2024 G1の証明書に適用）

<table>
<colgroup>
<col style="width: 15%" />
<col style="width: 24%" />
<col style="width: 48%" />
<col style="width: 11%" />
</colgroup>
<thead>
<tr>
<th colspan="2">基本領域</th>
<th>設定内容</th>
<th>critical</th>
</tr>
</thead>
<tbody>
<tr>
<td colspan="2">Version</td>
<td>Version 3</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Serial Number</td>
<td>CSPRNG から出力される少なくとも 64 ビットを含む、ゼロ(0)より大きく 2^159より小さい非連続的な数値でなければならない</td>
<td></td>
</tr>
<tr>
<td colspan="2">Signature Algorithm</td>
<td>ecdsa-with-SHA384</td>
<td>-</td>
</tr>
<tr>
<td rowspan="3">Issuer</td>
<td>Country</td>
<td>C=JP</td>
<td>-</td>
</tr>
<tr>
<td>Organization</td>
<td>O= Japan Registry Services Co., Ltd.</td>
<td>-</td>
</tr>
<tr>
<td>Common Name</td>
<td style="text-align: left;"><p>（1）ドメイン認証型</p>
<p>CN= JPRS DV ECC CA 2024 G1</p>
<p>（2）組織認証型</p>
<p>CN= JPRS OV ECC CA 2024 G1</p></td>
<td>-</td>
</tr>
<tr>
<td rowspan="2">Validity</td>
<td>NotBefore</td>
<td>例) 2008/3/1 00:00:00 GMT</td>
<td>-</td>
</tr>
<tr>
<td>NotAfter</td>
<td>例) 2008/3/5 00:00:00 GMT</td>
<td>-</td>
</tr>
<tr>
<td rowspan="3">Subject</td>
<td>Country</td>
<td>C=JP（固定値）</td>
<td>-</td>
</tr>
<tr>
<td>Organization</td>
<td><p>Japan Registry Services Co., Ltd.</p>
<p>（固定値）</p></td>
<td>-</td>
</tr>
<tr>
<td>Common Name</td>
<td>OCSPサーバー名（必須）</td>
<td>-</td>
</tr>
<tr>
<td colspan="2">Subject Public Key Info</td>
<td><p>Subjectの公開鍵 256 ビット、</p>
<p>384 ビットのいずれか</p></td>
<td>-</td>
</tr>
<tr>
<td colspan="2">拡張領域</td>
<td>設定内容</td>
<td>critical</td>
</tr>
<tr>
<td colspan="2">Authority Key Identifier</td>
<td>Issuer公開鍵のSHA-1ハッシュ値（160ビット）</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">Subject Key Identifier</td>
<td>Subject公開鍵のSHA-1ハッシュ値（160ビット）</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">KeyUsage</td>
<td>digitalSignature</td>
<td>y</td>
</tr>
<tr>
<td colspan="2">ExtendedKeyUsage</td>
<td>OCSPSigning</td>
<td>n</td>
</tr>
<tr>
<td colspan="2">OCSP No Check</td>
<td>null</td>
<td>n</td>
</tr>
</tbody>
</table>

### 7.1.1 バージョン番号

本CA は、バージョン 3 を適用する。

### 7.1.2 証明書の内容と拡張

本CA が発行する証明書の内容と拡張は、本CP/CPS「7.1 証明書のプロファイル」に規定する。

### 7.1.3 アルゴリズムオブジェクト識別子

本サービスにおいて用いられるアルゴリズム OID は、次のとおりである。

| アルゴリズム               | オブジェクト識別子    |
|----------------------------|-----------------------|
| sha256 With RSA Encryption | 1.2.840.113549.1.1.11 |
| RSA Encryption             | 1.2.840.113549.1.1.1  |
| sha384 With RSA Encryption | 1.2.840.113549.1.1.12 |
| id-ecPublicKey             | 1.2.840.10045.2.1     |
| ecdsa-with-SHA384          | 1.2.840.10045.4.3.3   |

### 7.1.4 名前形式

本CAでは、RFC5280 で定められる識別名を使用する。

すべての有効な認証パス（RFC 5280の6項で定義されているとおり）について認証パスの利用者向け証明書ごとに、証明書発行者の識別名フィールドのエンコードされた内容は、発行されるCA証明書のSubject識別名フィールドのエンコードされた形式とバイト単位で同一である必要がある。

本 CA は、証明書を発行することにより、本CP/CPS に定められた手順に従い、証明書の発行日時点で、すべての識別名が正確であることを確認することを表明する。本 CAは、Baseline Requirementsの3.2.2.4項 に定める場合を除き、識別名にドメイン名を含めてはならない。

識別名には、'.'、'-'、''（スペース）文字などのメタデータや、値が存在しない、不完全、または適用できないことを示すその他の記号のみを含めてはならない。

本CAでは、予約済みIPアドレスまたは内部名を含むSubject Alt Name拡張領域またはコモンネームを持つ証明書を発行しない。

コモンネームの値がFQDNまたはワイルドカードドメイン名の場合、コモンネームの値は、Subject Alt Name拡張領域のdNSNameの値の 1 文字ずつのコピーとしてエンコードする。

具体的には、FQDNのすべてのドメインラベルまたはワイルドカードドメイン名の FQDN部分のすべてのDomainラベルは LDH ラベルとしてエンコードし、P-ラベルは Unicodeに変換しない。

### 7.1.5 名前制約

本CAでは設定しない。

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

本CAが発行する証明書のOIDは、本CP/CPS「1.2 文書名と識別」のOIDのとおりである。

次の証明書ポリシー識別子は、証明書または利用者向け証明書がBaseline Requirementsに準拠していることを表明するオプションの手段として本CAが使用するために用意されている。

【ドメイン認証型用】 {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) domain-validated(1)} (2.23.140.1.2.1)

【組織認証型用】 {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) organization-validated(2)} (2.23.140.1.2.2)

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

設定しない。

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

ポリシー修飾子については、本CP/CPSを公表するWebページのURIを格納する。

### 7.1.9 クリティカルな証明書ポリシー拡張に対する解釈の方法

設定しない。

## 7.2 CRLのプロファイル

本CAが発行するCRLのプロファイルは、次表のとおりである。

表7.2.1（削除）

表7.2.2 CRLプロファイル（IssuerがJPRS Domain Validation Authority $2013 G4またはJPRS Organization Validation Authority $2013 G4の証明書に適用）

<table>
<colgroup>
<col style="width: 15%" />
<col style="width: 24%" />
<col style="width: 48%" />
<col style="width: 11%" />
</colgroup>
<thead>
<tr>
<th colspan="2" style="text-align: left;">基本領域</th>
<th style="text-align: left;">設定内容</th>
<th style="text-align: left;">critical</th>
</tr>
</thead>
<tbody>
<tr>
<td colspan="2" style="text-align: left;">Version</td>
<td style="text-align: left;">Version 2</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;">Signature Algorithm</td>
<td style="text-align: left;">SHA256 with RSA Encryption</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td rowspan="3" style="text-align: left;">Issuer</td>
<td style="text-align: left;">Country</td>
<td style="text-align: left;">C=JP</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td style="text-align: left;">Organization</td>
<td style="text-align: left;">O= Japan Registry Services Co., Ltd.</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td style="text-align: left;">Common Name</td>
<td style="text-align: left;"><p>（1）ドメイン認証型</p>
<p>CN=JPRS Domain Validation Authority - G4</p>
<p>（2）組織認証型</p>
<p>CN=JPRS Organization Validation Authority $2013 G4</p></td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;">This Update</td>
<td style="text-align: left;">例) 2008/3/1 00:00:00 GMT</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;">Next Update</td>
<td style="text-align: left;">例) 2008/3/5 00:00:00 GMT</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td rowspan="3" style="text-align: left;">Revoked Certificates</td>
<td style="text-align: left;">Serial Number</td>
<td style="text-align: left;">例) 0123456789</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td style="text-align: left;">Revocation Date</td>
<td style="text-align: left;">例) 2008/3/1 00:00:00 GMT</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td style="text-align: left;">Reason Code</td>
<td style="text-align: left;">失効理由コード（※）</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;">拡張領域</td>
<td style="text-align: left;">設定内容</td>
<td style="text-align: left;">critical</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;">CRL Number</td>
<td style="text-align: left;">CRL番号</td>
<td style="text-align: left;">n</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;">Authority Key Identifier</td>
<td style="text-align: left;">Issuer公開鍵のSHA-1ハッシュ値（160ビット）</td>
<td style="text-align: left;">n</td>
</tr>
</tbody>
</table>

※：本CAは、CRLのReason Codeの項目に表7.2.2.1に定めるいずれかの失効理由コードを記載する。ただし、失効理由コードが「#0 unspecified」である場合は、Reason Codeの項目自体を記載しない。

表7.2.3 CRLプロファイル（IssuerがJPRS DV RSA CA 2024 G1またはJPRS OV RSA CA 2024 G1の証明書に適用）

<table>
<colgroup>
<col style="width: 15%" />
<col style="width: 24%" />
<col style="width: 48%" />
<col style="width: 11%" />
</colgroup>
<thead>
<tr>
<th colspan="2" style="text-align: left;">基本領域</th>
<th style="text-align: left;">設定内容</th>
<th style="text-align: left;">critical</th>
</tr>
</thead>
<tbody>
<tr>
<td colspan="2" style="text-align: left;">Version</td>
<td style="text-align: left;">Version 2</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;">Signature Algorithm</td>
<td style="text-align: left;">SHA384 with RSA Encryption</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td rowspan="3" style="text-align: left;">Issuer</td>
<td style="text-align: left;">Country</td>
<td style="text-align: left;">C=JP</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td style="text-align: left;">Organization</td>
<td style="text-align: left;">O= Japan Registry Services Co., Ltd.</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td style="text-align: left;">Common Name</td>
<td style="text-align: left;"><p>（1）ドメイン認証型</p>
<p>CN= JPRS DV RSA CA 2024 G1</p>
<p>（2）組織認証型</p>
<p>CN= JPRS OV RSA CA 2024 G1</p></td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;">This Update</td>
<td style="text-align: left;">例) 2008/3/1 00:00:00 GMT</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;">Next Update</td>
<td style="text-align: left;">例) 2008/3/5 00:00:00 GMT</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td rowspan="3" style="text-align: left;">Revoked Certificates</td>
<td style="text-align: left;">Serial Number</td>
<td style="text-align: left;">例) 0123456789</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td style="text-align: left;">Revocation Date</td>
<td style="text-align: left;">例) 2008/3/1 00:00:00 GMT</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td style="text-align: left;">Reason Code</td>
<td style="text-align: left;">失効理由コード（※）</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;">拡張領域</td>
<td style="text-align: left;">設定内容</td>
<td style="text-align: left;">Critical</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;">CRL Number</td>
<td style="text-align: left;">CRL番号</td>
<td style="text-align: left;">n</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;">Authority Key Identifier</td>
<td style="text-align: left;">Issuer公開鍵のSHA-1ハッシュ値（160ビット）</td>
<td style="text-align: left;">n</td>
</tr>
</tbody>
</table>

※：本CAは、CRLのReason Codeの項目に表7.2.2.1に定めるいずれかの失効理由コードを記載する。ただし、失効理由コードが「#0 unspecified」である場合は、Reason Codeの項目自体を記載しない。

表7.2.4 CRLプロファイル（IssuerがJPRS DV ECC CA 2024 G1またはJPRS OV ECC CA 2024 G1の証明書に適用）

<table>
<colgroup>
<col style="width: 15%" />
<col style="width: 24%" />
<col style="width: 48%" />
<col style="width: 11%" />
</colgroup>
<thead>
<tr>
<th colspan="2" style="text-align: left;">基本領域</th>
<th style="text-align: left;">設定内容</th>
<th style="text-align: left;">critical</th>
</tr>
</thead>
<tbody>
<tr>
<td colspan="2" style="text-align: left;">Version</td>
<td style="text-align: left;">Version 2</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;">Signature Algorithm</td>
<td style="text-align: left;">ecdsa-with-SHA384</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td rowspan="3" style="text-align: left;">Issuer</td>
<td style="text-align: left;">Country</td>
<td style="text-align: left;">C=JP</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td style="text-align: left;">Organization</td>
<td style="text-align: left;">O= Japan Registry Services Co., Ltd.</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td style="text-align: left;">Common Name</td>
<td style="text-align: left;"><p>（1）ドメイン認証型</p>
<p>CN= JPRS DV ECC CA 2024 G1</p>
<p>（2）組織認証型</p>
<p>CN= JPRS OV ECC CA 2024 G1</p></td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;">This Update</td>
<td style="text-align: left;">例) 2008/3/1 00:00:00 GMT</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;">Next Update</td>
<td style="text-align: left;">例) 2008/3/5 00:00:00 GMT</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td rowspan="3" style="text-align: left;">Revoked Certificates</td>
<td style="text-align: left;">Serial Number</td>
<td style="text-align: left;">例) 0123456789</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td style="text-align: left;">Revocation Date</td>
<td style="text-align: left;">例) 2008/3/1 00:00:00 GMT</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td style="text-align: left;">Reason Code</td>
<td style="text-align: left;">失効理由コード（※）</td>
<td style="text-align: left;">-</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;">拡張領域</td>
<td style="text-align: left;">設定内容</td>
<td style="text-align: left;">Critical</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;">CRL Number</td>
<td style="text-align: left;">CRL番号</td>
<td style="text-align: left;">n</td>
</tr>
<tr>
<td colspan="2" style="text-align: left;">Authority Key Identifier</td>
<td style="text-align: left;">Issuer公開鍵のSHA-1ハッシュ値（160ビット）</td>
<td style="text-align: left;">n</td>
</tr>
</tbody>
</table>

※：本CAは、CRLのReason Codeの項目に表7.2.2.1に定めるいずれかの失効理由コードを記載する。ただし、失効理由コードが「#0 unspecified」である場合は、Reason Codeの項目自体を記載しない。

### 7.2.1 バージョン番号

本CAは、CRLバージョン2を適用する。

### 7.2.2 CRLとCRLエントリー拡張

本CAが発行するCRLには、次の拡張領域を使用する。

・reasoncode(OID 2.5.29.21)

失効理由コードが「#0 unspecified」でない限り、2023年7月15日以降に失効する証明書については、CRLのReason Codeの項目に失効理由コードを含めるものとする。

本CAのCRLのReason Codeの項目には、次の表の「#0 unspecified」以外の失効理由を記載するものとする。

表 7.2.2.1 失効理由コード

<table>
<colgroup>
<col style="width: 44%" />
<col style="width: 55%" />
</colgroup>
<thead>
<tr>
<th style="text-align: left;">失効理由コード</th>
<th style="text-align: left;">この失効理由コードを指定する事由</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: left;">#0 unspecified</td>
<td style="text-align: left;"><p>該当なし</p>
<p>・以下に定める失効事由のいずれにも該当しない場合</p></td>
</tr>
<tr>
<td style="text-align: left;">#1 keyCompromise</td>
<td style="text-align: left;"><p>鍵の危殆化</p>
<p>・証明書利用者の私有鍵が危殆化した、またはその可能性がある場合</p></td>
</tr>
<tr>
<td style="text-align: left;">#3 affiliationChanged</td>
<td style="text-align: left;"><p>組織情報の変更</p>
<p>・証明書記載情報のうち組織の名称その他の組織に関する情報に変更が生じた場合</p></td>
</tr>
<tr>
<td style="text-align: left;">#4 superseded</td>
<td style="text-align: left;"><p>証明書の取替</p>
<p>・その他の失効事由に該当しない場合において、既存の証明書を取り替える場合</p></td>
</tr>
<tr>
<td style="text-align: left;">#5 cessationOfOperation</td>
<td style="text-align: left;"><p>運用の停止</p>
<p>・証明書記載情報に含まれるドメイン名の全部または一部について、その管理権限を失った場合</p>
<p>・Webサイトの停止に伴い証明書を使用しなくなった場合</p></td>
</tr>
<tr>
<td style="text-align: left;">#9 privilegeWithdrawn</td>
<td style="text-align: left;"><p>権限のはく奪</p>
<p>・証明書利用者がご利用条件に違反した場合</p></td>
</tr>
</tbody>
</table>

## 7.3 OCSPのプロファイル

### 7.3.1 バージョン番号

本CAは、OCSPバージョン1を適用する。

### 7.3.2 OCSP拡張

本CP/CPS「7.1 証明書のプロファイル」に記載する。OCSP応答の singleExtensionsには、reasonCode（OID 2.5.29.21）CRLエントリー拡張を含めてはならない。

# 8. 準拠性監査と他の評価

## 8.1 監査の頻度

当社は、本CAの運用が本CP/CPSに準拠して行われているかについて、年に1回以上の監査を行う。

新しい利用者向け証明書を発行するために使用することができる証明書は、本CP/CPS「7.1.5 名前制約」に従って技術的に制約され、かつ本CP/CPS「8.7 内部監査」に従って監査されているか、制約はされていないものの、このセクションの残りすべての要件に従って完全に監査されているかのいずれかである必要がある。証明書は、X.509v3 basicConstraints 拡張領域を含み、cA boolean が true に設定された、ルート CA 証明書または下位 CA 証明書 である場合、新規証明書の発行に使用可能と見なされる。

本 CA が利用者向け証明書を発行している期間は、監査期間の連続したシーケンスに分割されるものとする。監査期間は 1 年を超えてはならない。

本 CA が、本 CP/CPS「8.4 監査で扱われる事項」に記載された監査スキームに準拠していることを示す現在有効な監査レポートを有している場合、発行前準備の評価は必要ない。

本 CA が、本 CP/CPS「8.4 監査で扱われる事項」に記載された監査スキームのいずれかに準拠していることを示す現在有効な監査レポートを有していない場合、本CA は、パブリックな信頼された利用者向け証明書を発行する前に、本CP/CPS「8.4 監査で扱われる事項」に記載された監査スキームのいずれかに基づき、適用される規準に従って実施される時点での準備状況の評価を完了しなければならない。当該準備状況の評価は、パブリック証明書を発行する 12 か月前までに完了し、最初のパブリック証明書を発行してから 90 日以内に、当該スキームに基づく完全な監査を受けなければならない。

## 8.2 監査者の身元／資格

本 CA の監査は、公認監査人が行わなければならない。公認監査人とは、以下の資格および技能を総合的に有する自然人、法人、または自然人もしくは法人のグループをいう。

1\. 監査の対象から独立している。

2\. 適格な監査スキームで指定されている条件に対応する監査を実施できる（本 CP/CPS「8.4 監査で扱われる事項」を参照）。

3\. 公開鍵基盤技術、情報セキュリティツールおよび技法、情報技術およびセキュリティ監査、および第三者認証機能の審査に熟達している人材を採用している。

4\. （WebTrust 規格に基づいて実施される監査の場合）WebTrust による実施許可を受けている。

5\. 法律、政府の規制、または職業倫理に準拠している。

6\. 国内政府監査機関の場合を除き、少なくとも 100 万米ドルの補償を保険範囲とする業務上の過失および不備に対する責任保険に加入している。

## 8.3 監査者と被監査者の関係

監査人は、監査に関する事項を除き、被監査部門の業務から独立した立場にあるものとする。監査の実施にあたり、被監査部門は監査に協力するものとする。

## 8.4 監査で扱われる事項

監査は、本CAの運用の本CP/CPSに対する準拠性を中心として行う。

また、WebTrust認証を受ける際は、次の規準に基づいて行われる。

- WebTrust for CAs

- WebTrust for CAs - SSL Baseline

- WebTrust for CAs - Network Security

監査が継続的にスキームの要件に従って実施されるようにするため、定期的な監査手順や説明責任手順を組み込む必要がある。

監査は、本 CP/CPS「8.2 監査人の身分と資格」の規定どおり、公認監査人によって実施される必要がある。

外部委託先がエンタープライズ RA でない場合、本 CA は、本 CP/CPS「8.4 監査で扱われる事項」に記載された容認されている監査スキームの基になる監査標準に従って発行された監査レポートを取得するものとする。

この監査レポートは、外部委託先の遂行する監査が外部委託先の運用規定または本CAの 本CP/CPS に準拠するかどうかについての意見を提供する。外部委託先が条件に準拠しないという意見である場合、本CA は、外部委託先による委託職務の履行継続を許可しないものとする。

外部委託先による監査期間は、1年を超えないものとする（この場合、本CAの監査と整合することが望ましい）。

## 8.5 不備の結果としてとられる処置

本CAは、監査報告書で指摘された事項に関し、すみやかに必要な是正措置を行う。

## 8.6 監査結果の開示

WebTrust認証に関する監査結果は、監査人から本CAに対して報告される。

本CA は、監査期間の終了後3か月以内に監査報告書を公開する。

監査報告書の公開が3か月を超えて遅延した場合、本CA は監査人によって署名された説明文書を提供するものとする。

## 8.7 内部監査

本CAは、CAの運用が本CP/CPSおよびBaseline Requirementsに準拠して行われているかについて内部監査を行い、Baseline Requirementsで定められた要件に基づき、証明書の無作為のサンプル抽出による定期的な検証を実施する。

本CAが証明書を発行する期間中、本CAは、前の自己監査でサンプルが取得された直後から始まる期間に発行されたBaseline Requirementsに準拠した証明書のうち2つ以上、または 3％のいずれか多い方の数の証明書 をサンプルとしてランダムに選択し、少なくとも四半期に1回の頻度で自己監査を実施して、本CP/CPSおよびBaseline Requirementsへの準拠を監視し、サービス品質を厳密 に管理するものとする。

2025年3月15日以降、本CAは、選択されたサンプルセット内にある証明書の技術的な正確性を検証するためのリンティングプロセスを、対象の証明書について以前に実行されたリンティングとは別に使用する。

本CP/CPS「8.4 監査で扱われる事項」に規定されている条件を満たす年次監査対象の外部委託先を除き、本CAは、最後のサンプルが取得された直後から始まる期間に外部委託先によって検証されたBaseline Requirementsに準拠した証明書のうち2つ以上、あるいは3%のいずれか多い方の数の証明書をサンプルとしてランダムに選択し、本CAが雇用する検証スペシャリストに四半期に1回の監査を継続的に実施させることで、外部委託先によって発行された証明書または検証された情報を含む証明書のサービス品質を厳密に管理するものとする。本CAは、各外部委託先の運用および手順をレビューして、外部委託先がBaseline Requirements、ならびに本CP/CPSに準拠していることを保証するものとする。本CAは、年1回の頻度で、各外部委託先がBaseline Requirementsに準拠しているかどうかを内部監査するものとする。本CAは、少なくとも四半期に1回の頻度で、最後のサンプルが取得された直後から始まる期間においてCAによって発行された証明書のうち2つ以上、あるいは3%のいずれか多い方の数の証明書をサンプルとしてランダムに選択し、CP/CPSに準拠していることを確認する。

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

## 9.1 料金

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

別途、ご利用条件に規定する。

### 9.1.2 証明書アクセス料金

規定しない。

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

規定しない。

### 9.1.4 その他のサービス料金

別途、ご利用条件に規定する。

### 9.1.5 返金ポリシー

別途、ご利用条件に規定する。

## 9.2 財務的責任

本CAは、本CAの運用維持にあたり、十分な財務的基盤を維持するものとする。

### 9.2.1 保険適用範囲

規定しない。

### 9.2.2 その他の資産

規定しない。

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

規定しない。

## 9.3 企業情報の機密性

### 9.3.1 機密情報の範囲

本CAが保持する個人情報および組織情報は、証明書、CRLおよび本CP/CPSの一部として明示的に公表されたものを除き、機密保持対象として扱われる。

本CAは、法の定めによる場合および証明書利用者による事前の承諾を得た場合を除いてこれらの情報を社外に開示しない。かかる法的手続、司法手続、行政手続あるいは法律で要求されるその他の手続に関連してアドバイスする法律顧問および財務顧問に対し、本CAは機密保持対象として扱われる情報を開示することができる。また会社の合併、買収あるいは再編成に関連してアドバイスする弁護士、会計士、金融機関およびその他の専門家に対しても、本CAは機密保持対象として扱われる情報を開示することができる。

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

証明書およびCRLに含まれている情報は機密保持対象外として扱う。その他、次の状況におかれた情報は機密保持対象外とする。

・本CAの過失によらず知られた、あるいは知られるようになった情報

・本CA以外の出所から、機密保持の制限無しに本CAに知られた、あるいは知られるようになった情報

・本CAによって独自に開発された情報

・開示に関して証明書利用者によって承認されている情報

### 9.3.3 機密情報を保護する責任

本CAは、法の定めによる場合および証明書利用者による事前の承諾を得た場合に機密情報を開示することがある。その際、その情報を知り得た者は、契約あるいは法的な制約によりその情報を第三者に開示させない。

## 9.4 個人情報の保護

### 9.4.1 個人情報保護プラン

当社のプライバシーポリシーについては、ホームページ（ https://jprs.jp/privacy.html ）にて公表する。

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

当社のホームページ（ https://jprs.jp/privacy.html ）にて公表するプライバシーポリシーにて定める。

### 9.4.3 個人情報とみなされない情報

当社は、当社のホームページ（ https://jprs.jp/privacy.html ）にて公表するプライバシーポリシーに定める情報以外は、個人情報とみなさない。

### 9.4.4 個人情報の保護責任

当社のホームページ（ https://jprs.jp/privacy.html ）にて公表するプライバシーポリシーにて定める。

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

当社のホームページ（ https://jprs.jp/privacy.html ）にて公表するプライバシーポリシーにて定める。

### 9.4.6 司法または行政手続に基づく情報開示

当社のホームページ（ https://jprs.jp/privacy.html ）にて公表するプライバシーポリシーにて定める。

### 9.4.7 その他の情報開示要件

当社のホームページ（ https://jprs.jp/privacy.html ）にて公表するプライバシーポリシーにて定める。

## 9.5 知的財産権

特段の合意がなされない限り、以下の情報に関するすべての知的財産権は当社の権利に属するものとする。

・本CAが発行した証明書およびサイトシール、証明書の失効情報

・本CP/CPSおよび関連文書

・本CAの公開鍵および秘密鍵

・当社より提供されたソフトウェア

本CP/CPSは、「クリエイティブ・コモンズ表示 - 改変禁止 4.0 国際ライセンス」の下に公開する。

< https://creativecommons.org/licenses/by-nd/4.0/ >

## 9.6 表明保証

### 9.6.1 CA業務の表明保証

本CAは、CAの業務を遂行するにあたり次の義務を負う。

・CA私有鍵のセキュアな生成・管理

・RAからの申請に基づいた証明書の正確な発行・失効管理

・CAのシステム稼動の監視・運用

・CRLの発行・公表

### 9.6.2 RA業務の表明保証

本CAは、RAの業務を遂行するにあたり次の義務を負う。

・登録端末のセキュアな環境への設置・運用

・証明書発行・失効申請におけるCAへの正確な情報伝達

・証明書失効申請におけるCAへの運用時間中の速やかな情報伝達

・リポジトリの維持管理

### 9.6.3 証明書利用者の表明保証

本CAは、ご利用条件に規定することで、申請者が本項の誓約と保証を本CAおよび証明書の受益者のために履行することを要求するものとする。

本CAは、証明書の発行前に、本CAおよび証明書の受益者のため、申請者よりご利用条件に対する同意を取得する。

本CAは、ご利用条件が申請者に対して、法的強制力を有することを保証するプロセスを導入する。

ご利用条件には、以下の義務と保証を課す条項を含める。

**1. 情報の正確性：** 証明書申請時、および本CAが証明書の発行に関連して要求する場合、常に正確かつ完全な情報を本CAに提供する義務および保証。

**2. 私有鍵の保護：** 申請者は、要求された証明書に含まれる公開鍵に対応する私有鍵の管理を保証し、機密性を保持し、常に適切に保護するために、あらゆる合理的な手段を講じる義務および保証。

**3. 証明書の受領：** 証明書利用者が証明書の内容を確認し、正確性を検証する義務および保証

**4. 証明書の使用：** 証明書に記載のsubjectAltNameでアクセス可能なサーバーにのみ証明書をインストールし、 適用されるすべての法律に準拠し、ご利用条件にのみ従って証明書を使用する義務および保証。

**5. 報告および失効：** 以下の義務および保証。

- 証明書に含まれる公開鍵に関連する証明書利用者の私有鍵の不正使用または危殆化の事実または疑いがある場合、速やかに証明書の失効を要求し、証明書および関連する私有鍵の使用を停止すること。

- 証明書に記載される情報が間違いもしくは不正確であり、または間違いもしくは不正確になった場合、速やかに証明書の失効を要求し、その使用を停止すること。

**6. 証明書の使用停止：** 鍵の危殆化を理由に証明書が失効した場合、証明書に含まれる公開鍵に対応する私有鍵の使用をすべて速やかに停止する義務および保証。

**7. 応答性：** 鍵の危殆化または証明書の不正使用に関する本CAの指示に対し、所定の期間内に対応する義務。

**8. 承認および受諾：** 申請者がご利用条件に違反した場合、あるいは本CP/CPSまたはBaseline Requirementsによって証明書の失効が要求された場合、本CAは直ちに証明書を失効する権利を有することを認め、承諾すること。

### 9.6.4 検証者の表明保証

検証者は、本CP/CPSに定める諸事項を遵守することについて保証するものとする。また、検証者は、本CP/CPSに遵守しない場合、すべての責任を有するものとする。

### 9.6.5 その他関係者の表明保証

規定しない。

## 9.7 無保証

本CAは、本CP/CPS「9.6.1 CA業務の表明保証」に規定する保証に関連して発生するいかなる間接損害、特別損害、付随的損害または派生的損害に対する責任を負わず、また、いかなる逸失利益、データの紛失またはその他の間接的もしくは派生的損害に対する責任を負わない。

## 9.8 責任の制限

本CP/CPS「9.6.1 CA業務の表明保証」の内容に関し、次の場合、本CAは責任を負わないものとする。

・本CAに起因しない不法行為、不正使用または過失等により発生する一切の損害

・証明書利用者が自己の義務の履行を怠ったために生じた損害

・証明書利用者のシステムに起因して発生した一切の損害

・本CA、証明書利用者のハードウェア、ソフトウェアの瑕疵、不具合あるいはその他の動作自体によって生じた損害

・本CAの責に帰することのできない事由で証明書およびCRLに公開された情報に起因する損害

・本CAの責に帰することのできない事由で正常な通信が行われない状態で生じた一切の損害

・証明書の使用に関して発生する取引上の債務等、一切の損害

・現時点の予想を超えた、ハードウェア的あるいはソフトウェア的な暗号アルゴリズム解読技術の向上に起因する損害

・天変地異、地震、噴火、火災、津波、水災、落雷、戦争、動乱、テロリズムその他の不可抗力に起因する、本CAの業務停止に起因する一切の損害

・証明書発行に必要な情報のCTログサーバーへの登録・公開に付随または関連して発生した一切の損害

## 9.9 補償

本CAが発行する証明書を申請、受領、信頼した時点で、証明書利用者には、本CAおよび関連する組織等に対する損害賠償責任および保護責任が発生するものとする。当該責任の対象となる事象には、損失、損害、訴訟、あらゆる種類の費用負担の原因となるようなミス、怠慢な行為、各種行為、履行遅滞、不履行等の各種責任が含まれる。なお、証明書利用者の損害に関する補償については、ご利用条件で定める。

## 9.10 有効期間と終了

### 9.10.1 有効期間

本CP/CPSは、本CAのサーバー証明書発行サービス運営会議の承認により有効となる。本CP/CPS「9.10.2 終了」に規定する終了以前に本CP/CPSが無効となることはない。

### 9.10.2 終了

本CP/CPSは、「9.10.3 終了の効果と効果継続」に規定する内容を除き、本CAの終了と同時に無効となる。

### 9.10.3 終了の効果と効果継続

証明書利用者と本CAとの間で利用契約等を終了する場合、または、本CA自体を終了する場合であっても、その性質上存続されるべき条項は終了の事由を問わず証明書利用者、検証者および本CAに適用されるものとする。

## 9.11 関係者間の個別通知と連絡

当社は、証明書利用者および検証者に対する必要な通知をホームページ上、電子メールまたは書面等によって行う。

## 9.12 改訂

### 9.12.1 改訂手続

本CP/CPSは、本CAの判断によって適宜改訂され、本CA のサーバー証明書発行サービス運営会議の承認によって発効する。

### 9.12.2 通知方法および期間

本CP/CPSを変更した場合、すみやかに変更した本CP/CPSを公表することにより、証明書利用者に対しての告知とする。

### 9.12.3 オブジェクト識別子が変更されなければならない場合

規定しない。

## 9.13 紛争解決手続

証明書の利用に関し、本CAに対して訴訟、仲裁を含む解決手段に訴えようとする場合、本CAに対して事前にその旨を通知するものとする。なお、JPRSサーバー証明書発行サービスに関する全ての紛争の第一審の専属的合意管轄裁判所を東京地方裁判所とする。

## 9.14 準拠法

本CA、証明書利用者の所在地にかかわらず、本CP/CPSの解釈、有効性および証明書の利用にかかわる紛争については、日本国の法律が適用されるものとする。

## 9.15 適用法の遵守

本CAは、本CA事業および発行する証明書に適用されるすべての法律に従い、証明書を発行しそのPKIを運用するものとする。

## 9.16 雑則

### 9.16.1 完全合意条項

規定しない。

### 9.16.2 権利譲渡条項

別途、ご利用条件に規定する。

### 9.16.3 分離条項

Baseline Requirementsと本CAの運用および証明書の発行を行う地域における法律、規制、行政命令（以下「法律」とする）が矛盾する場合、本CAは、当該地域において要件を合法かつ有効とするために必要な最小限の範囲で、矛盾する要件を修正することができる。これは、該当する法律の対象となる本CAの運用または証明書の発行に限り適用される。本項に基づく要件の修正を行う場合、本CAは、直ちに（また、修正された要件に基づいた証明書を発行する前に）、本CAのCP/CPSの9.16.3項に、本項に基づく要件の修正を要求する法律への参照および修正内容について詳細な言及を記載しなければならない。本CAは、修正された要件に基づいた証明書を発行する前に、CA/Browser Forumが本項に基づく要件の修正の可能性について検討できるようにするため、本CAのCP/CPSに新たに追加された情報について、questions@cabforum.org宛にメールを送信するとともに、送信した内容が https://cabforum.org/pipermail/public/ （または CA/Browser Forum が指定するその他の メールアドレスやリンク）で閲覧可能な公開メールアーカイブにインデックスされたことを確認するものとする。

本項に基づき有効となる本CAの実務に対するいかなる修正も、法律が適用されなくなった場合、またはBaseline Requirementsが修正されBaseline Requirementsと法律を同時に遵守することが可能となった場合は、本項に基づき修正された要件による実務を中止する。

本項に基づく要件の修正、本CAのCP/CPSの修正、およびCA/Browser Forumへの通知は、90日以内に行われる必要がある。

### 9.16.4 強制執行条項

本CP/CPS「9.13 紛争解決手続」およびご利用条件に規定する。

### 9.16.5 不可抗力条項

別途、ご利用条件に規定する。

## 9.17 その他の条項

適用外とする。