CACAnet勉強会資料

2001年8月27日（月曜）
講師：田代勝也（CACAnet福岡，システムラボラトリー株式会社）
tashiro@cacanet.org　tashiro@syslabo.co.jp
参考資料
- RFC2459 CACANetによるRFC2459日本語訳
- PKI ；カーライル・アダムズ、スティーブ・ロイド著、鈴木優一訳、ピアソン・エディケーション；ISBN4-89471-248-2
- CACAnet勉強会資料（山崎重一郎） http://cvs.cacanet.org/fsc/revocation.html
- OpenSSLホームページ http://www.openssl.org

CACAnetの証明書廃棄システム説明会

１．概要

CACAnetの個人会員および団体会員とその構成員を対象として発行された X.509デジタル証明書を廃棄(Revoke)し，証明書失効リストCRLを発行するシステムを作成するための設計についての説明である．

システムの構成内容，証明書の破棄に必要な情報，CRLの構成，問題点などについてである．なお，この仕様はまだ未完成であり，これから検討すべき問題である．

２．システム構成

End entity：証明書の検証者: 証明書が有効かどうかを検証する人．
RA：証明書記録者およびシステム: 証明書の破棄を要請する人およびそのシステム．
RA Server：RA Serverシステム: RAからの要求によって，証明書破棄を行うセッションを管理するサーバーシステムである．RAから証明書破棄の要求を受けると， CAに対してSSLのClient認証で接続する．強固なセキュリティで守る必要がある．
CA：証明書破棄，証明書失効リスト作成システム: 証明書の管理と発行・破棄を行うシステム． CAシステムには人間は介入せず，RAからの証明書破棄要求によって自動的に証明書の発行を行う．証明書失効リストCRLを定期的に自動作成し，CRL配布点に設置する．最高の強度のセキュリティで守る必要がある．
CRL Distribution Point：証明書失効リストの配布場所: 証明書の拡張領域に記載された配布場所． CRLは，CAシステムで定期的に作られるものを設置する．
Repository：証明書の配布場所: ディレクトリサーバーによる証明書の配布場所．廃棄する証明書の情報を入手する．

 +-------------+     +--------------+     https(c)     +--------+
 |     CA      |     |  RA server   |<-----------------|   RA   |
 |+-----------+|     |+------------+|                  +--------+
 || index.txt ||https||    CRL     ||
 |+-----------+|<----|+------------+| https(c)
 |+-----------+| (c) |+------------+|<------+
 ||certificate||     ||RA server DB||       |
 |+-----------+|     |+------------+|       |
 +-------------+     ++-------------+       |
                             ^              |
                             |              |
             +---------------+              |LDAP
             |  https(c)                    v
             |                 +-------------+
     +--------------+          | Repository  |
     |  CRL  Point  |          |+-----------+|  LDAP  +----------+
     |+------------+|          ||certificate||<-------|End Entity|
     ||    CRL     ||          |+-----------+|        +----------+
     || repository ||          +-------------+              |
     |+------------+|<--------------------------------------+
     |+------------+|                https(s)
     ||  old CRL   ||
     |+------------+|
     +--------------+
https(c): SSLのクライアント認証付きhttpセッション
https(s): SSLのサーバー認証のみhttpセッション
S/MIME(es): S/MIMEの暗号化と署名付きメール
S/MIME(s): S/MIMEの署名付きメール

システムで必要なソフトウェア

CA
OS	FreeBSD-4.3 Release
System Script	Ruby: version 1.6.4 eRuby: version 0.9.5
httpd/SSL	Apache: version 1.3.20 mod_SSL: version 1.3.28
CA,CRL	OpenSSL: version 0.9.6b

RA Server

OS
FreeBSD-4.3 Release
System Script Ruby: version 1.6.4
eRuby: version 0.9.5

httpd/SSL Apache: version 1.3.20
mod_SSL: version 1.3.28
S/MIME OpenSSL: version 0.9.6b

RA Server
OS
FreeBSD-4.3 Release
System Script	Ruby: version 1.6.4 eRuby: version 0.9.5
httpd/SSL	Apache: version 1.3.20 mod_SSL: version 1.3.28
S/MIME	OpenSSL: version 0.9.6b

CRL Point

OS
FreeBSD-4.3 Release
System Script Ruby: version 1.6.4
eRuby: version 0.9.5

httpd/SSL Apache: version 1.3.20
mod_SSL: version 1.3.28
http/SSL OpenSSL: version 0.9.6b

CRL Point
OS
FreeBSD-4.3 Release
System Script	Ruby: version 1.6.4 eRuby: version 0.9.5
httpd/SSL	Apache: version 1.3.20 mod_SSL: version 1.3.28
http/SSL	OpenSSL: version 0.9.6b

Repository

OS FreeBSD-4.3 Release
System Script Ruby: version 1.6.4
eRuby: version 0.9.5

httpd/SSL Apache: version 1.3.20
mod_SSL: version 1.3.28
LDAP OpenLDAP: version 2.0.15
Cyrus-SASL: version 1.5.24

３．機能

証明書の廃棄で必要な情報

CRLには，以下のような情報が記載される．

バージョン(Version)
整数の１が設定されている場合は，バージョン２
署名アルゴリズム(Signature)
発行者(Issuer)
更新時間(This Update)
次回更新時間(Next Update)
失効証明書(Revoked Certification)：証明書のシリアル番号のリスト

失効された証明書のエントリーごとの拡張として，以下のような情報が記載される．

理由コード(Reason Code)
理由コードについては，以下のようなものを入れる．
- 鍵漏洩
- CA弱体化
- 所属変更
- 破棄
- 運用停止
無効日時(Invalidity Date)

CRLの拡張として，以下のものを入れる．

認証機関識別子(Authority Key Identifire)
発行者別名(Issuer Alternative Name)
CRL番号(CRL Number)

ソフトウェアの機能制限

OpenSSL(version 0.9.6b)

「crlEntry Extensions（失効証明書ごとの拡張領域）」はサポートしていないため，「reasonCode（理由コード）」「invalidityDate（推定無効日）」などが使えない．
「crlExtensions（失効リスト拡張領域）」についても，サポートしているのは「issuerAltName（発行人別名）」「AuthorityKeyIdentifier（認証機関鍵識別子）」のみ．
「cRLNumber（CRL番号）」についてサポートしていない（発行されたCRLの順番について，電子署名で完全性を証明できない）

Netscape Communicator

V2のCRLを扱うことが出来ない．
RFC2459では，V2のCRLは必須になっている．

CACAnetでは，OpenSSLを使ってCAの構築を行うので，CACAnetのCRLでは，以下の情報を記載することにする．（CRL version2の場合）

  CertificateList  ::=  SEQUENCE  {
        tbsCertList          TBSCertList,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

   TBSCertList  ::=  SEQUENCE  {
        version                 Version,
        signature               AlgorithmIdentifier,
        issuer                  Name,
        thisUpdate              Time,
        nextUpdate              Time OPTIONAL,
        revokedCertificates     SEQUENCE OF SEQUENCE  {
             userCertificate         CertificateSerialNumber,
             revocationDate          Time,
                                }
         crlExtensions          SEQUENCE OF SEQUENCE  {
             AuthorityKeyIdentifier  keyid,Dirname,CertificateSerialNumver
                                    }
                                  }

発行されるCRLに記載される内容の具体例

Certificate Revocation List (CRL):
        Version 2 (0x1)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: /C=JP/O=CACAnet Fukuoka/OU=CA/CN=CACAnet Class A CA
        Last Update: Aug 27 06:21:08 2001 GMT
        Next Update: Aug 28 06:21:08 2001 GMT
        CRL extensions:
            X509v3 Authority Key Identifier:
                keyid:57:B1:7C:1C:0F:00:BC:A9:60:EA:0A:02:4B:65:7D:37:90:A4:D2:EA
                DirName:/C=JP/O=CACAnet Fukuoka/OU=CA/CN=CACAnet Class A CA
                serial:00

Revoked Certificates:
    Serial Number: 4620B4FEE5EFC11415212AC5993E03F0
        Revocation Date: Aug 27 06:21:05 2001 GMT
    Serial Number: 4FF946854C03507735E1605FAA6104E0
        Revocation Date: Aug 27 06:21:05 2001 GMT
    Signature Algorithm: md5WithRSAEncryption
        24:ae:bc:4d:25:e7:55:6d:00:99:e3:89:ac:62:14:8b:2a:f6:
        2f:4b:91:e5:16:53:1a:85:2f:12:07:08:06:b2:4a:8b:aa:22:
        87:c0:b9:c2:83:09:f7:e1:7f:03:86:9e:21:4c:12:ed:c5:4f:
        0d:ca:9d:d1:ff:bd:11:a1:5f:b1

ASN.1の構造

    0:d=0  hl=4 l= 416 cons: SEQUENCE
    4:d=1  hl=4 l= 330 cons:  SEQUENCE
    8:d=2  hl=2 l=   1 prim:   INTEGER           :01
   11:d=2  hl=2 l=  13 cons:   SEQUENCE
   13:d=3  hl=2 l=   9 prim:    OBJECT            :md5WithRSAEncryption
   24:d=3  hl=2 l=   0 prim:    NULL
   26:d=2  hl=2 l=  81 cons:   SEQUENCE
   28:d=3  hl=2 l=  11 cons:    SET
   30:d=4  hl=2 l=   9 cons:     SEQUENCE
   32:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
   37:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :JP
   41:d=3  hl=2 l=  24 cons:    SET
   43:d=4  hl=2 l=  22 cons:     SEQUENCE
   45:d=5  hl=2 l=   3 prim:      OBJECT            :organizationName
   50:d=5  hl=2 l=  15 prim:      PRINTABLESTRING   :CACAnet Fukuoka
   67:d=3  hl=2 l=  11 cons:    SET
   69:d=4  hl=2 l=   9 cons:     SEQUENCE
   71:d=5  hl=2 l=   3 prim:      OBJECT            :organizationalUnitName
   76:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :CA
   80:d=3  hl=2 l=  27 cons:    SET
   82:d=4  hl=2 l=  25 cons:     SEQUENCE
   84:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
   89:d=5  hl=2 l=  18 prim:      PRINTABLESTRING   :CACAnet Class A CA
  109:d=2  hl=2 l=  13 prim:   UTCTIME           :010827062108Z
  124:d=2  hl=2 l=  13 prim:   UTCTIME           :010828062108Z
  139:d=2  hl=2 l=  70 cons:   SEQUENCE
  141:d=3  hl=2 l=  33 cons:    SEQUENCE
  143:d=4  hl=2 l=  16 prim:     INTEGER           :4620B4FEE5EFC11415212AC5993E03F0
  161:d=4  hl=2 l=  13 prim:     UTCTIME           :010827062105Z
  176:d=3  hl=2 l=  33 cons:    SEQUENCE
  178:d=4  hl=2 l=  16 prim:     INTEGER           :4FF946854C03507735E1605FAA6104E0
  196:d=4  hl=2 l=  13 prim:     UTCTIME           :010827062105Z
  211:d=2  hl=2 l= 125 cons:   cont [ 0 ]
  213:d=3  hl=2 l= 123 cons:    SEQUENCE
  215:d=4  hl=2 l= 121 cons:     SEQUENCE
  217:d=5  hl=2 l=   3 prim:      OBJECT            :X509v3 Authority Key Identifier
  222:d=5  hl=2 l= 114 prim:      OCTET STRING
  338:d=1  hl=2 l=  13 cons:  SEQUENCE
  340:d=2  hl=2 l=   9 prim:   OBJECT            :md5WithRSAEncryption
  351:d=2  hl=2 l=   0 prim:   NULL
  353:d=1  hl=2 l=  65 prim:  BIT STRING

CRLのRAによる分割

CRLは，RAごとに作成・配布を行うようにする（区分CRL）．これを実現するには，発行された証明書のデータベースを，RAごとに分割する必要がある．このとき，証明書のシリアル番号については，すべてのRAを通じて一意でないといけない．

証明書破棄(Revoke)の手順

Subjectは，秘密鍵の漏洩など，証明書破棄の要請．
RAは，RA Serverの証明書破棄のためのページにアクセス．（SSL Client認証）
RAは，廃棄すべきSubjectの情報を，RA Serverに入力
RA ServerからCAに，破棄すべき証明書のシリアル番号を通達．（SSL Client認証） CAに対して証明書廃棄を要請する．　　（RA Serverに，発行された証明書を保存しておく必要がある？それともデータベースにシリアル番号を保存しておくか？）
CAは，通達されたシリアル番号の証明書をRevoke．
RAは，個人情報のデータベースにRevokeフラグを立てる．（それとも，個人情報を削除？）

    < CA >           < RA Server >           < RA >
                                        +---------------+
                                        | Revokeの要請  |
                                        +---------------+
               +------------------------+ https(c)|
               |Revokeする証明書のSerial|<--------+RA権とRA名のチェック(DN?)
               +------------------------+
+----------------+ https(c)|
| 証明書のRevoke |<--------+証明書のRA名をチェック(DN?)
+----------------+
        |            +------------+
        +----------->|Revokeの通知|
          https(c)   +------------+

最後に，運営委員に対して，廃棄の情報を送る．（S/MIMEの署名メール？）

CRLの発行手順

CAは一日１回CRLを発行し，RA ServerにCRLを転送．（cronで実行）
RA Serverから，WWWのCRL distribution Pointsに転送．
　（WWW側で一日１回とかcronで実行か？）


   < CA >         < RA Server >      < CRL配布点 >        < End entity >

+---------+
|CRLの作成|
+---------+
     |           +---------+
     +---------->|CRLの入手|
       https(c)  +---------+
                      |              +---------+
                      +------------->|CRLの設置|
                      https(c)       +---------+
                                          |                +---------+
                                          +--------------->|CRLを入手|
                                                https(s)   +---------+

CRLについては，何らかの方法で「CRL配布点」に置く必要がある．一日１回，Client認証のhttpsで，cronとかで取ってくる？

４．問題点

OpenSSLの機能制限のため， CRL Numberについて扱うことが出来ない．(RFC2459では必須)
（CRLの発行順番の証明が出来ない）
他に，invalidityDate（推定無効日），reasonCode（理由コード）などが扱えない．
Netscape Communicatorは，Version2のCRLを扱うことが出来ない．
RAとCAの時間の同期はどうするか？
RA ServerとCAの時間のズレによる問題は？

５．おまけ

OpenSSLコマンドの使い方

証明書のシリアル番号の表示
$ openssl x509 -noout -serial -in cert.pem
証明書の廃棄（Revoke）
$ openssl ca -revoke cert.pem
CRLv1の発行
$ openssl ca -gencrl -out crl.pem
CRLv2の発行(CRL Extensionを指定)
$ openssl ca -gencrl -crlexts crl_ext -out crl.pem

OpenSSLの証明書データベース

OpenSSLの場合，発行された証明書のデータベースは，テキストファイルの形式で保存される．一行につきひとつの証明書が対応する．フィールド間はタブ文字で区切られている．各フィールドの意味については，以下のとおりである．

有効・無効フラグ　有効時間　（廃棄時間）　シリアル番号　？　Subject名(DN)

有効・無効フラグ	「V」が有効(Valid)，「R」が廃棄(Revoke)されているという意味
有効時間	証明書の有効な期限
（廃棄時間）	証明書が廃棄された時間
シリアル番号	証明書のシリアル番号．あるCAについて一意な番号．
？	（わかりませんでした）
Subject名(DN)	証明書の所持主体のDistinguished Name

以下に実例を載せる．「user02」の証明書については，廃棄されていることがわかる．このデータベースをもとにCRLが作成される．

V       020827035435Z           AA834FF9550AD8953CBAD6016BF0A339        unknown	/C=JP/O=CACAnet Fukuoka/OU=CACAnet Class A Members RA1/OU=person/CN=user01/Email=user01@cacanet.org
R       020827035436Z   010827035722Z   A688B7FC3B49F86B75F4421B46937C9E	unknown /C=JP/O=CACAnet Fukuoka/OU=CACAnet Class A Members RA1/OU=person/CN=user02/Email=user02@cacanet.org
V       020827035436Z           D6DAF69B8BA143510A5DF0F20D40050F        unknown	/C=JP/O=CACAnet Fukuoka/OU=CACAnet Class A Members RA1/OU=person/CN=user03/Email=user03@cacanet.org
V       020827035436Z           931DCFFF6D7F0F1E59B0551C1B51FBDA        unknown	/C=JP/O=CACAnet Fukuoka/OU=CACAnet Class A Members RA1/OU=person/CN=user04/Email=user04@cacanet.org
V       020827035437Z           53144CE5AA6CFDA3A9EAE69179422468        unknown	/C=JP/O=CACAnet Fukuoka/OU=CACAnet Class A Members RA1/OU=person/CN=user05/Email=user05@cacanet.org

区分CRLの実験スクリプト

ここからダウンロードして遊んでみてください．

OpenSSLの設定ファイルと，証明書データベースのテキストファイルを分割することによって，区分CRLを実現しています．証明書の廃棄やCRLの発行の際は，証明書の中に記載されたRAの名前（DNのなかのOUに記載）を見て，OpenSSLの設定ファイルを切り替えています．

証明書のシリアル番号は，32桁の16進数の乱数を使っています．全てのRAを通してシリアル番号を一意なものにするために，証明書データベースのテキストファイルを全て検索し，シリアル番号がぶつからないようにしています．

CAの構築
$ ./mkca.sh

２つの証明書データベース（index_RA1.txt，index_RA2.txt）を作っています．
OpenSSLの設定ファイルは，CACAnetClassACA_RA1.cnfと
CACAnetClassACA_RA2.cnfの２つを使っています．
証明書の発行
$ ./cert_issue.sh

user01からuser05までがCACAnet Class A Members RA1で，
user06からuser010までがCACAnet Class A Members RA2です．
証明書の廃棄(revoke) $ ./revoke.sh user03.crt user08.crt

user03とuser08の証明書を廃棄する場合．（複数の証明書を指定可）
CRLの発行
$ ./crl.sh

RA*.crlというファイルが出来ます．
CRLの確認
RA1v2.crlの中身を確認するには

$ openssl crl -noout -text -in RA1v2.crl

すべて消去して最初からやり直すには，

$ ./clear.sh

を実行します．

フリースクール中で出た話

区分CRLを実現するだけなら，CRLのバージョンは１でいいのでは．→ RFC2459では，CRL Version2は必須項目になっている．
システム構成のなかに，リポジトリの証明書を検証する人がいるのでは？
CRLを発行したRAが悪い人だったら？悪いRAから発行されたCRLが出回ったらどうするか？
RA Serverに，Revokeしたい人のメールアドレスを入力すると，証明書のDNやシリアル番号が返ってくるインターフェースがいるのでは？
区分CRLを実現するには，RAごとにOpenSSLの設定ファイルと証明書データベースファイルが必要になるが，OpenSSLの設定ファイルを動的に生成するとかっこいい？
CRLの中に，RevokeしたRAの名前を残す必要があるのでは？
CAとRA Serverのシステム時計の精度については，CPSに記載する必要があるのでは？