C-6-4-5

LGPKI
技術仕様書

第２.1 版

令和４年３月８日

地方公共団体情報システム機構

技術仕様書１ はじめに ...................................................................................................................... 1
１.１.

概要 ................................................................................................................... 1

１.２.

各章の位置付け.................................................................................................. 1

１.３.

前提 ................................................................................................................... 2

１.４.

見直し ............................................................................................................... 2

２ LGPKI コンポーネント仕様 .......................................................................................... 3
２.１.

概要 ................................................................................................................... 3

２.２.

第三次 LGPKI 組織 CA...................................................................................... 3

２.３.

第四次 LGPKI 組織 CA R2................................................................................. 4

２.４.

第四次 LGPKI アプリケーション CA R2（LGWAN 内部環境用） ...................... 5

２.５.

リポジトリ等 ..................................................................................................... 5

２.５.１.

第四次 LGPKI 公開リポジトリ ......................................................................5２.５.２.

第四次 LGPKI 統合リポジトリ ......................................................................6

２.６.

第四次 LGPKI 証明書検証サーバ ....................................................................... 6

２.７.

Security Communication RootCA2 ..................................................................... 6

２.８.

Security Communication RootCA3 ..................................................................... 7

２.９.

セコムパスポート for Web SR3.0 CA ................................................................. 7

２.１０.

セコムパスポート for PublicID CA ................................................................ 7

２.１１.

セコム公開リポジトリ .................................................................................... 8

２.１２.

セコム OCSP レスポンダ................................................................................ 8

２.１３.

エンドエンティティ ....................................................................................... 8

２.１４.

LGPKI における認証情報............................................................................. 10

２.１４.１.

認証情報の公開 ........................................................................................10２.１４.２.

相互認証証明書の格納･削除 ....................................................................12２.１４.３.

自己署名証明書及びリンク証明書の格納・削除 .....................................13２.１４.４.

失効情報の格納と更新 .............................................................................13

３ アプリケーション仕様 ................................................................................................ 15
３.１.

概要 ................................................................................................................. 15i

技術仕様書

３.２.

証明書と失効情報（CRL/ARL）のプロファイル.............................................. 15

３.３.

証明書と失効情報（CRL/ARL）の公開方法 .................................................... 18

３.４.

推奨署名アルゴリズム ..................................................................................... 18

３.４.１.

アルゴリズム................................................................................................18

３.４.２.

鍵長 ..............................................................................................................18

３.４.３.

認証パスの構築・検証方法 ..........................................................................19

３.５.

LGPKI における名前と DIT の規定 ................................................................. 19

３.５.１.

識別名、相対識別名.....................................................................................19

３.５.２.

エンコードタイプ ........................................................................................19

３.５.３.

issuerAltName 及び subjectAltName ...............................................................19

４ 証明書検証サーバの利用 ............................................................................................ 20
４.１.

概要 ................................................................................................................. 20

４.２.

証明書検証サーバ用証明書（VA 証明書） ........................................................ 20

４.３.

クライアント要件 ............................................................................................ 20

４.３.１.

クライアント側の前準備 .............................................................................20

４.４.

証明書検証サーバ通信プロトコル .................................................................... 20

４.５.

証明書検証サーバのアクセス制御 .................................................................... 20

５ OCSP レスポンダの利用 ............................................................................................. 22
６ ディレクトリプロファイル ......................................................................................... 23
６.１.

LGPKI における DIT 構造 ............................................................................... 23

６.２.

DIT の名前形式 ............................................................................................... 24

６.３.

リポジトリ等に格納される情報........................................................................ 24

６.３.１.

LGPKI コンテナ ...........................................................................................24

６.３.２.

CA エントリ .................................................................................................26

６.４.

リポジトリ等のインタフェース仕様................................................................. 32

６.５.

リポジトリ等のアクセス制御 ........................................................................... 33

６.５.１.

認証ポリシー................................................................................................33

６.５.２.

アクセス制御ポリシー .................................................................................33

ii

技術仕様書

１

はじめに
本仕様書は、LGPKI を構成する各 CA 及び LGPKI を利用するアプリケーションに関する技
術仕様を定めるものである。本書の対象は、次の技術要件とする。


LGPKI を構成する各コンポーネントが満たすべき技術要件



LGPKI を利用するアプリケーションが満たすべき技術要件

１.１. 概要LGPKI は、第三次 LGPKI 組織 CA 及び第四次 LGPKI 組織 CA R2（以下「組織 CA 等」という。）を中心とした認証基盤である。
本仕様書では、LGPKI を利用するために必要となる機能と仕様を定める。ただし、外部サービスを利用する機能については、外部サービスの規程を参照するものとする。

１.２. 各章の位置付け（２章）LGPKI コンポーネント仕様
２章では、LGPKI を構成する PKI コンポーネントの概要と基本的な仕様について記述する。
対象とするコンポーネントの種類は以下のとおりとする。


第三次 LGPKI 組織 CA



第四次 LGPKI 組織 CA R2



第四次 LGPKI アプリケーション CA R2



第四次 LGPKI 公開リポジトリ



第四次 LGPKI 統合リポジトリ



第四次 LGPKI 証明書検証サーバ

Security Communication RootCA2（外部サービス）Security Communication RootCA3（外部サービス）

セコムパスポート for Web SR3.0 CA（外部サービス）

セコムパスポート for PublicID CA（外部サービス）

セコム公開リポジトリ（外部サービス）

セコム OCSP レスポンダ（外部サービス）

エンドエンティティ（３章）アプリケーション仕様
３章では、LGPKI を利用するアプリケーションが満たすべき機能を記述する。
また、この仕様書で記述するアプリケーションは、LGPKI を利用しデータに署名するソフト
ウェア（署名者）と署名されたデータを検証するソフトウェア（署名検証者）に位置付ける。
（４章）証明書検証サーバの利用
４章では、LGPKI の提供する証明書検証サーバを利用する際に満たすべき仕様について定め

1

技術仕様書る。
（６章）ディレクトリプロファイル
６章では、リポジトリ等のプロファイルについて定める。

１.３. 前提
政府認証基盤相互運用性仕様書（http://www.gpki.go.jp/session/）及び以下の標準等を考慮し、技術仕様を規定する。


IETF：Internet X.509 Public Key Certificate Infrastructure and CRL Profile

ITU-T：ITU-T RECOMMENDATION X.509 | ISO/IEC 9594-8

１.４. 見直し
本仕様書は情報通信技術の動向等を踏まえ必要に応じて見直すものとする。

2

技術仕様書２

LGPKI コンポーネント仕様

２.１. 概要
本章では、LGPKI を構成する各 PKI コンポーネントの概要と基本的な仕様について記述する。
なお、LGPKI を構成する PKI コンポーネントの概念図を以下に示す。

Ｌ
Ｇ
Ｗ
Ａ
Ｎ

第四次LGPKI統合リポジトリ
他認証ドメイン
LDAP
GPKI
ブリッジ
CA

OCSPレスポンダ
通信プロトコル
HTTP

利用者

LDAP

セコム
公開リポジトリ

第四次LGPKI公開リポジトリ

証明書検証
サーバ
通信プロトコル

セコム
OCSPレスポンダ

LDAP

第四次LGPKI
証明書検証サーバ

出力

出力

第四次
APCA R2

第三次
組織CA

第四次
組織
CA R2

セコム
CA

RA

RA

RA

RA

EE
（職責、利用者）

EE（サーバ、メール、
コードサイニング）

出力

登録局

EE
（サーバ ）

図 ２-1

EE
（暗通）

LGPKI 概念図

LGPKI は、組織 CA 等（組織 CA 等発行局及び登録局（以下「RA」という。
））、第四次 LGPKI
アプリケーション CAR2、第四次 LGPKI 公開リポジトリ及び第四次 LGPKI 統合リポジトリ（以下、総称して「リポジトリ等」という。）、第四次 LGPKI 証明書検証サーバ、セコムトラストシ
ステムズ株式会社の運用する認証サービス、セコム公開リポジトリ、セコム OCSP レスポンダから構成される。

２.２. 第三次 LGPKI 組織 CA
第三次 LGPKI 組織 CA は証明書の発行、失効、更新を行う。また各種証明書と失効情報（CRL/ARL）をリポジトリ等に格納する。

3

技術仕様書

第三次 LGPKI 組織 CA には RA が存在する。RA は証明書所有者の身元を保証し、証明書に含まれる公開鍵と一致する秘密鍵を確実に証明書所有者が持っていることを保証する。
第三次 LGPKI 組織 CA は以下の機能を備える。


自己署名証明書の発行及び第四次 LGPKI 統合リポジトリへの格納

証明書の発行、更新



エンドエンティティ（コンピュータシステムを含む）からの証明書発行要求の受け付け、証明書の発行、失効、更新自 CA が発行した証明書に関する失効要求の受け付け、失効情報の発行とリポジトリ等への格納

自 CA の各操作員の明確な権限分離が可能な証明書の発行･更新･失効

自 CA の鍵更新

２.３. 第四次 LGPKI 組織 CA R2
第四次 LGPKI 組織 CAR2 は他認証ドメインに属する CA（以下｢他 CA｣という。）の公開鍵を含む相互認証証明書の発行、失効、更新を行う。
第四次 LGPKI 組織 CAR2 は第四次 LGPKI 組織 CAR2 が発行した相互認証証明書を含む相互認証証明書ペアと、失効情報をリポジトリ等の第四次 LGPKI 組織 CAR2 エントリに格納する。
第四次 LGPKI 組織 CAR2 は証明書の発行、失効、更新を行う。また各種証明書と失効情報（CRL/ARL）をリポジトリ等に格納する。
第四次 LGPKI 組織 CAR2 には RA が存在する。RA は証明書所有者の身元を保証し、証明書に含まれる公開鍵と一致する秘密鍵を確実に証明書所有者が持っていることを保証する。また、相互認証証明書に含まれる公開鍵が確実にその CA の公開鍵であり、CA がこの公開鍵に一致する秘密鍵を持っていることを保証する。
第四次 LGPKI 組織 CAR2 は以下の機能を備える。


自己署名証明書の発行とリポジトリ等への格納

証明書の発行、更新

他 CA からの相互認証証明書発行要求の受け付けと検証、証明書の発行、更新

他 CA への相互認証証明書発行要求の作成、発行・更新された証明書の受け入れ

相互認証証明書ペアのリポジトリ等への格納

他 CA への相互認証証明書失効要求の作成

エンドエンティティ（コンピュータシステムを含む）からの証明書発行要求の受け付け、証明書の発行、失効、更新自 CA が発行した証明書に関する失効要求の受け付け、失効情報の発行とリポジトリ等への格納

4

技術仕様書

自 CA の各操作員の明確な権限分離が可能な証明書の発行･更新･失効

自 CA の鍵更新
なお、鍵更新、リンク証明書の仕様については、政府認証基盤相互運用性仕様書に定められた仕様に準拠するものとする。

２.４. 第四次 LGPKI アプリケーション CA R2（LGWAN 内部環境用）
第四次 LGPKI アプリケーション CA は証明書の発行、失効、更新を行う。また各種証明書と失効情報（CRL）を第四次 LGPKI 統合リポジトリに格納する。
第四次 LGPKI アプリケーション CA には RA が存在する。RA は証明書所有者の身元を保証し、証明書に含まれる公開鍵と一致する秘密鍵を確実に証明書所有者が持っていることを保証する。
第四次 LGPKI アプリケーション CA は以下の機能を備える。


自己署名証明書の発行と第四次 LGPKI 統合リポジトリへの格納

証明書の発行、更新



エンドエンティティ（コンピュータシステムを含む）からの証明書発行要求の受け付け、証明書の発行、失効、更新自 CA が発行した証明書に関する失効要求の受け付け、失効情報の発行と第四次 LGPKI 統合リポジトリへの格納自 CA の各操作員の明確な権限分離が可能な証明書の発行･更新･失効

自 CA の鍵更新

２.５. リポジトリ等
２.５.１. 第四次 LGPKI 公開リポジトリ
第四次 LGPKI 公開リポジトリは、証明書の有効性検証に必要な各種証明書、CRL/ARL を格納する。また、LDAPv3(389/tcp)を備えており、各 PKI コンポーネントからの証明書、CRL/ARLの検索、取り出し、格納が行える。
第四次 LGPKI 公開リポジトリは以下の機能を備える。


第四次 LGPKI 組織 CA R2 の自己署名証明書の格納

相互認証証明書及び相互認証証明書ペアの格納

CRL/ARL の格納



証明書、CRL/ARL の検索

他リポジトリとの連携（リフェラル）
他のリポジトリとの連携に関しては、LDAPv3 リフェラルを使うことを前提とする。

5

技術仕様書２.５.２. 第四次 LGPKI 統合リポジトリ
第四次 LGPKI 統合リポジトリは、証明書の有効性検証に必要な各種証明書、CRL/ARL を格納する。また、LDAPv3(389/tcp)を備えており、各 PKI コンポーネントからの証明書、CRL/ARLの検索、取り出し、格納が行える。
第四次 LGPKI 統合リポジトリは以下の機能を備える。


第三次 LGPKI 組織 CA の自己署名証明書の格納



第四次 LGPKI 組織 CA R2 の自己署名証明書の格納



第四次 LGPKI アプリケーション CA R2 の自己署名証明書の格納



CRL/ARL の格納



証明書、CRL/ARL の検索

２.６. 第四次 LGPKI 証明書検証サーバ
第四次 LGPKI 証明書検証サーバは、検証要求者が指定した証明書の妥当性を検証し、その検証要求者に証明書の検証結果を返すサーバである。証明書認証パス構築と各証明書の有効性に関する検証も可能なプロトコルを使用する。
第四次 LGPKI 証明書検証サーバは相互運用に関する機能として以下を備える。


第四次 LGPKI 証明書検証サーバ自身の証明書の発行要求、発行された証明書の受け入れ



検証要求者からの証明書検証要求受け付け

認証パス構築

認証パス検証（指定されたポリシーによるチェック等）



検証要求者への証明書検証結果の送信

２.７. Security Communication RootCA2
Security Communication RootCA2 はセコムトラストシステム株式会社が運用するパブリックな Root 認証局である。Security Communication RootCA2 は証明書の発行、失効、更新を行う。
また各種証明書と失効情報（CRL）をセコム公開リポジトリに格納する。Security Communication
RootCA2 には RA が存在する。RA は証明書所有者の身元を保証し、証明書に含まれる公開鍵と一致する秘密鍵を確実に証明書所有者が持っていることを保証する。
Security Communication RootCA2 の備える機能については、「Security Communication RootCA
認証運用規定」及び「Security Communication RootCA 下位 CA 証明書ポリシー」を参照のこと。（https://repository.secomtrust.net/SC-Root2/）

6

技術仕様書２.８. Security Communication RootCA3
Security Communication RootCA3 はセコムトラストシステム株式会社が運用するパブリックな Root 認証局である。Security Communication RootCA3 は証明書の発行、失効、更新を行う。
また各種証明書と失効情報（CRL）をセコム公開リポジトリに格納する。Security Communication
RootCA3 には RA が存在する。RA は証明書所有者の身元を保証し、証明書に含まれる公開鍵と一致する秘密鍵を確実に証明書所有者が持っていることを保証する。
Security Communication RootCA3 の備える機能については、「Security Communication RootCA
認証運用規定」及び「Security Communication RootCA 下位 CA 証明書ポリシー」を参照のこと。（https://repository.secomtrust.net/SC-Root3/）

２.９. セコムパスポート for Web SR3.0 CA
セコムパスポート for Web SR3.0 CA は Security Communication RootCA2 からサイニングを受けたセコムトラストシステム株式会社が運用するパブリックな Web サーバ証明書（OV 証明書）
を発行する CA である。セコムパスポート for Web SR3.0 CA は証明書の発行、失効、更新を行う。また各種証明書と失効情報（CRL）をセコム公開リポジトリに格納する。
セコムパスポート for Web SR3.0 CA には RA が存在する。RA は証明書所有者の身元を保証し、証明書に含まれる公開鍵と一致する秘密鍵を確実に証明書所有者が持っていることを保証する。
セコムパスポート for Web SR3.0 CA の備える機能については、「セコム電子認証基盤認証運用規程」及び「セコムパスポート for Web SR 認証局 証明書ポリシー」を参照のこと。
（https://repo1.secomtrust.net/spcpp/pfw/pfwsr3ca/）

２.１０.

セコムパスポート for PublicID CA
セ コ ム パ ス ポ ー ト for PublicID CA は Security Communication RootCA2 又 は Security
Communication RootCA3 からサイニングを受けたセコムトラストシステムズ株式会社が運用するパブリックなメール用証明書、コードサイニング証明書を発行するサービスである、セコム
パスポート for PublicID CA は証明書の発行、失効、更新を行う。また各種証明書と失効情報（CRL）をセコム公開リポジトリに格納する。
セコムパスポート for PublicID CA には RA が存在する。RA は証明書所有者の身元を保証し、証明書に含まれる公開鍵と一致する秘密鍵を確実に証明書所有者が持っていることを保証する。
セコムパスポート for PublicID CA の備える機能については、「セコム電子認証基盤認証運用
規 程」及 び「セ コムパス ポート for Member 2.0 PUB 証明書 ポリシ ー」 を参照 のこと 。
（https://repo1.secomtrust.net/spcpp/pfm20pub/）7

技術仕様書２.１１.

セコム公開リポジトリ
セコム公開リポジトリは、セコムトラストシステズが運用するセコムの認証局が発行する証
明書の有効性検証に必要な各種証明書、CRL/ARL を格納する。
セコム公開リポジトリが備える機能については、セコムトラストシステムズ株式会社が運用する各認証サービスのリポジトリで公開する CP、CPS を参照のこと。
Security Communication RootCA2：https://repository.secomtrust.net/SC-Root2/
Security Communication RootCA3：https://repository.secomtrust.net/SC-Root3/
セコムパスポート for Web SR3.0 CA：https://repo1.secomtrust.net/spcpp/pfw/pfwsr3ca/
セコムパスポート for PublicID CA：https://repo1.secomtrust.net/spcpp/pfm20pub/

２.１２.

セコム OCSP レスポンダ
セコム OCSP レスポンダは、検証要求者が指定した証明書の有効性を検証し、その検証要求
者に証明書の有効性の検証結果を返すサーバである。OCSP レスポンダのプロトコルは
RFC2560 及び RFC5019 で規定されている。
セコム OCSP レスポンダが備える機能については、セコムトラストシステムズ株式会社が運用する各認証サービスのリポジトリで公開する CP、CPS を参照のこと。
Security Communication RootCA2：https://repository.secomtrust.net/SC-Root2/
Security Communication RootCA3：https://repository.secomtrust.net/SC-Root3/
セコムパスポート for Web SR3.0 CA：https://repo1.secomtrust.net/spcpp/pfw/pfwsr3ca/
セコムパスポート for PublicID CA：https://repo1.secomtrust.net/spcpp/pfm20pub/

２.１３.

エンドエンティティ
エンドエンティティは、データに署名し送信する署名者と、認証パスを構築し署名を検証す
る署名検証者に大別できる。署名者は CA から証明書を発行され、その証明書に含む公開鍵と一致する秘密鍵でデータに署名することができる。
共通の機能として以下を備える。
エンドエンティティ自身の証明書発行要求、発行された証明書の受け入れ

エンドエンティティ自身の証明書の更新要求、発行された証明書の受け入れ
署名者のエンドエンティティは以下の機能を備えている。



データに署名

リポジトリ等及びセコム公開リポジトリから証明書の取得



認証パスの構築（オプション）

8

技術仕様書

署名検証者のエンドエンティティは以下の機能を備えている。


署名の検証



リポジトリ等及びセコム公開リポジトリから証明書、CRL/ARL の取得



LDAPv3 リフェラルによる他のリポジトリへの連携
エンドエンティティは、LDAPv3 をサポートすること。



OCSP レスポンダへの問い合わせ機能、第四次 LGPKI 証明書検証サーバへの問い合わせ機能、もしくは証明書検証サーバ等と同等の証明書検証機能

9技術仕様書２.１４.

LGPKI における認証情報
LGPKI では、相互認証証明書や自己署名証明書及び失効情報を用いる。以降では、これら認証情報について記述する。
なお、セコムトラストシステムズ株式会社が運用する各認証サービスの認証局についてはセ
コムトラストシステムズ株式会社が運用する各認証サービスのリポジトリで公開する CP、CPS
を参照のこと。
Security Communication RootCA2：https://repository.secomtrust.net/SC-Root2/
Security Communication RootCA3：https://repository.secomtrust.net/SC-Root3/
セコムパスポート for Web SR3.0 CA：https://repo1.secomtrust.net/spcpp/pfw/pfwsr3ca/
セコムパスポート for PublicID CA：https://repo1.secomtrust.net/spcpp/pfm20pub/

２.１４.１. 認証情報の公開
LGPKI の各 CA が発行する各種証明書と証明書の有効性を検証する情報である失効情報(CRL/ ARL)の公開に関して記載する。ここでは、主に各種証明書と CRL/ARL のリポジトリ等への格納・削除・更新について記述する。
証明書や CRL などの ASN.1 の構造をもつバイナリデータは、
AttributeDescription での「Binary」
オプションを指定し、バイナリ符号化して格納する。
表 ２-1 に各認証情報と第四次 LGPKI 公開リポジトリへの格納・削除・更新の関係を示し、次節以降で格納形式等を記述する。
表 ２-1 認証情報の第四次 LGPKI 公開リポジトリへの格納・削除・更新

相互認証証明書

エンドエンティティ
用証明書

自己署名証明書

リンク証明書失効情報

第三次 LGPKI

第四次 LGPKI

組織 CA

組織 CA R2

の処理

の処理

格納

−

○

削除

−

○

更新

−

○

格納

−

−

削除

−

−

更新

−

−

格納

−

○

削除

−

○

格納

−

○

削除

−

○

格納

−

○

削除

−

○

10

技術仕様書更新−○○：処理対象、−：処理対象外
・エンドエンティティ用証明書は、リポジトリ等への情報格納を行わない。
格納についての詳細な形式は RFC4523 の記述にしたがうものとする。
以下の証明書は、リポジトリ内の格納対象のエントリに複数格納される可能性がある。このため削除や更新時には、対象となる証明書以外に影響を与えないようにしなければならない。

各 CA エントリの cACertificate 属性に格納される、自己署名証明書及びリンク証明書もしくは相互認証証明書

表２−２に各認証情報と第四次 LGPKI 統合リポジトリへの格納・削除・更新の関係を示し、次節以降で格納形式等を記述する。
表 ２−２認証情報の統合リポジトリ等への格納・削除・更新（○：処理対象、−：処理対象外）
第三次組織

第四次組織

第四次アプリ

CA の処理CAR2 の処理

ケーション
CAR2 の処理

相互認証証明書

エンドエンティ
ティ用証明書
自己署名証明書
リンク証明書

失効情報

格納

−

−

−

削除

−

−

−

更新

−

−

−

格納

−

−

−

削除

−

−

−

更新

−

−

−

格納

○

○

○

削除

○

○

○

格納

○

○

−

削除

○

○

−

格納

○

○

○

削除

○

○

○

更新

○

○

○

格納についての詳細な形式は RFC4523 の記述にしたがうものとする。
以下の証明書は、リポジトリ内の格納対象のエントリに複数格納される可能性がある。このため削除や更新時には、対象となる証明書以外に影響を与えないようにしなければならない。
各 CA エントリの cACertificate 属性に格納される、自己署名証明書及びリンク証明書もしくは相互認証証明書

11

技術仕様書２.１４.２. 相互認証証明書の格納･削除(1)相互認証証明書の格納
ア）第四次 LGPKI 組織 CAR2 の CA エントリへの格納
第四次 LGPKI 組織 CAR2 が他 CA へ発行した、あるいは他 CA から発行された相互認証証明
書のリポジトリ等への格納は、次の形式で行う。
格納するエントリ

第四次 LGPKI 組織 CAR2 の CA のエントリ格納するエントリが持た PkiCA(joint-iso-itu-t(2) ds(5) objectClass(6) pkiCA(22))
なければならないオブ
ジェクトクラス

格納する属性名
属性値の型

crossCertificatePair 属性
CertificatePair

格納するフィールド1

Forward フィールド

他 CA が第四次 LGPKI 組織 CAの公開鍵に署名した相互認証証
明書

Reverse フィールド

第四次 LGPKI 組織 CA が他 CAの公開鍵に署名した相互認証証
明書

複数 CA と相互認証した 相互認証した CA ごとに別の属性値として格納する
場合の属性値の扱い
相互認証証明書の格納は、相互認証証明書ペアを構成する 2 つの証明書が両方揃った時点で行っても、リポジトリ等へ格納できる状態になった方から随時格納してもよい。

(2)相互認証証明書の削除
相互認証証明書の削除は、次のような場合に実施する。


自 CA が発行した相互認証証明書を失効した場合



相互認証する相手の CA が自 CA に対して発行した相互認証証明書を失効したことが、発行した相手の CA から通知された場合



リポジトリ等内に存在する相互認証証明書が失効、もしくは、停止されたことを知った
場合

1International standard 9594-8 ITU-T RECOMMENDATION X.509 (03/2000)では、これまで

forward / reverse と表記されていたフィールドを issuedToThisCA / issuedByThisCA と表記している。しかし、本書では政府認証基盤相互運用性仕様書との整合性を考慮し forward / reverse と表記する。

12

技術仕様書２.１４.３. 自己署名証明書及びリンク証明書の格納・削除
組織 CA 等の自己署名証明書は 10 年間有効である。そのうち、前半の 5 年間のみ相互認証証
明書の発行に使用する。
(1)自己署名証明書、リンク証明書の格納
組織 CA 等及び第四次 LGPKI アプリケーション CAR2 が自らの公開鍵に自らの秘密鍵で署名して発行した自己署名証明書及びリンク証明書のリポジトリ等への格納は、次の形式で行う
ものとする。なお、第三次 LGPKI 組織 CA は、自己署名証明書及びリンク証明書の第四次 LGPKI
公開リポジトリへの格納は行わない。
格納するエントリ

CA のエントリ
格納するエントリが持た PkiCA(joint-iso-itu-t(2) ds(5) objectClass(6) pkiCA(22))
なければならないオブ
ジェクトクラス

格納する属性
属性値の型

cACertificate 属性
Certificate

複数の自己署名証明書及 発行された自己署名証明書及びリンク証明書ごとに別びリンク証明書を持つ場 の属性値として格納する合の属性値の扱い(2)自己署名証明書及びリンク証明書の削除
CA は、
CA エントリ内の cACertificate 属性中の証明書の削除を、次のような場合に実施する。


証明書内容変更、鍵長変更等で証明書を失効した場合



証明書の有効期限が切れた場合

２.１４.４. 失効情報の格納と更新(1)失効情報の格納
CA が発行した証明書の証明書失効リストは、各証明書の cRLDistributionPoint 拡張に示されたエントリ、または CA のエントリに格納するものとする。なお、第三次 LGPKI 組織 CA は、
失効情報の第四次 LGPKI 公開リポジトリへの格納は行わない。
・ ARL
格納するエントリ

各証明書内の cRLDistributionPoints で指定されたエント
リまたは CA のエントリ格納するエントリが持た ・cRLDistributionPoints で指定されたエントリの場合、な け れ ば な ら な い オ ブ CRLDistributionPoint(joint-iso-itu-t(2) ds(5) objectClass(6)ジェクトクラス
cRLDistiributionPoint(19))

13

技術仕様書格納する属性
属性値の型
・ CRL格納するエントリ・CA のエントリの場合、
pkiCA(joint-iso-itu-t(2) ds(5) objectClass(6) pkiCA(22))
AuthorityRevocationList 属性（ARL）
CertificateList

各証明書内の cRLDistributionPoints で指定されたエント
リまたは CA のエントリ格納するエントリが持た ・cRLDistributionPoints で指定されたエントリの場合、な け れ ば な ら な い オ ブ CRLDistributionPoint(joint-iso-itu-t(2) ds(5) objectClass(6)ジェクトクラス
cRLDistiributionPoint(19))

格納する属性
属性値の型

・CA のエントリの場合、
pkiCA(joint-iso-itu-t(2) ds(5) objectClass(6) pkiCA(22))
CertificateRevocationList 属性（CRL）
CertificateList(2)失効情報の更新
失効情報は、nextUpdate までに更新しなければならない。この時、実際の更新を nextUpdate
より前に行い、新旧の失効情報がオーバーラップする期間を設けておく運用を行う。これにより、障害や事故等により次回の更新が遅れた場合に、失効情報がまったく公開されない期間が出現しないようにできる可能性が大きくなる。

14

技術仕様書３

アプリケーション仕様

３.１. 概要
本章では、LGPKI を利用するアプリケーションが満たすべき機能を記述する。前提として、以下の要件を満たすことが必要となる。


アプリケーション間で関連する証明書と失効情報には互換性がなければならない



署名アルゴリズムは互換性がなければならない



相対する 2 者間で認証パスの構築と検証ができなければならない

証明書や失効情報を共有する方法には互換性がなければならない



相対する 2 者間で利用する署名フォーマットは互換性がなければならない



ベンダー固有の依存性は避けなれければならない

また LGPKI は、拡張性やアプリケーションの汎用性を確保する観点から、他の認証ドメインとの技術的な統一性を重視している。具体的には、公的な認証基盤である GPKI との技術的な統一を重視している。そのため、原則として、GPKI の技術仕様である、政府認証基盤相互運用性仕様書に定められた事項に準拠しなければならない。
なお、セコムトラストシステムズ株式会社が運用する各認証サービスの認証局についてはセ
コムトラストシステムズ株式会社が運用する各認証サービスのリポジトリで公開する CP、CPS
を参照のこと。
Security Communication RootCA2：https://repository.secomtrust.net/SC-Root2/
Security Communication RootCA3：https://repository.secomtrust.net/SC-Root3/
セコムパスポート for Web SR3.0 CA：https://repo1.secomtrust.net/spcpp/pfw/pfwsr3ca/
セコムパスポート for PublicID CA：https://repo1.secomtrust.net/spcpp/pfm20pub/
以降では、LGPKI に固有な仕様について記述する。

３.２. 証明書と失効情報（CRL/ARL）のプロファイル
LGPKI で定義するプロファイルの詳細に関しては「地方公共団体組織認証基盤・プロファイ
ル設計書」に示す。
なお、第四次 LGPKI 組織 CA R2 の発行する証明書の名義（Subject）を表 ３-1、表 ３-2 に、
セコムパスポート for Web SR3.0 CA が発行する Web サーバ証明書の名義（Subject）を表 ３-3に、セコムパスポート for PublicID CA が発行するメール用証明書、コードサイニング証明書の証明書の名義（Subject）を表 ３-4 、表 ３-5 に、第三次 LGPKI 組織 CA の発行する暗号化
通信用等証明書の名義（Subject）を表 ３-6 に示す。

15

技術仕様書表 ３-1 職責証明書
識別属性型
c
o
l
ou
ou (*1)cn (*1)

属性型

属性型説明

値の設定例

countryNameorganizeitionName
localityNameorganizationalUnitNameorganizationalUnitName
commonName

電子証明書所有者の国名
電子証明書所有者の組織名
電子証明書所有者の地域名
電子証明書所有者の組織単位名
電子証明書所有者の組織単位名（*2）
電子証明書所有者の固有名称

JP
Local Governments
都道府県（英語）
地方公共団体名（英語）
所属部門名（英語）
役職名等（英語）(*1) ou、cn の英語表記は 64 文字以内という制限があり、64 文字を超える名称等については
64 文字以内で収まるような名称に変更する。
(*2) 局、室、課名は、organizationalUnitName を用いて表現する。本 organizationalUnitName は、
０〜７個の間で任意に用いることが出来る。
表 ３-2 利用者証明書
識別属性型
c
o
l
ou
ou (*1)cn (*1)

属性型

属性型説明

値の設定例

countryNameorganizeitionName
localityNameorganizationalUnitNameorganizationalUnitName
commonName

電子証明書所有者の国名
電子証明書所有者の組織名
電子証明書所有者の地域名
電子証明書所有者の組織単位名
電子証明書所有者の組織単位名（*2）
電子証明書所有者の固有名称

JP
Local Governments
都道府県（英語）
地方公共団体名（英語）
所属部門名（英語）
役職名等（英語）(*1) ou、cn の英語表記は 64 文字以内という制限があり、64 文字を超える名称等については
64 文字以内で収まるような名称に変更する。
(*2) 局、室、課名は、organizationalUnitName を用いて表現する。本 organizationalUnitName は、
０〜７個の間で任意に用いることが出来る。
証明書発行要求（以下「CSR」という。）ファイルに設定できるサブジェクトが定型化されているなどの Web サーバ及び署名ツール側の技術的理由により、指定する識別名と同様の識別名
構造での CSR ファイル作成が不可能な場合は、CSR ファイル作成側で指定する識別名の読み替えを行う。
表 ３-3 Web サーバ証明書
識別属性型

属性型

読み替え

値の設定例

国コードをそのまま指定。
各地方公共団体の属する都道府県域を指定。

JP
東京都の場合「Tokyo」「Tokyo-to」
東京都の場合「Shinjuku-ku」「Shinjuku City」
東京都の場合「Tokyo」「Tokyo-to」
xxxxx Prefecture Soumubu
IT SuishinshitsuccountryName

st または sstate or provincellocalityName

各地方公共団体の組織の所在地（代表）が置かれている市区町村名を指定。

oorganizeitionName

各地方公共団体の団体名

ou (*1)organizationalUnitName

部署又はグループ名。省略可能。

cn (*1)

commonName

サーバの完全修飾ドメイン名（FQDN）
を指定。

16

www.pref.xxxxx.lg.jp

技術仕様書(*1) ou、cn の英語表記は 64 文字以内という制限があり、64 文字を超える名称等については
64 文字以内で収まるような名称に変更する。
表 ３-4 メール用証明書
識別属性型
c
o
l
ou
ou (*1)cn (*1)
E

属性型

属性型説明

値の設定例

countryNameorganizeitionName
localityNameorganizationalUnitNameorganizationalUnitName
commonName
E-mail address

電子証明書所有者の国名
電子証明書所有者の組織名
電子証明書所有者の地域名
電子証明書所有者の組織単位名
電子証明書所有者の組織単位名（*2）
電子証明書所有者の固有名称
電子証明書所有者のメールアドレス

JP
Local Governments
都道府県（英語）
地方公共団体名（英語）
所属部門名（英語）
役職名等（英語）
xxxxx@pref.xxxx.lg.jp(*1) ou、cn の英語表記は 64 文字以内という制限があり、64 文字を超える名称等については
64 文字以内で収まるような名称に変更する。
(*2) 局、室、課名は、organizationalUnitName を用いて表現する。本 organizationalUnitName は、
０〜７個の間で任意に用いることが出来る。

表 ３-5 コードサイニング証明書
識別属性型

属性型

読み替え

c

countryName

st または sstate or provincellocalityNameoorganizeitionName

ou (*1)organizationalUnitName

cn (*1)

commonName

値の設定例

国コードをそのまま指定。
JP
指定しない。省略不可の場合、各地方公共団体の属する都道府県域を指定。
各地方公共団体の属する都道府県域を都道府県（英語）
指定。
Local Governments を固定で指定。
Local Governments
地方公共団体名を指定。サーバ管理組織 xxxxx Prefecture Soumubu
IT Suishinshitsu
名も任意で指定可能。
地方公共団体名及びコード管理責任者 CodeAdminofxxxxxを表す CodeAdmin を指定（*2）
。組織名、 Prefecture {組織名} {アプ
アプリケーション名も任意で指定可能。 リケーション名}(*1) ou、cn の英語表記は 64 文字以内という制限があり、64 文字を超える名称等については
64 文字以内で収まるような名称に変更する。
(*2) コード管理責任者の表記は、特段の理由がない限り CodeAdmin 固定とする。
表 ３-6 暗号化通信用等証明書
識別属性型

属性型

属性型説明

c
o
l
ou (*1)countryNameorganizeitionName
localityNameorganizationalUnitName

電子証明書所有者の国名
電子証明書所有者の組織名
電子証明書所有者の地域名
電子証明書所有者の組織単位名

cn (*1)

commonName

電子証明書所有者の固有名称

値の設定例
JP
Local Governments
都道府県（英語）
地方公共団体名（英語）
情報提供ネットワークシス
テムが定める機関コード(*1) ou、cn の英語表記は 64 文字以内という制限があり、64 文字を超える名称等については
64 文字以内で収まるような名称に変更する。

17

技術仕様書３.３. 証明書と失効情報（CRL/ARL）の公開方法
LGPKI では基本的に第四次 LGPKI 公開リポジトリを使用し各種証明書や失効情報（CRL/ARL）
を公開するものとする。そのため、登録内容に基準が無ければ、認証パスの構築や検証の際に参照できなくなってしまう。
本仕様書ではリポジトリ内のスキーマや DIT を示すディレクトリプロファイルを「６ディレ
クトリプロファイル」に規定する。

３.４. 推奨署名アルゴリズム
LGPKI では以下に示す点に従って、推奨署名アルゴリズムを定める。


署名者があるアルゴリズムで署名したデータを、署名検証者が検証する際にはそのアルゴリズムを解釈できなければならない。



現状利用できるアルゴリズムが将来アルゴリズム危殆化により利用できなくなることも考慮しなければならない。



認証パス中に複数の署名アルゴリズムがある場合、認証パス中にある全てのアルゴリズ
ムを解釈できなければならない。

３.４.１. アルゴリズム
エンドエンティティは署名検証する際、署名者が使用した署名アルゴリズムをサポートしていなければならない。
原則として署名アルゴリズムは以下を用いる。
Sha384WithRSAEncryption（1.2.840.113549.1.1.12）



Sha256WithRSAEncryption（1.2.840.113549.1.1.11）



sha1WithRSAEncryption（1.2.840.113549.1.1.5）

なお、sha1WithRSAEncryption は過去の互換性のためにサポートする。
また、
Sha384WithRSAEncryption はセコムトラストシステムズ株式会社が運用する各認証サービスの認証局でのみサポートする。

３.４.２. 鍵長
署名検証者は、署名者が使用する鍵長の署名を検証できなければならない。また認証パスに含まれる全ての証明書の署名をその鍵長で検証できなければならない。そのため、少なくとも以下の鍵長での署名検証ができなければならない。


RSA、2048 ビットまで

また、コードサイニング証明書については、少なくとも以下の鍵長での署名検証ができなけ
ればならない。

18

技術仕様書

RSA、4096 ビットまで

３.４.３. 認証パスの構築・検証方法
認証パスの構築・検証に関しては、政府認証基盤相互運用性仕様書に記載の技術要件に準拠することが必須である。

３.５. LGPKI における名前と DIT の規定
３.５.１. 識別名、相対識別名
LGPKI における名前としては、generalName の directoryName を用いる。issuer 及び subject も
また directoryName である。directoryName は識別名、すなわち一個以上の相対識別名のシーケンスである。
ここでは識別名及びその構成要素である相対識別名の使用可能文字、証明書へのエンコード
方式について規定する。以後本書では、特に断らない限り「識別名」と記している場合、相対識別名も含むものとする。
これらは原則として RFC5280 の規定にしたがうものとするが、以下では LGPKI における特記事項について記述する。

３.５.２. エンコードタイプ
subject や issuer で使用される DN を記述する文字コードについては、原則として UTF8 Stringを用いる。ただし、アプリケーション CA 等から発行される証明書については、当面 Printable
String で発行する。

３.５.３. issuerAltName 及び subjectAltName
issuerAltName 及び subjectAltName の directoryName については、日本語表記を格納することもできるものとする。その場合、エンコードタイプは UTF8String としなければならない。

19

技術仕様書４

証明書検証サーバの利用

４.１. 概要LGPKI では、第四次 LGPKI 証明書検証サーバは第四次 LGPKI 組織 CA R2 によって認証される。また、証明書検証サーバを利用するのは、第四次 LGPKI 組織 CA R2 をトラストアンカーとする地方公共団体の職責者もしくはそれに準ずる証明書検証者である。また、検証対象となる証明書は、LGPKI が発行する証明書のほかに、第四次 LGPKI 組織 CA R2 が相互認証している他 CA が発行した証明書である。第四次 LGPKI 証明書検証サーバは、LGPKI が発行した証明書を検証する者に対し、証明書検証という非常に複雑な処理の代行や、さらに、LDAP による
第四次 LGPKI 公開リポジトリへのアクセスが困難な者に対し、各種認証情報を提供する等、
LGPKI が発行した証明書を検証する側の負担を軽減するものである。
本章では、まず第四次 LGPKI 組織 CA R2 が提供する第四次 LGPKI 証明書検証サーバについて記述し、その後証明書を発行する第四次 LGPKI 組織 CA R2 と、第四次 LGPKI 証明書検証
サーバを利用する利用者クライアントが満たすべき仕様について記述する。

４.２. 証明書検証サーバ用証明書（VA 証明書）
第四次 LGPKI 証明書検証サーバの証明書は、第四次 LGPKI 組織 CA R2 が発行する。また、証明書検証サーバの証明書の extendedKeyUsage には id-kp-OCSPSigning を設定する。

４.３. クライアント要件
第四次 LGPKI 証明書検証サーバを利用するクライアントが備えているべき点を記述する。

４.３.１. クライアント側の前準備
第四次 LGPKI 証明書検証サーバのレスポンスデータに含まれる署名を検証する必要がある
ため、クライアントは自分の利用する第四次 LGPKI 証明書検証サーバの署名を検証するのに必要な下記の情報を設定する必要がある。


トラストアンカーの証明書

４.４. 証明書検証サーバ通信プロトコル
第四次 LGPKI 証明書検証サーバとの通信プロトコルについては、別添１に示す。

４.５. 証明書検証サーバのアクセス制御
第四次 LGPKI 証明書検証サーバは、公的個人認証サービスから発行された証明書の検証を行う際､公的個人認証サービスの失効情報を参照する｡LGPKI では、第四次 LGPKI 証明書検証サーバの利用に当たって､公的個人認証サービスから失効情報の参照が許可された地方公共団体か20技術仕様書らの利用だけに限ることとする｡

21

技術仕様書５

OCSP レスポンダの利用
LGPKI では、第四次 LGPKI にて、セコムトラストシステムズ株式会社が運用する各認証サー
ビスの OCSP レスポンダを利用する。この OCSP レスポンダについてはセコムトラストシステ
ムズ株式会社が運用する各認証サービスのリポジトリで公開する CP、CPS を参照のこと。
Security Communication RootCA2：https://repository.secomtrust.net/SC-Root2/
Security Communication RootCA3：https://repository.secomtrust.net/SC-Root3/
セコムパスポート for Web SR3.0 CA：https://repo1.secomtrust.net/spcpp/pfw/pfwsr3ca/
セコムパスポート for PublicID CA：https://repo1.secomtrust.net/spcpp/pfm20pub/

22

技術仕様書６

ディレクトリプロファイル

６.１. LGPKI における DIT 構造
全てのエンティティは、全体として矛盾のない一つのディレクトリ情報ツリー（DIT）を構成する。
DIT の第一階層は国、第二階層は LGPKI（"LGPKI"、”LGPKI2”）コンテナとする。第三階層は、"LGPKI"以下に第三次 LGPKI 組織 CA、第四次 LGPKI アプリケーション CAR2、"LGPKI2"以下に第四次 LGPKI 組織 CA R2 とする。
なお LGPKI においては、発行する証明書の subject や issuer で使用される DN を記述する文字コー
ドが Printable String の CA と UTF8String の CA がある。第三次 LGPKI 組織 CA 及び第四次 LGPKI
組織 CA R2 の文字コードは UTF8String である。
図 ６-1 に LGPKI における DIT 構造を示す。

c=JP
o=LGPKI

ou=Organization CA U8

cn=Application CA R2※※第四次LGPKI統合リポジトリのみ

o=LGPKI2

ou=Organization CA R2
図 ６-1 LGPKI における DIT 構造

23

技術仕様書６.２. DIT の名前形式
DIT 構造の各階層において、識別名に用いる属性を表 ６-1

階層ごとの識別属性型と属性値のように定める。
表 ６-1
階層

階層ごとの識別属性型と属性値

識別属性型

属性値として取り得る値

第一階層

c

"JP"

第二階層

o

"Local Goverments"、"LGPKI"、"LGPKI2"、"地方公共団体"

第三階層

ou
cn
l

”Organization CA U8”、”Organization CA R2”“Application CA R2”
都道府県域名第四階層

ou

地方公共団体名

第五階層以下ou

地方公共団体内各組織・部門

リーフ

cn

名義（役職名義）

６.３. リポジトリ等に格納される情報
リポジトリ等に格納されるエントリ及び属性について示す。

６.３.１. LGPKI コンテナ
LGPKI コンテナを表すエントリを構成するオブジェクトクラスとして、RFC4519 に定められている organization オブジェクトクラスを用いる。
organization オブジェクトクラスの定義及び organization オブジェクトクラスの上位オブジェ
クトクラスとして参照される top オブジェクトクラスの定義は、各々表 ６-2、表 ６-3 のとお
りである。
表 ６-2

organization オブジェクトクラスの定義【オブジェクトクラス名】【オブジェクト識別子】【種別】

organization

joint-iso-itu-t(2) ds(5) objectClass(6)organization(4)構造型【上位オブジェクトクラス】 top【必須属性】o【任意属性】

userPassword
searchGuide24

技術仕様書

seeAlsobusinessCategory
x121Address
registeredAddress
destinationIndicatorpreferedDeliveryMethodtelexNumber
telexTerminalIdentifier
telephoneNumber
internationaliSDNNumber
facsimileTelephoneNumber
streetpostOfficeBox
postalCode
postalAddress
physicalDeliveryOfficeNamestldescription

表 ６-3【オブジェクトクラス名】【オブジェクト識別子】【種別】

top オブジェクトクラスの定義
top

joint-iso-itu-t(2) ds(5) objectClass(6)top(0)
抽象型【上位オブジェクトクラス】 なし【必須属性】

objectClass【任意属性】

なし(1) LGPKI コンテナ
LGPKI のコンテナを表す名前("LGPKI"、”LGPKI2”)を格納する属性として organization オブ
ジェクトクラスの必須属性である o 属性を用いる。
o 属性の定義及び o 属性の上位属性として参照される name 属性の定義は、各々表 ６-4、表
６-5 のとおりである。
表 ６-4

o 属性の定義【属性名】

o【オブジェクト識別子】

joint-iso-itu-t(2) ds(5) attributeType(4)organizationName(10)25技術仕様書【上位属性】

name【照合規則】

name 属性を継承【属性構文】

name 属性を継承

表 ６-5

name 属性の定義

【属性名】

name

【オブジェクト識別子】

joint-iso-itu-t(2) ds(5) attributeType(4)name(41)
なし【上位属性】【照合規則】＜完全一致＞ caseIgnoreMatch＜部分一致＞ caseIgnoreSubstringMatch＜順序性＞【属性構文】

なし
DirectoryString

６.３.２. CA エントリ
組織 CA 等を表すエントリを構成するオブジェクトクラスとして、RFC4519 に定められている organizationalUnit オブジェクトクラスを用い、これに補助クラスとして、RFC4523 に定められている pkiCA オブジェクトクラスを付加する。
organziationalUnit オブジェクトクラスの定義及び organizaionlUnit オブジェクトクラスの上位
オブジェクトクラスとして参照される top オブジェクトクラスの定義は、各々表 ６-6、表 ６-3のとおりである。
表 ６-6

organizationalUnit の定義【オブジェクトクラス名】

organizationalUnit【オブジェクト識別子】

joint-iso-itu-t(2) ds(5) objectClass(6)organizationalUnit(5)
構造型

【種別】

【上位オブジェクトクラス】 top【必須属性】

objectClassou

26

技術仕様書【任意属性】

userPassword
searchGuide
seeAlsobusinessCategory
x121Address
registeredAddress
destinationIndicatorpreferedDeliveryMethodtelexNumber
telexTerminalIdentifier
telephoneNumber
internationaliSDNNumber
facsimileTelephoneNumber
streetpostOfficeBox
postalCode
postalAddress
physicalDeliveryOfficeNamestldescription

organizationalRole オブジェクトクラスの定義及び organizationalRole オブジェクトクラスの上
位オブジェクトクラスとして参照される top オブジェクトクラスの定義は、各々表 ６-7 、表
６-3 のとおりである。

表 ６-7

organizationalRole の定義【オブジェクトクラス名】

organizationalRole【オブジェクト識別子】

joint-iso-itu-t(2) ds(5) objectClass(6)organizationalRole(8)
構造型

【種別】

【上位オブジェクトクラス】 top【必須属性】

objectClasscn【任意属性】

x121Address
registeredAddress
destinationIndicatorpreferredDeliveryMethodtelexNumber
teletexTerminalIdentifier
telephoneNumber
internationaliSDNNumber
facsimileTelephoneNumber
seeAlsoroleOccupant
preferredDeliveryMethod
street27

技術仕様書postOfficeBox
postalCode
postalAddress
physicalDeliveryOfficeNameoustldescription

pkiCA オブジェクトクラスの定義は表 ６-8 のとおりである。
表 ６-8

pkiCA の定義

【オブジェクトクラス名】

pkiCA【オブジェクト識別子】

joint-iso-itu-t(2) ds(5) objectClass(6)pkiCA(22)
補助型

【種別】

【上位オブジェクトクラス】 top【必須属性】

objectClass【任意属性】

cACertificate
certificateRevocationList
authorityRevocationList
crossCertificatePair(1) CA 名称
CA 名称（第三次 LGPKI 組織 CA（"Organization CA U8"））あるいは第四次 LGPKI 組織 CA R2（" Organization CA R2”）を格納する属性として、organizationalUnit オブジェクトクラスの必須属性である ou 属性を用いる。
CA 名称（第四次 LGPKI アプリケーション CA R2（"Application CA R2"））を格納する属性として、organizationalRole オブジェクトクラスの必須属性である cn 属性を用いる。
ou 属性の定義、及び ou 属性の上位属性として参照される name 属性の定義は、各々表 ６-9 、
表 ６-5 のとおりである。
表 ６-9

ou 属性の定義

【属性名】

ou

【オブジェクト識別子】

joint-iso-itu-t(2) ds(5) attributeType(4)organizationalUnitName(11)name【上位属性】

28

技術仕様書【照合規則】

name 属性を継承【属性構文】

name 属性を継承

cn 属性の定義及び cn 属性の上位属性として参照される name 属性の定義は、各々表 ６-10、
表 ６-5 のとおりである。
表 ６-10cn 属性の定義

【属性名】

cn

【オブジェクト識別子】【上位属性】

joint-iso-itu-t(2) ds(5) attributeType(4)commonName (3)name【照合規則】

name 属性を継承【属性構文】

name 属性を継承(2) 自己署名証明書及びリンク証明書
自己署名証明書及びリンク証明書を格納する属性として、pkiCA オブジェクトクラスの設定
上追加必須属性である cACertificate 属性を用いる。
自己署名証明書及びリンク証明書は､第四次 LGPKI 組織 CAR2 が持つ｡
この属性は"cACertificate;binary"と指定することによって属性値の受け渡しを行う。
cACertificate 属性の定義は表 ６-11 のとおりである。
表 ６-11cACertificate 属性の定義【属性名】

cACertificate【オブジェクト識別子】

joint-iso-itu-t(2) ds(5) attributeType(4)cACertificate(37)なし【上位属性】【照合規則】＜完全一致＞ certificateExactMatch＜部分一致＞ なし＜順序性＞【属性構文】なし
Certificate

29

技術仕様書(3)相互認証証明書
相互認証証明書は､次の二つの属性に格納される｡
ア）crossCertificatePair 属性
第四次 LGPKI 組織 CAR2 の CA エントリでは、他 CA との間で取り交わした相互
認 証 証 明 書 が 、 pkiCA オ ブ ジ ェ ク ト ク ラ ス の 設 定 上 追 加 必 須 属 性 で あ る
crossCertificatePair 属性に格納される。
この属性は"crossCertificatePair;binary"と指定することによって属性値の受け渡しを行う。
crossCertificatePair 属性の定義は表 ６-12 のとおりである。
表 ６-12crossCertificatePair 属性の定義【属性名】

crossCertificatePair【オブジェクト識別子】

joint-iso-itu-t(2) ds(5) attributeType(4)crossCertificatePair(40)なし【上位属性】【照合規則】＜完全一致＞ certificatePairExactMatch＜部分一致＞ なし＜順序性＞【属性構文】なし
CertificatePair(4) CRL
CRL を格納する属性として、pkiCA オブジェクトクラスの設定上追加必須属性である
certificateRevocationList 属性を用いる。
この属性は"certificateRevocationList;binary"と指定することによって属性値の受け渡しを行う。
certificateRevocationList 属性の定義は表 ６-13 のとおりである。
表 ６-13certificateRevocationList 属性の定義【属性名】

certificateRevocationList【オブジェクト識別子】

joint-iso-itu-t(2) ds(5) attributeType(4)certificateRevocationList(39)なし【上位属性】

30

技術仕様書【照合規則】＜完全一致＞ certificateListExactMatch＜部分一致＞ なし＜順序性＞【属性構文】なし
CertificateList(5) ARLCA に関する CRL を格納する属性として、pkiCA オブジェクトクラスの設定上追加必須属性
である authorityRevocationList 属性を用いる。
この属性は"authorityRevocationList;binary"と指定することによって属性値の受け渡しを行う。
authorityRevocationList 属性の定義は表 ６-14 のとおりである。
表 ６-14authorityRevocationList 属性の定義【属性名】

authorityRevocationList【オブジェクト識別子】

joint-iso-itu-t(2) ds(5) attributeType(4)authorityRevocationList(38)なし【上位属性】【照合規則】＜完全一致＞ certificateListExactMatch＜部分一致＞ なし＜順序性＞【属性構文】なし
CertificateList

31

技術仕様書６.４. リポジトリ等のインタフェース仕様
リポジトリ等及びセコム公開リポジトリに対して、民間側が利用する行政サービスアプリケー
ションからは、証明書・署名の検証のための認証情報の検索が行われる。リポジトリ等及びセコム
公開リポジトリに対する一切の更新系の操作は許可されない。
民間側が利用する行政サービスアプリケーションは、LDAPv3 をサポートするものとする。
BindRequest
認証なしによる Bind のみを許可する。この場合、BindRequest パラメータは以下のとおりである。
version2 あるいは 3

name"" (長さ 0 の文字列)

authenticaton.simple"" (長さ 0 の文字列)

Bind Response
RFC4511 4.2.2 の規定のとおりとする。
Unbind Request/Response
RFC4511 4.3 の規定のとおりとする。
Search Request
以下の事項以外については、RFC4511 4.5.1 の規定のとおりとする。
derefAliases パラメータは neverDerefAliases のみとする。
typesOnly パラメータは FALSE としなくてはならない。
filter 項目について、approxMatch 及び extensibleMatch はサポートしない。
SearchResEntry/ResDone/ResRef
RFC4511 4.5.2 及び 4.5.3 の規定のとおりとする。
SearchResponse
RFC1777 4.3 の規定のとおりとする。

32

技術仕様書６.５. リポジトリ等のアクセス制御
６.５.１. 認証ポリシー
原則として認証しない。匿名によるアクセスを許可する。
この時、後述するアクセス制御ポリシーに従い、一部を除く全ての情報の参照が可能となるが、あらゆる情報の更新はできない。



リポジトリ等及びセコム公開リポジトリが管理・格納する情報を更新する操作員に対しては、最低限パスワードによる認証を行う。この時、後述するアクセス制御ポリシーに従い、許可された範囲の情報に対する参照・更新・削除が可能となる。

６.５.２. アクセス制御ポリシー
以下の方針によるアクセス制御を実施する。


リポジトリ等及びセコム公開リポジトリにアクセス可能な全てのクライアントに対して、全ての情報に対する参照権限を与える。ただし、一部公開すべきでない属性については、参照権限を与えない。さらに、各操作員を表すエントリに対しては、自分以外からの参照権限を与えない。



資格と権限のある操作員に対して、リポジトリ等及びセコム公開リポジトリが管理・格納する全ての情報について、参照・更新権限を与える。さらに、エントリの追加・削除・
識別名変更権限を与える。

33

別添１
証明書検証サーバ通信プロトコル
1. はじめに
1.1.

証明書検証サーバの利用手順

証明書検証サーバの利用手順について説明する。
なお、証明書検証サーバと証明書検証サービスの利用者との通信は、SSL（https(TCP/443)）のサーバ認証を用いた暗号化通信とする。

証明書検証サービスの利用者②証明書検証要求の送信

アプリケーション

証明書検証サーバ

プログラム
証明書検証クライアント①証明書検証要求

証明書検証サーバ（CVS）

アクセスプロトコル③証明書検証応答の受信の作成④証明書検証結果の取り出し

図 1-1 証明書検証の流れ①証明書検証要求の作成
アプリケーションプログラムは、証明書検証要求を 2 章以降で説明する証明書検証サーバアクセスプロトコルに従ったフォーマットで作成する。
②証明書検証要求の送信
アプリケーションプログラムは、①で作成した証明書検証要求を証明書検証サーバ（CVS）に送信する。

1

③証明書検証応答の受信
アプリケーションプログラムは、証明書検証サーバ（CVS）から送信された証明書
検証応答を受信する。このとき受信した証明書検証応答は、2 章以降で説明する証
明書検証サーバアクセスプロトコルに従ったフォーマットとなる。 また、証明書検証
応答中の証明書検証サーバによる署名の検証を行う。
④証明書検証結果の取り出し
アプリケーションプログラムは、証明書検証応答から証明書検証結果の取り出しを行う。

2. 通信プロトコル
OCSP(RFC2560)をベースとし、その拡張領域を証明書検証サーバ用に以下のように定義する。なお、拡張領域に付与する OID（オブジェクト識別子）は次のものをベースとして指定するものとする。
OID: 1.2.392.200010.10
2.1.

証明書検証要求（OCSP Request＋拡張）

2.1.1. OCSP 基本領域（OCSPRequest）
RFC2560 の規定に従う。
ただし、requestExtensions に nonce を必須とする。
また、acceptableResponses, optionalSignature は用いないこととする。
2.1.2. OCSP 拡張領域 （singleRequestExtensions）
OCSP Request の拡張領域（singleRequestExtensions）に以下の情報を設定する。
2.1.2.1. 検証対象(subscriber)の証明書（必須）
検証の対象となる subscriber のエンドエンティティ証明書を指定する。
この Extension は必須である。
拡張部分への設定フォーマットを次表に示す。
表 2-1 検証対象の証明書の設定フォーマット
プロトコル要素

指定する値

備考

Object id

1.2.392.200010.10.1 :subscriberCert

独自定義

Critical flag

CriticalValue

証明書（X.509）

2

2.1.2.2. 中間証明書（オプション）
検証対象者(subscriber)側のルート認証局 (Trust Anchor)から subscriber のエンドエンテ
ィティまでの証明書等、認証パスの一部となる証明書を指定する。ただし、証明書検証サー
バは,中間証明書を認証パス構築のためのヒント情報として利用するだけであり、必ずしも指定した証明書を含むパスを常に構築するわけではない。
この Extension はオプションであり、複数指定可能である。
また、複数指定する場合は、認証パスにおいて Trust Anchor に近い証明書から順に指定すること。
拡張部分への設定フォーマットを次表に示す。
表 2-2 中間証明書の設定フォーマット
プロトコル要素

指定する値

備考

Object id

1.2.392.200010.10.2 :intermediateCerts

独自定義

Critical flag

CriticalValue

証明書（X.509）

2.1.2.3. CA(Trust Anchor)の識別情報（オプション）
検証依頼者(relying party)が信頼するルート認証局 (Trust Anchor)を識別するための情報として次の情報を指定可能とする。
 CA 証明書
この Extension はオプションである。省略した場合、検証依頼者(relying party)が信頼する
ルート認証局 (Trust Anchor)は、証明書検証サーバ側で設定したルート認証局となる。
ただし、LGPKI では、必ず LGPKI ブリッジ認証局証明書を指定することとし、それ以外が指定された場合は、エラーを返すこととする。
拡張部分への設定フォーマットを次表に示す。
表 2-3 ルート認証局 (Trust Anchor)証明書の設定フォーマット
プロトコル要素

指定する値

備考

Object id

1.2.392.200010.10.3 : trustAnchorCert

独自定義

Critical flag

CriticalValue

証明書（X.509）

3

2.1.2.4. 満たすべきポリシ（オプション）
検証依頼者(relying party)が、認証パスに対して満たすべきポリシを要求する場合に、そのポリシの object id を指定する。満たすべきポリシが指定された場合、証明書検証サーバ
は、構築した認証パスが指定されたポリシを満たすかどうかを検査する。
この Extension はオプションであり、複数指定可能である。
表 2-4 満たすべきポリシ設定フォーマット
プロトコル要素

指定する値

備考

Object id

1.2.392.200010.10.4 : requiredPolicy

独自定義

Critical flag

CriticalValue

ポリシの object-id

2.1.2.5. require-explicit-policy の初期値（オプション）
検証依頼者(relying party)が、認証パスに対して require-explicit-policy を要求する場合に、範囲を指定する。require-explicit-policy が指定された場合、証明書検証サーバは、
require-explicit-policy の範囲外の証明書にポリシが存在することを検査する。
この Extension はオプションである。
LGPKI では、満たすべきポリシが指定された場合、この Extension は常に“0(ゼロ)”を指定することとする。
表 2-5 require-explicit-policy の初期値設定フォーマット
プロトコル要素

指定する値

備考

Object id

1.2.392.200010.10.5 :require-explicit-policy

独自定義

Critical flag

CriticalValue

0-xxx(integer)42.1.2.6. inhibit-policy-mapping の初期値（オプション）
検証依頼者(relying party)が、認証パスに対して inhibit-policy-mapping を要求する場合に、範囲を指定する。inhibit-policy-mapping が指定された場合、証明書検証サーバは、
inhibit-policy-mapping の範囲外の証明書にポリシマッピングが存在しないことを検査する。
この Extension はオプションである。
LGPKI では、ポリシマッピングを必須とするため、この Extension は常に指定しないこととする。
表 2-6 inhibit-policy-mapping の初期値設定フォーマット
プロトコル要素

指定する値

備考

Object id

1.2.392.200010.10.6 :inhibit-policy-mapping

独自定義

Critical flag

CriticalValue

0-xxx(integer)

2.1.2.7. 応答フォーマット（オプション）
検証依頼者(relying party)が、証明書検証応答として返却すべき情報のレベルを指定する。
この Extension はオプションである。（省略時は証明書の検証結果のみ返却する。）
指定可能な情報レベルを次に示す。
 0: 証明書の検証結果のみ返却する(デフォルト) 1: 証明書の検証結果に加えて、認証パス及び CRL/ARL を返却する。
拡張部分への設定フォーマットを次表に示す。
表 2-7 応答フォーマット設定フォーマット
プロトコル要素

指定する値

備考

Object id

1.2.392.200010.10.7 : responseFormat

独自定義

Critical flag

CriticalValue

0 または 1(integer)

5

2.2.

証明書検証応答（OCSP Response + 拡張）

2.2.1. OCSP 基本領域（OCSPResponse）
RFC2560 の規定に従う。
ただし、responseExtensions に nonce を必須とする。
また、nextUpdate は用いないこととする。
2.2.2. OCSP 拡張領域（singleExtensions）
OCSP Response の拡張領域（singleExtensions）に以下の情報を設定する。
2.2.2.1. 証明書検証結果（必須）証明書検証（認証パスの構築及び検証）の結果コードが設定される。
この Extension は必須である。
証明書検証の結果コードを次に示す。
 0: 認証パスの構築が成功し検証結果が正しい(good) 101: 認証パス構築不可
 202: 認証パスに署名が不正である証明書が含まれる
 203: 認証パスに失効した証明書が含まれる
 204: 認証パスに Policy Mappings に Any-Policy が設定された証明書が含まれる
 205: 認証パスに制約に違反している証明書が含まれる
 206: 認証パスに OCSP での CertStatus が unknown と応答される証明書が含まれる 301: 証明書検証要求に推奨していない暗号アルゴリズムの検証対象証明書が含まれる
 302: 証明書検証要求に推奨していない暗号アルゴリズムの中間証明書もしくはト
ラストアンカーの証明書、または、その両方が含まれる
 901: 証明書検証サーバ側で要求の受付けを拒否した
 902: 要求がタイムアウトとなった
拡張部分への設定フォーマットを次表に示す。
表 2-8 証明書検証結果設定フォーマット
プロトコル要素

指定する値

備考

Object id

1.2.392.200010.10.8 : certPathStatus

独自定義

Critical flag

CriticalValue

0-xxx(integer)62.2.2.2. 認証パス（オプション）
構築した認証パスの全証明書を設定する。
この Extension はオプションであり、１つまたは複数設定される。（証明書検証要求の応答
フォーマットで返却が要求されている場合に限り設定される。）
拡張部分への設定フォーマットを次表に示す。
表 2-9 認証パス設定フォーマット
プロトコル要素

指定する値

備考

Object id

1.2.392.200010.10.9 : CertPath

独自定義

Critical flag

Non Critical

Value

証明書（X.509）

2.2.2.3. CRL/ARL（オプション）
構築した認証パスの証明書について、証明書発行者（OCSP レスポンダを除く）が発行した失効リスト（CRL/ARL）を設定する。
この Extension はオプションであり、１つまたは複数設定される。（証明書検証要求の応答
フォーマットで返却が要求されている場合に限り設定される。）
拡張部分への設定フォーマットを次表に示す。
表 2-10 CRL/ARL 設定フォーマット
プロトコル要素

指定する値

備考

Object id

1.2.392.200010.10.10 : revocationList

独自定義

Critical flag

Non CriticalValue

CRL（X.509）

7

2.2.2.4. OCSP レスポンダからの応答（オプション）
構築した認証パスの証明書について、証明書発行者（OCSP レスポンダに限る）から取得した OCSP 応答情報を設定する。
この Extension はオプションであり、１つまたは複数設定される。（証明書検証要求の応答
フォーマットで返却が要求されている場合に限り設定される。）
拡張部分への設定フォーマットを次表に示す。
表 2-11 OCSP レスポンダからの応答設定フォーマット
プロトコル要素

指定する値

備考

Object id

1.2.392.200010.10.11 : OCSPResponse

独自定義

Critical flag

Non CriticalValue

OCSP レスポンスデータ（RFC2560）

2.2.2.5. 適合したポリシ（オプション）
構築した認証パスの証明書について、検証結果として有効なポリシを設定する。
この Extension はオプションであり、１つまたは複数設定される。（証明書検証要求の応答
フォーマットで返却が要求されている場合に限り設定される。）
拡張部分への設定フォーマットを次表に示す。
表 2-12 適合したポリシ設定フォーマット
プロトコル要素

指定する値

備考

Object id

1.2.392.200010.10.12 : mappedPolicy

独自定義

Critical flag

Non CriticalValue

ポリシの object-id

8

3. 電文フォーマット
証明書検証要求、応答はそれぞれ https(TCP/443)を通信プロトコルとする。証明書検証サーバとの通信で利用する HTTP ヘッダを以下のように定義する。
3.1.

証明書検証要求
表 3-1 証明書検証要求

項番

項目

設定値

区切り

1

Request-line

POST△/△HTTP/1.0

CR+LF

2

entity-header

Content-Type:△application/ocsp-request

CR+LF

Content-Length:△N

CR+LF

3

（空行）

4

entity-body

CR+LF

要求内容

注(1) CR+LF：ASCII コードの 0d(16 進)、0a（16 進）を続けることを示す。
注(2) N：entity-body のバイト長を示す。
注(3) △：空白(ASCII コード 20(16 進))を示す。

3.2.

証明書検証応答
表 3-2 証明書検証応答

項番

項目

設定値

区切り

1

Status-line

HTTP/1.0△200△OK

CR+LF

2

entity-header

Content-Type:△application/ocsp-response

CR+LF

Content-Transfer-Encoding: △Binary

CR+LF

Content-Length:△N

CR+LF

3
4

（空行）
Entity-body

応答内容

注(1) CR+LF：ASCII コードの 0d(16 進)、0a（16 進）を続けることを示す。
注(2) N：entity-body のバイト長を示す。
注(3) △：空白(ASCII コード 20(16 進))を示す。

9

CR+LF

4. 証明書検証要求・応答プロトコル
4.1.

証明書検証要求プロトコル
LGPKI における証明書検証サーバにアクセスする際の証明書検証要求プロトコルを以下に示す。
表 4-1 証明書検証要求プロトコルフィールド

tbsRequest
requestList
reqCerthashAlgorithm
algorithm
parameters
issuerNameHash
issuerKeyHash
serialNumber
singleRequestExtensions(subscriberCert)
extnIdcritical
extnValue-

データ型
OCSPRequest
TBSRequest
SEQUENCE OF Request
RequestCertID（注 2）
AlgorithmIdentifier
OBJECT IDENTIFIERNULL
OCTET STRING
OCTET STRING
CertificateSerialNumber[0]Extensions
Extension
OBJECT IDENTIFIERBOOLEANOCTET STRING
Certificate(intermediateCerts)
extnIdcritical
extnValue(trustAnchorCert)
extnIdcritical
extnValue-

Extension（注 3）
OBJECT IDENTIFIERBOOLEANOCTET STRING
Certificate
Extension
OBJECT IDENTIFIERBOOLEANOCTET STRING
Certificate(requiredPolicy)
extnIdcritical
extnValue-

Extension（注 3）
OBJECT IDENTIFIERBOOLEANOCTET STRINGOBJECT IDENTIFIER(require-explicit-policy)
extnIdcritical
extnValue-

Extension
OBJECT IDENTIFIERBOOLEANOCTET STRINGINTEGER(inhibit-policy-mapping)
extnIdcritical
extnValue-

Extension
OBJECT IDENTIFIERBOOLEANOCTET STRINGINTEGER

10

設定値

必須
(注 1)

1.3.14.3.2.26
20 バイト以下の値を設定する。
20 バイト以下の値を設定する。
シリアル番号を設定する。

◎
△
◎
◎
◎

1.2.392.200010.10.1
TRUE

◎
◎

検証の対象となるsubscriberの証明書を設定する。

◎

1.2.392.200010.10.2
TRUE

△
↑◎
↑◎

中間証明書を設定する。

↑◎

1.2.392.200010.10.3
TRUE

◎
◎

検証依頼者が信頼するルートCAの自己署
名証明書を設定する。

◎

1.2.392.200010.10.4
TRUE
検証依頼者が受け入れるポリシのOIDを設定する。
1.2.392.200010.10.5
TRUE
require-explicit-policyの範囲を設定する。
(注4)
1.2.392.200010.10.6
TRUE
inhibit-policy-mappingの範囲を設定する。
(注5)

△
↑◎
↑◎
↑◎
△
↑◎
↑◎
↑◎
△
↑◎
↑◎
↑◎

(responseFormat)
extnIdcritical
extnValue
requestExtensions(nonce)extnIdextnValue-

Extension
OBJECT IDENTIFIERBOOLEANOCTET STRINGINTEGER[2]
Extensions
Extension
OBJECT IDENTIFIEROCTET STRING
Nonce （注 6）

1.2.392.200010.10.7
TRUE

△
↑◎
↑◎

応答フォーマットを指定する。

↑◎

1.3.6.1.5.5.7.48.1.2◎

1バイト以上32バイト以下の乱数を設定する。

◎

注１ ◎印のあるフィールドは必須である。△印のあるフィールドは、オプションである。↑◎印のあるフィールドには、上欄にフィールドを設けたときは、必須である。
注２ 証明書検証サーバは CertID ではなく Subscriber の証明書で検証対象となる証明書を特定している。
注３

複数指定する場合は、 同じ OID を持つ Extension を複数設定する。

注４ 設定する場合は、必ず「０」を設定する。
注５

本拡張は利用しない。

注６

OCTET STRING としてカプセル化されていること。

4.2.

証明書検証応答プロトコル
LGPKI における証明書検証サーバにアクセスする際の検証応答プロトコルを以下に示す。
表 4-2 証明書検証応答プロトコル
フィールド

responseStatus
responseBytes
responseType
response
tbsResponseData
responderID
producedAt
responses
certID
hashAlgorithm
algorithm
parameters
issuerNameHash
issuerKeyHash
serialNumber
certStatus
unknown
thisUpdate

データ型
OCSPResponse
OCSPResponseStatus[0]
ResponseBytes
OBJECT IDENTIFIEROCTET STRING
BasicOCSPResponse
ResponseData
ResponderID([1])
NameGeneralizedTime
SEQUENCE OF
SingleResponse
SingleResponse
CertID
AlgorithmIdentifier
OBJECT IDENTIFIERNULL
OCTET STRING
OCTET STRING
CertificateSerialNumber
CertStatus(CHOICE)[2] UnknownInfo
GeneralizedTime

11

設定値

必須
(注 1)

0

◎

1.3.6.1.5.5.7.48.1.1◎

署名を行った CVS の電子証明書の「subject」が設定される。
この電文を作成した日時が設定される。

◎

1.3.14.3.2.26
Request で設定した値が設定される。
Request で設定した値が設定される。
Request で設定した値が設定される。

◎
◎
◎
◎
◎

(注 2)
この電文を作成した日時が設定される。

◎◎◎

singleExtensions(certPathStatus)
extnIdcritical
extnValue(certPath)
extnIdextnValue-[1]
Extensions
Extension
OBJECT IDENTIFIERBOOLEANOCTET STRINGINTEGER
Extension（注 3）
OBJECT IDENTIFIEROCTET STRING
CERTIFICATE(revocationList)
extnIdextnValue-

Extension（注 3）
OBJECT IDENTIFIEROCTET STRINGCRL(OCSPResponse)
extnIdextnValue-

Extension（注 3）
OBJECT IDENTIFIEROCTET STRINGOCSPResponse(mappedPolicy)
extnIdextnValue-

Extension（注 3）
OBJECT IDENTIFIEROCTET STRINGOBJECT IDENTIFIER

responseExtensions(nonce)extnIdextnValue
signatureAlgorithm
algorithm
parameters
signature
certs
-

[1]
Extensions
Extension
OBJECT IDENTIFIEROCTET STRING
Nonce
AlgorithmIdentifier
OBJECT IDENTIFIERNULL
BIT STRING[0]
SEQUENCE OF Certificate

1.2.392.200010.10.8
TRUE

◎
◎

証明書検証結果が設定される◎△↑◎

1.2.392.200010.10.9
認証パスで構築された証明書が設定される
1.2.392.200010.10.10
認証パス検証で利用したCRL/ARLが設定される。
1.2.392.200010.10.11
認証パス検証で利用したOCSPResponseが設定される。
1.2.392.200010.10.12

△
↑◎
↑◎
△
↑◎
↑◎
△
↑◎

検証結果として有効なポリシのOIDが設
定される。

↑◎

1.3.6.1.5.5.7.48.1.2◎

Request で設定した値が設定される。

◎

1.2.840.113549.1.1.11−
CVS の署名が設定される。

◎◎◎

CVS の証明書が設定される。

◎

注１ ◎印のあるフィールドは必ず設定される。△印のあるフィールドは、証明書検証要求で指定された場合にのみ設定される。↑◎印のあるフィールドには、上欄にフィールドを設けたときは、必ず設定される。
注２

必ず unknown が設定される。

注３

複数設定される場合は、 同じ OID を持つ Extension が複数設定される。

12↑◎

5. 署名アルゴリズム
証明書検証サーバがサポートする証明書の署名アルゴリズムは以下の通りである。
 sha256WithRSAEncryption
上記署名アルゴリズム以外の証明書を証明書検証要求に設定した場合、証明書検証サー
バは、証明書検証結果に 2.2.2.1 で示した結果コードを応答する。
また、証明書検証サーバは、sha256WithRSAEncryption により署名を行い、レスポンスデー
タには証明書検証サーバ証明書が含まれる。

13