フリースクール（久留米）：２００２年４月３０日 ●証明書のシリアル番号管理について Raserverのデータベースでシリアル番号を管理する． 理由：RAA分割，区分CRLに対応するため，RAA毎にindex.txtが存在する． シリアル番号の衝突を避けるため，シリアル番号の集約をするデータベースが必要． ●CRL配布点について LDAPで配布しようとすると，対応しないアプリケーションがある． LDAPとHTTP間の変換プロキシが必要では？ ●OpenSSLの設定ファイル CAを構築するディレクトリのパスを，各設定ファイル(ca.conf，person.conf，server.conf)の同期をどうするか？ ●CAの秘密鍵の置き場所 RAA毎のディレクトリに置くのはまずいかな？ どこかのディレクトリに固定して，フルパスで記述． ●ユーザー証明書の有効期間 １年と少しにする？オーバーラップの期間をもうける． 実際の期間はRAAのポリシーに依存する． 最長期限の縛りは必要でしょう． ●CRLの発行頻度 RAAのポリシーに依存する． 最低頻度の縛りは必要でしょう 余談：OCSPレスポンダのサービスとか出来たらいいな． ●使用するハッシュについて やっぱりSHA1の方がいいかなあ？ ●RAAページについて RAAの証明書を発行するページが必要では？ そのページにアクセスする権限の管理が必要では？ ●文字列の最大値は？ commonName_max = 64 emailAddress_max = 64 ●extendedKeyUsage RAAのポリシーに依存する． ●policyConstraints CACAnet Class A CAでは無しでいこう． PASS検証に関係する項目だけど，CACAnetはPASS検証しない． ●S/MIME処理の不具合 From行が認識されない．重大な問題である．改行コードの問題かな？ 桑山さんが言っていた，バイナリモードを試してみる必要有り． ●設定ファイルの整理 CA用，person用，server用と整理しないとね． 2002年5月13日 ●policy constraints問題 Windows XP Home EditionでのIE6では，フィールドの存在は理解している． ただし，値がおかしいと判断している？ Windows2000上では，フィールドの存在を理解できない． フィールドを理解できるのは，Windows XPじゃないとダメなのでは？ XPではフィールドの値がおかしいので，「無効なポリシーがある」 ということで，ＣＡの証明書を信頼しないという問題がある． Policy Constraintを外してCAの証明書を作成． そのCAからユーザー証明書を作成して実験をした． ●新しい証明書での実験結果 ・WindowXPな方 CAとユーザーの証明書の組込に成功． IE6.0とNS6.2では問題なかった． ・Windows2000な方 IE5.5とWinbiff 2.34PL1＋S/Goma2.12では問題なかった． Mozillaでは，本文に日本語を使わないと送ることが可能．検証中． 文字コードを変えたら，うまくいった模様． ・MAC OS X mozilla 1.0RC2日本語リソース入りでは，Winbiff 2.34PL1＋S/Goma2.12 から送った署名・暗号化メールは，「メッセージに署名が含まれていない」 というふうにでてしまう． 日本語化を行わなければ，PKCS#12ファイルの読み込みが出来る． ただし，CAの証明書を消してから入れなおさないといけない． ●CRL配布点について 区分CRLを置く場所の問題があるのでは？ 現状は以下のとおり．www.cacanet.orgに決め打ちしてしまっている． X509v3 CRL Distribution Points: URI:http://www.cacanet.org/CACAnetClassACA/CACAnetClassACA.crl ●Friendly Name は，CA証明書もユーザー証明書は入れたほうがいい？入れないほうがいい？ ユーザー側で入れるようにしておいたほうがいい？ フリースクール（久留米）：２００２年７月８日 ●証明書の廃棄 　「CACAnetの証明書廃棄システム説明会」の見直し 　　http://cvs.cacanet.org/fsc/revoke/0827.html 　○証明書廃棄ページのインターフェース 　　・廃棄する証明書の電子メールアドレスやシリアル番号を入力． 　　・対応する証明書の内容を表示して確認． 　　　（リポジトリから検索するようにする？） 　　・その証明書を廃棄要請． 証明書廃棄申請の方法は，RAに任せる． 廃棄ページというよりは，リポジトリと連携を取った 証明書検索のページにするほうがいいだろう． 検索項目は，電子メールアドレス，シリアル番号，名前など． RA権限をもつ人がアクセスした場合は， 「廃棄」が出来るというイメージになるのではないか？ 　○だれが廃棄可能にするか？（RAのCPSによる？） 　　他の機関のRAが廃棄できないようにする必要はある． 　　証明書を発行したRAのみが廃棄可能にする？ 　　それとも，同じ機関のRAなら，誰でも廃棄可能にする？ 　　また，それを制御するインターフェースは必要か？ 制御のインターフェースを作る． 発行したRA以外が廃棄可能か不可能かの二択のみをサポート． 　○廃棄の履歴 　　どのRAが，どのSubjectの証明書を廃棄したかの履歴を残す必要があるか？ 　　必要ならば，どのように残して，どのようなアクセス制御が必要か？ RAが発行した証明書と廃棄した証明書のシリアルリストとかが要るだろう． 配列とかリストとかのデータ構造に入れることになる．Pstoreが便利かな？ 　○RAが不正を行った場合， 　　そのRAから発行された証明書をまとめて廃棄する仕組みが必要か？ バッチ処理する仕組みは必要だろう．発行や廃棄も含めて． でも，これは将来的な話ではないだろうか？ 　○廃棄する時間の制約 　　CRLを発行する時間に重ならないように制約を設けるか？ 証明書の発行と廃棄が重なるほうが危険だろう． CRLについてはインデックスファイルの読み込みだけなので， 特に気にしないでいいのではないか？ ●CRLの発行 　「CACAnetの証明書廃棄システム説明会」の見直し 　　http://cvs.cacanet.org/fsc/revoke/0827.html 　○CRLのバージョンは１でいくか？ 　○CRLのバージョンが２なら，どんな拡張を入れるか？ 　　・crlEntry extensionは，OpenSSLの仕様上ダメ 　　・cRLNumberはサポートしていない 現ＣＰＳ７章ではバージョン１になっているが， バージョンは１と２の両方を発行する． プロファイルは，http://cvs.cacanet.org/fsc/revoke/0827.htmlを参照． ************************************************************************** OpenSSL 0.9.7 b2では，crlEntry extensionをサポートしているらしい． これは，将来的な構想になるだろう． ************************************************************************** 　○CRLの中に，RevokeをしたRA名を残す必要があるか？ CRLの仕様的に無理． 　○区分CRLへの対応 　　index.txtを分割するかしないか？ 　　・index.txtを分割する場合 　　　分割するのなら，Serialをどこで管理するか？ 　　　RAServer側か？CA側か？ 分割する方向でいく． 証明書の発行や廃棄時に，処理が複雑になる． シリアル番号の管理は，やっぱりCAでやるのが合理的だと思う． 　　・index.txtを分割しない場合 　　　CRL発行時にRA名をキーに抜き出して，RA毎にインデックスデータを作成． 　　　そのインデックス使って区分CRLを発行する． この場合は，証明書の発行や廃棄時は特に問題は生じないが， CRLを発行する時に処理が複雑になる． 　○サーバー群（CA，RAserver，LDAP）の時刻校正をどうするか？ 　　NTPサーバーを動かすか？動かすならどこで動かすか？ dns.cacanet.orgで，NTPサーバーを動かす． あと，ズレの許容範囲をどうするか？ 以下のリポジトリへの設置方法では，１分ずつずらして設置になっているので， それに見合う許容範囲にするべきであろう． ------------------------------------------- でも，将来的にはGPS装備が理想ですね． ------------------------------------------- 　○CRLリポジトリへの設置方法 　　HTTPSやLDAPSを使って，定期的に設置するしかないか 午前３時〜４時頃は，システムがデータベースを構築している時間帯なので避ける． 午前５時頃に，CA -> RAserver -> LDAPと１分ずつずらして設置する． フリースクール（久留米）：２００２年７月１７日 東様の質問に答える形式で行った． １．　証明書の発行 @　各資料の確認（基本仕様書） ・「個人証明書発行手続き」の資料は、以下の資料を示すのですか？ http://cvs.cacanet.org/doc/index.html CACAnetの証明書発行システム　2001年6月15日　 「個人証明書発行手続き」の資料は，次の証明書発行システム仕様書のことを示す． http://cvs.cacanet.org/spec/b_spec.pdf ・システムの「ディレクトリ構造」の資料？　見当たらないと思います。 （システムは、ＲＡ・ＲＡｓｅｒｖｅｒが該当しますか？） システムの「ディレクトリ構造」の資料は，大体作成してあるので公開する． システム正常系 １．１　発行依頼申請（詳細設計） （１）　ｓｕｂｊｅｃｔの登録項目は、どのような情報ですか？ ・ｓｕｂｊｅｃｔメールアドレス ・ｓｕｂｊｅｃｔ氏名 （個人情報の内容はどこまで必要ですか？　　ＲＡのＣＰＳで確定した項目になりますか？） 基本的にはSubjectのメールアドレスとローマ字氏名のみ． RAAのCPSによって増やすことは可能． （２）　登録ページ・確認ページ・承諾ページ（ＯＫ・ＮＧ）の画面レイアウトは 　どのようになっていますか？ 実際の画面を確認してもらう． （３）　各画面の入力チェックはどのようになっていますか？ 基本的に入力チェックは行わず確認画面によってチェックする ただし、Subjectの入力情報としてCACAnetとしての必須入力情報の部分に関しては 空白もしくは不当なアドレスチェックを行う。 　・ローマ字氏名 　・電子メールアドレス （４）　画面の入力順番はどうなっていますか？ 「Subject向け手引書」を参照　（まだWeb上には公開されていない部分） 異常（５）　入力ミス時のエラー内容及び処置はどうなりますか？ （エラー情報をメッセージファイルで管理しますか？）　エラー仕様はどのようなものですか？ エラーの内容に対して逐一対応する （６）　ＤＢ構造はどのようになっていますか？（ファイルレイアウトはどのようになっていますか？） セッションＴＢＬ構造等 （セッションＩＤとセッション状態コード（コードの意味は？コード仕様が必要）） DB構造はどうなっているかについて討論中 DB構造のセッション管理のデータベース部分にしては，現在のscdb.rbのSCDBプログラム部分にあるrd形式で書かれたものが大枠であり，それを元にDB構造の仕様書を作成． RADBも同様． （７）　秘密情報の生成する仕様はありますか？ （関数になっていますので無いですね関数仕様がありますか） 10桁の10進乱数を使用． （８）　秘密情報及びセッションＩＤをｓｕｂｊｅｃｔに渡す情報はどのような項目ですか？ 異常（９）　秘密情報を生成中障害が発生した時、再生成することが可能ですか？ （どのような処置になるのですか？） この場合は異常システムが発動しますので，エラーページが出力し「ふりだしにもどる」となっている．次のバージョンで厳密に対処． 異常（１０）　秘密情報とセッションＩＤの情報は食い違いが発生しないのですか？ （バージョン等） 秘密情報とセッションIDは同一のレコードで管理しているのでシステム的に食い違いはおきず，Subject側で食い違いをおこしていたらエラーとなる． （１１）　秘密情報をｓｕｂｊｅｃｔへ渡す場合は、どのような受け渡しをするのですか？ （媒体であれば、ファイル名及び内容が必要と思います） ファイルのネーミングルールがありますか？ アウトオブバンドです。 １．２　証明書申請手続き（詳細設計） （１）　Ｓｕｂｊｅｃｔの秘密情報とセッションＩＤの入力画面の画面レイアウトはどのようになっていますか？ 秘密情報は，アウトオブバンドにてい得た情報を書き込む． セッションIDは，メールで通達が来るURLの中に情報が入っている． （２）　入力項目は秘密情報（入力内容及び桁）とセッションＩＤのみですか？ 秘密情報だけ． （３）　入力値が不整合の時、どのような処置になりますか？ （ｓｕｂｊｅｃｔに対し、エラーを表示し再入力をしてもらうか、システム管理者へ依頼となりますか） セッションIDが異なる場合は，異常処理によりセッションが存在しない旨を告げる． 秘密情報が異なる場合は，異常処理により秘密情報が異なるという旨を告げる． SCDBの仕様を変更して，5回失敗した場合は「ふりだしにもどる」とする 異常（４）　秘密情報及びセッションＩＤの有効期間はありますか？ （ｓｕｂｊｅｃｔが申請をしなかった場合） 有効期間はある．プログラム的にはstate.rbをまとめる． その期間が妥当かどうかは考えていない． 現状はそのまま． （５）　ｓｕｂｊｅｃｔの個人情報の入力ページでの個人情報はどのような項目になりますか？ 　画面レイアウトはどのようになりますか？ （ＲＡのＣＰＳ検討） 運用しながらきめる．RAのCPSによる． （６）　各画面の入力チェックはどのようになりますか？ 運用しながらきめる． （７）　画面の入力順番はどうなっていますか？ （８）　入力ミス時のエラー内容及び処置はどうなりますか？ （９）　ＤＢ構造はどのようになっていますか？（ファイルレイアウトはどのようになっていますか？） セッションＤＢ構造等 まとめて、先に話した内容と同じ． （１０）鍵生成方法の選択ページのレイアウトはどのようになりますか？ PKCS12か鍵ペアをブラウザで生成の２択 １．３　鍵生成（詳細設計） @　ＲＡｓｅｒｖｅｒでの鍵生成 （１）　Ｐｋｃｓ＃１２のパスワード入力ページレイアウトはどのようになっていますか？ レイアウトは見てもらう． パスワード入力は，HTMLフォームのパスワード入力にて任意の文字を入力． パスワードは２回入力して，そのチェックをJavaScriptにて確認． 長さの制限はしていない．運用実験で調整． （２）　入力チェックはどのようになりますか？ JavaScriptを使って確認． （３）　パスワードの保存を保存する場所（フォルダ）及びレイアウトはどのようになりますか？ セッションが切れるのでパスワードを再利用しないといけないため，SCDBに生で保存． 生でなくハッシュなどにするとしたら，証明書発行手続きのながれを変えなければならないので，次期バージョンへの検討事項とする． （４）　このパスワードはいつまで有効ですか？ SCDBにパスワードを入れているが，システム的には１．２（４）で話した セッション保存時間がシステム的なパスワード保持期間になる． （５）　鍵の生成後、保存場所（フォルダ場所）と保存期間？ PKCS12ファイル中の秘密鍵の扱いは，運用しながら考える．． 秘密鍵ファイルを消すかどうかは運用中に考える． 秘密鍵のモードが不適切なので，モード変更する必要有り． デフォルトのumask設定と，パーミッションの変更をするという二重チェックを行う． 異常（６）　鍵生成時、なんらかの障害で生成出来なかった場合は、どのような処置になりますか？ （生成時、Ｓ／ＭＩＭＥ時） 現在は鍵生成時にエラーが出た場合の処理は現状ではできていない． もし起きた場合は再チャレンジ可能にする． （７）　個人情報確認のページはどの様な構成になりますか？（ディレクトリ構造を参照ですか？） Subjectの個人情報なども含む入力情報は，AのCPSによる． 確認ページは入力された情報をそのまま出力し，本人による確認． （８）　個人情報確認ページの管理はどのようになりますか？ 個人情報の管理確認という面では，RAのCPSに依存する． （９）　秘密情報とセッションＩＤをもっている人は、何回もパスワード更新が可能ですか？（勉強不足） P12作成前では可能だが，P12作成後は不可能． 表向きは出来ないが、裏技的な方法を用いれば可能な状況になる． A　ｋｅｙｇｅｎでの鍵生成（　よく理解していませんすみません） （１）　鍵生成ページのレイアウトはどのようになっていますか？ レイアウトは本物を見てもらうとして， 発行システムの画面ではなくてIEのレイアウトになる． （２）　鍵の生成情報は、何回もｒｅｑｕｅｓｔ可能ですか？ これも表向きは出来ないが、裏技的な方法を用いれば、可能な状況にもなる． BＩＥで鍵生成（他のブラウザの評価をどこまでの範囲としますか？） １．３Aと同じ． （１）　鍵生成ページのレイアウトはどのようになっていますか？ 本物を見てもらって確認してもらう． （２）　鍵の生成情報は、何回もｒｅｑｕｅｓｔ可能ですか？ これも表向きは出来ないが、裏技的な方法を用いれば、可能な状況にもなる． １．４　個人情報確認と証明書発行（詳細設計） （１）　ＲＡの確認ページは誰でも参照することが可能ですか？ RAしか参照できない．他の団体のRAも参照できない． （２）　個人情報確認のレイアウトはどのようになっていますか？ レイアウトは本物を見てもらう． RAのCPSによった，Subjectの入力した個人情報が出力され確認． （３）　個人情報確認受理の判断は、なんですか？ RAのCPSによる． （４）　Ｐ１２での生成とその他での生成判断条件情報はどこで管理されていますか？ SCDBで管理． （５）　各個人用証明書はどのように管理されるのですか？ （証明書の有効期間は、どのときから１年間有効になりますか） リポジトリによって管理．管理はリポジトリ運用方針による． リポジトリの運用方針をつくる必要有り． １．５　証明書の取得（詳細設計） （１）　本人確認ページのレイアウトはどのようになっていますか？ 証明書の取得のフェーズでは　本人確認はしない． 本人確認をしなくても良いかと議論が進んだが， PKCS12の証明書取得画面はPKCS12のパスワードレベルでの セキュリティレベルということで， 現状の証明書発行手続きのままですすめる． （２）　入力チェックはどのようになりますか？ 　（セッションＩＤ入力） （３）　入力エラーは、どのようになりますか？ これらは１．５（１）があった場合は必要だが，このシステムが無いので不要． フリースクール（久留米）：２００２年７月１９日 ●証明書の入手 　○LDAPリポジトリの仕様 　・使用する文字コード 　　　ASCIIのみにする． 　　　RFC2459とRFC3280では，2003年12月31日以降はDNはUTF8がMUSTなので， 　　　UTF8への対応は考えておく必要がある． 　・DNの仕様 　　以下のとおりとする．OUの階層は，これ以上増やさない． countryName = Country name countryName_default = JP 0.organizationName = Organization Name 0.organizationName_default = CACAnet Fukuoka 1.organizationName = RAA Name (eg, company) 1.organizationName_default = CACAnet Fukuoka Members RAA 0.organizationalUnitName = Organizational Unit Name (eg, section) 0.organizationalUnitName_default = member（または明示的に部署を指定） 1.organizationalUnitName = Entity Type 1.organizationalUnitName_default = person（サーバー証明書ならserver） 2.organizationalUnitName = RA serial 2.organizationalUnitName_default = RA証明書のシリアル番号 commonName = User Name commonName_max = 64 emailAddress = Email Address emailAddress_max = 64 　・証明書を登録するスキーマ 　　inetOrgPersonクラスのuserCertificate属性に，Binaryデータとして登録． 　・CRLを登録するスキーマ 　　cRLDistributionPointのcertificateRevocationListに，Binaryデータとして登録？ 　　CNを入れないといけないのだが，CNが何者かわからないので，調べる必要あり． objectclass ( 2.5.6.19 NAME 'cRLDistributionPoint' SUP top STRUCTURAL MUST ( cn ) MAY ( certificateRevocationList $ authorityRevocationList $ deltaRevocationList ) ) 　○リポジトリからの削除 　　リポジトリには最新の証明書のみを上書きして登録し， 　　過去の証明書は他の場所に保管しておく． ●CAのエラーコード 　CAマシンが返すHTTP ResponseのBody部分に以下のデータを入れておき， 　RAserverがそのデータを見て判断するようにする． 　　・肯定応答 +OK -----BEGIN CERTIFICATE----- .... -----END CERTIFICATE----- 　　・否定応答 -ERR Error_Code 　　・Error_Codeについて 　　　１：CAの秘密鍵のパスワードファイルオープンエラー 　　　２：新しいシリアル番号の生成エラー 　　　３：Requestデータのエラー 　　　　　空データ，フォーマットエラーなど 　　　４：OpenSSL実行時のエラー 　　　　　起動エラー 　　　　　実行時の何らかのエラー 　　　　　　署名失敗 　　　　　　インデックスファイルのアップデートミスなど 久留米で議論２：００２年７月２２日 山村，大岡，永井，遠藤，田代 現在の発行システムの仕様では， OU（部署名）についてはRAの証明書のものを引き継ぐようになっています． しかし，RAAからRAになる人に証明書を発行する場合，RAAとRAは部署名が異なってきます． よって，RAAからRAの証明書を発行する場合を考えなくてはいけないと思います． 昨日話した内容では，RAAがアクセスしてきた時には， S000のところで，部署名を入力するフォームを出すようにすればいいのではないか？ ということです．デフォルトでは，RAAの部署名を入れておくほうがいいですかね？ 部署データは，セッションデータベースに入れておきます． また，RAの証明書をリポジトリに登録する時は， OU（部署名）のディレクトリエントリが作成されていないので， OUのディレクトリを作ってからRAの証明書を登録するということになると思います． それから，秘密情報を入れるところで，秘密情報を間違った時の処理です． ５回失敗したら振り出しに戻るようにしたほうがいいという意見になっていますが， これを実現するには，セッション管理データベースで扱う項目を増やす という方向に行きたいと思います． 久留米で議論：２００２年７月２６日 メンバー：田代，山村，永井，遠藤 ○リポジトリから証明書の検索 ・証明書のシリアル番号での検索は出来ない． 　（それでいいのかな？） ・検索ページのインターフェースは， 　検索の項目（CNやemailAddress，OUなど）を入力するフォームを並べる． 　（あいまい検索のようなものは必要か？） ・DNで使うローマ字はヘボン式とする． ○証明書の廃棄 ・失効理由の入力 　失効理由については，RFC2459の"5.3.1 Reason Code"で規定されているものを使う． ・どのRAが廃棄したかについての管理 ○証明書廃棄リスト ・RFC2459ではcRLNumberは必須だが，OpenSSL0.9.6dでは未対応． 　今回の仕様ではcRLNumberは無しにする． OpenSSLの機能制限を考えると，証明書廃棄管理データベースが必要な気がします． 　・廃棄された証明書のシリアル番号 　・廃棄された理由(Reason Code) 　・廃棄したRAの情報（シリアル番号など） が入っているようなものです． 久留米で議論：２００２年７月２９日 山村，大岡，永井，遠藤，田代 リポジトリの構造 ********************** LDIF形式データ ************************ dn: o=CACAnet Fukuoka,c=JP objectClass: top objectClass: organization o: CACAnet Fukuoka dn: o=CACAnet Members RAA,o=CACAnet Fukuoka,c=JP objectClass: top objectClass: organization o: CACAnet Members RAA dn: ou=CACAnet Class A Members RA,o=CACAnet Members RAA,o=CACAnet Fukuoka,c=JP objectClass: top objectClass: organizationalUnit ou: CACAnet Class A Members RA dn: ou=0BC7D08ECC4CE340676D10071BE4C80B,ou=CACAnet Class A Members RA,o=CACAnet Members RAA,o=CACAnet Fukuoka,c=JP objectClass: top objectClass: organizationalUnit ou: 0BC7D08ECC4CE340676D10071BE4C80B dn: ou=person,ou=0BC7D08ECC4CE340676D10071BE4C80B,ou=CACAnet Class A Members RA,o=CACAnet Members RAA,o=CACAnet Fukuoka,c=JP objectClass: top objectClass: organizationalUnit ou: person dn: CN=Shoji endo,OU=person,OU=0BC7D08ECC4CE340676D10071BE4C80B,OU=CACAnet Class A Members RA,O=CACAnet Members RAA,O=CACAnet Fukuoka,C=JP objectClass: top objectClass: inetOrgPerson sn: Shoji cn: Shoji endo dn: Email=shoji@syslabo.co.jp,CN=Shoji endo,OU=person,OU=0BC7D08ECC4CE340676D10071BE4C80B,OU=CACAnet Class A Members RA,O=CACAnet Members RAA,O=CACAnet Fukuoka,C=JP objectClass: top objectClass: inetOrgPerson sn: Shoji cn: Shoji endo mail: shoji@syslabo.co.jp userCertificate:: MIIG3TCCBcWgAwIBAgIQD46bUYfyl9lWtywnCdpMHDANBgkqhkiG9w0BAQUFADBXMQswCQYDVQQG ….. リポジトリを登録する場所のDNは，証明書を解析して作成する． DNの電子メールは"Email"を使う．"emailAddress"は，OpenSSLを0.9.7にバージョンアップした時に考える．