CACAnet Fukuoka
2005年07月04日
証明書DNについて再考
EE用の証明書について、DNを再考しました。
２番目のOはRAA名を入れるので、RAAの文字は入れずに団体名を入れればいいと思います。OUには、認証用はClient Auth、署名用はClient Signとします。以下にDNの例を示します。LDAPディレクトリも、以下のDNをベースに作り変えました。
認証用証明書の例
CN=TASHIRO Katsuya, Email=tashiro@cacanet.org, OU=Client Auth, O=CACAnet Members, O=CACAnet Fukuoka, C=JP
署名用証明書の例
CN=TASHIRO Katsuya, Email=tashiro@cacanet.org, OU=Client Sign, O=CACAnet Members, O=CACAnet Fukuoka, C=JP
Posted by tashiro at 02:03 | Comments (2) | TrackBack
2005年04月07日
鍵用途
拡張領域で、鍵用途関連のパラメタをどう定義するかを決定した。
extendedKeyUsageにcriticalを設定していないが、
これは設定してもいいかもしれない。
EEsignは、署名用、EEauthは、SSLのクライアント認証用という位置付け。
RAAAは、EEauthと同様とする。
[EEsign]
keyUsage = critical,digitalSignature,nonRepudiation,keyEncipherment,keyAgreement
extendedKeyUsage = codeSigning,emailProtection
basicConstraints = critical,CA:false
[EEauth]
keyUsage = critical,digitalSignature,keyEncipherment,keyAgreement
extendedKeyUsage = clientAuth
basicConstraints = critical,CA:false
[Server]
keyUsage = critical,digitalSignature,keyEncipherment,keyAgreement
extendedKeyUsage = serverAuth
basicConstraints = critical,CA:false
[CA]
keyUsage = critical,cRLSign,keyCertSign
extendedKeyUsage = serverAuth,timeStamping
basicConstraints = critical,CA:true,pathlen:2
Posted by fujino at 17:30 | Comments (0) | TrackBack
2005年04月03日
SOAPで呼び出される各サーバープロセスのメソッド名
●EEserver
○ees_set_access_info(session_id,access_key_hash,email,kanji_name,romaji_name)
１．RAserverのCGIよりセッション情報を受け取る。
２．EEに証明書発行手続きのメールを送信する。
※SMTPエラーについて
存在しないメールアドレスを書いた時に、通信エラーと出てしまう。
・ees_issue_p12(p12_password,session_id,access_key)
１．EEserverのCGIよりリクエストを受け取る。
２．RAserverのras_issue_p12を呼び出す。
３．２が失敗したらリトライ。
●RAserver
○ras_issue_p12(p12_password,session_id)
１．EEserverのサーバープロセスより証明書発行のリクエストを受け取る。
２．セッション管理ファイルより証明書情報を読み出す。
３．IAサーバのias_issue_p12を呼び出し、証明書発行のリクエストを送信する。
４．IAサーバからPKCS12と証明書を受け取る。
５．LDAPに証明書を登録する。
●IAserver
○ias_issue_p12(p12_password,key_length,o,ou,cn,emailAddress,issuerAltName,friendy_name)
１．RAserverより証明書発行のリクエストを受けとる。
２．証明書を発行してRAserverに返す。
Posted by tashiro at 22:00 | Comments (6) | TrackBack
Net::SMTPのエラー
メールを送るときに、メールアドレスが存在しない場合、なぜか、
Net::SMTPServerBusy
450: Recipient address rejected:...
というようなエラーが出る。要するに、そんなユーザ知らんよ、とSMTPサーバが言っている訳だが、Ruby的に返されるクラスはNet::SMTPServerBusy。ま、いいんだけどね…
Posted by fujino at 16:23 | Comments (0) | TrackBack
SOAP&Rubyでのエラー処理
Ruby上のSOAPの場合、サーバ上のエラーをクライアント側でどのように検知するか、と言う話。簡単に言うと
* raiseされる例外クラスが、サーバとクライアントで共に定義されている場合：クライアントでもその例外クラスをrescueすることができる
* そうでない場合：クライアント側ではRunTimeErrorとして扱われる
ということだ。では、例題プログラムで確認しよう。まず、サーバ側:
#!/usr/bin/env ruby
require 'webrick'
require 'soap/rpc/httpserver'
require 'soap/rpc/driver'
class MyError < StandardError; end
class RAServer < SOAP::RPC::HTTPServer
def on_init
@log.level = Logger::Severity::DEBUG
add_method(self,'myerror')
end
def myerror
raise MyError,"This is an error."
return 0
end
end
server = RAServer::new(
:SOAPHTTPServerApplicationName => "myerror",
:SOAPDefaultNamespace => "http://localhost/soap/",
:BindAddress => "0.0.0.0",
:Port => 1969,
:AccessLog => []
)
trap(:INT) do
server.shutdown
end
server.start
要するに、独自に定義したMyErrorをraiseするサービスだ。次にクライアント側：
#!/usr/bin/env ruby
require 'webrick'
require 'soap/rpc/httpserver'
require 'soap/rpc/driver'
class MyError < StandardError; end
s = SOAP::RPC::Driver::new("http://localhost:1969/","http://localhost/soap/")
s.add_method("myerror")
s.wiredump_file_base = "myerror"
s.options["protcol.http.receive_timeout"]=300
ret = s.myerror
では実行してみよう。まずサーバ側を実行すると、正しく起動される。続いてクライアント側を実行する。
fujino@chimera{~/Works/MyError}$ ./error-client.rb
./error-server.rb:15:in `myerror': This is an error. (MyError)
from /CACAnet/app/ruby-1.8.2/lib/ruby/1.8/soap/rpc/router.rb:259:in `call'
from /CACAnet/app/ruby-1.8.2/lib/ruby/1.8/soap/rpc/router.rb:259:in `rpc_call'
from /CACAnet/app/ruby-1.8.2/lib/ruby/1.8/soap/rpc/router.rb:240:in `call'
from /CACAnet/app/ruby-1.8.2/lib/ruby/1.8/soap/rpc/router.rb:86:in `route'
from /CACAnet/app/ruby-1.8.2/lib/ruby/1.8/soap/rpc/soaplet.rb:108:in `do_POST'
from /CACAnet/app/ruby-1.8.2/lib/ruby/1.8/soap/rpc/soaplet.rb:103:in `with_headerhandler'
from /CACAnet/app/ruby-1.8.2/lib/ruby/1.8/soap/rpc/soaplet.rb:103:in `do_POST'
from /CACAnet/app/ruby-1.8.2/lib/ruby/1.8/webrick/httpservlet/abstract.rb:35:in `__send__'
... 15 levels...
from /CACAnet/app/ruby-1.8.2/lib/ruby/1.8/soap/rpc/driver.rb:275:in `call'
from /CACAnet/app/ruby-1.8.2/lib/ruby/1.8/soap/rpc/driver.rb:302:in `myerror'
from /CACAnet/app/ruby-1.8.2/lib/ruby/1.8/soap/rpc/driver.rb:297:in `myerror'
from ./error-client.rb:13
fujino@chimera{~/Works/MyError}$
というわけで、クライアント側でもMyErrorが定義してあるので、MyErrorをrescueできている。
Posted by fujino at 14:54 | Comments (0) | TrackBack
2005年04月02日
非同期、と思ったけど
実装するのは結構大変だ、と言うが前のエントリの考察で判明した。
そもそも論にまで立ち戻って考えてみて、もっとも大きな問題は、EEに対するウェブの応答時間が長くなることだ。であれば、そこだけを非同期にすればよいのではないか、という議論になった。
すなわち、EEからのウェブアクセスに対しては、「発行要求を受付けました」と即時応答し、別のプロセスがRAserverに対してPKCS#12発行を要求する。ここから先は、上り(req)下り(resp)別の非同期方式ではなく、同期方式で行く。ユーザへの応答時間は気にする必要はないので、何十秒かかっても構わない。タイムアウトすれば、しばらく待ってリトライしてもいいのではないか。
Posted by fujino at 17:57 | Comments (0) | TrackBack
非同期サービスとサービス命名規則
現状のシステムは、同期サービスで実現されている。この方式だと、各サーバ間の通信の途中、サーバの負荷が高い場合等に処理を保留された場合に問題が発生する。例えば、EEからのHTTPリクエストがタイムアウトしてしまう等だ。
この問題を解決するために、非同期サービスで実装する。つまり、今まで一つのSOAPメソッドであったものを、
- サーバ上の要求(req)用のメソッドと、
- 応答受付(resp)用のメソッド
の二つに分ける。
サービス名の命名だが、これはシステム全体で一意になった方が良かろう、ということで、命名規則を作った。
[サーバ名]_[サービス名]_[方向]
ここで言う方向とは、上で述べたreqおよびrespのことである。
サーバ名を付けるのは例えば、PKCS#12ファイルの発行を要求するメソッド(issue_p12)は、RAserverにもCAにも存在する。何故なら、EEからのPKCS#12発行要求は、EEserverで受付けられ、これがSOAPでRAserverに送られ、RAserverからCAへ SOAPで送られるためだ。
この方式を採用すると、サーバからクライアントへの通信(resp)のあて先がどこになるのかを、サーバが知る必要がある。これに関しては、
- SOAPの通信元IPを何らかの方法で知る
- クライアントからサーバへの通信(req)のパラメータに埋め込む
の二つが考えられる。前者が自然だが、SOAPの下位層をIPに固定したり、ポート番号を固定することになる。後者は面倒ではあるが柔軟であるので、後者で実装する。
後者でクライアントからサーバへ渡すべき情報は、URIのみになる。SOAPのRPC呼び出しには、URIの他にメソッド名が必要になるが、これは上の命名規則で決まっているので、渡さなくても問題はない。
書くのを忘れていたが、この非同期方式を採用すると、上り(req)下り(resp)の通信が一対であることを確認するため、セッションIDつける必要がある。
Posted by fujino at 16:03 | Comments (0) | TrackBack
2005年01月10日
Ruby でXML-RPCを使ってMovableTypeに投稿する
Ruby 1.8.2 の環境でXML-RPC でMovable Typeを制御する方法
#----
require "xmlrpc/client"
content={"title" => "記事のタイトル", "description" => "本文の内容"}
server = XMLRPC::Client.new("サーバー名","/パス/mt-xmlrpc.cgi")
r = server.call('metaWeblog.newPost','1','ユーザID','パスワード',content,true)
#----
第２引数の'1' はblogID で、何番目のブログかという番号です。一つしかないなら１。
詳しくは、MovableTypeのマニュアルページ参照
Posted by yamasaki at 01:42 | Comments (0) | TrackBack
2004年12月10日
セッションファイル置き場
[EEサーバ]
/CACAnet/cgi-bin/data/ee
[RAサーバ]
/CACAnet/cgi-bin/data/ra
Posted by yamamie at 19:13 | Comments (0) | TrackBack
2004年12月03日
サーバー間通信用ポート番号
22時48分にRAサーバへのサーバー間通信用ポートを許可するフィルタにしました。
Posted by yamamie at 22:55 | Comments (1) | TrackBack
プログラムファイル説明
●RAサーバ
セッション開始：section1.html (Apache)
本人確認情報を生成：section2.cgi (Apache)
----------------------------------------
PKCS#12証明書発行依頼：section3.cgi (デーモン)
●EEサーバ
本人確認情報受付：ee-serv.cgi (デーモン)
PKCS#12パスワード入力要求：cert_request1.cgi (Apache)
証明書発行依頼：cert_request2.cgi (Apache)
●IAサーバ
サーバー間通信＆署名プログラム：/home/ia/Works/Issue/iaserver.rb (デーモン)
Posted by yamamie at 20:15 | Comments (1) | TrackBack
2004年10月18日
コミュニティPKIビルダの仕様パート3
2004年10月18日の作業で変更した、PKCS#12での証明書発行のためのアクティビティ図です。
View image
Posted by admin at 23:04 | Comments (0) | TrackBack
創造主の誕生
C=JP, O=CACAnet Fukuoka, OU=CA, CN=RAA Manager
藤野さんの証明書発行スクリプトを参考に、上記の証明書を誕生させました。証明書データベースは、PostgreSQLを使っています。
Posted by tashiro at 22:59 | Comments (1) | TrackBack
2004年10月15日
神様のＤＮ
一番最初に発行する「神様」の証明書について、以下のＤＮにすることにしました。
C=JP, O=CACAnet Fukuoka, OU=CA, CN=RAA Manager
この証明書を使って、各ＲＡＡの証明書を発行していくことになります。
つまり、CACAnet Communityの創造主となるのです・・・
Posted by tashiro at 20:24 | Comments (1) | TrackBack
2004年10月11日
サーバ間通信のインターフェース
-------------------------------------------
EEサーバ
■本人確認情報受付
メソッド名：send_access_key
引数/型：
本人確認情報（本人確認情報のsha-1ハッシュ）：access_key:int
e-mailアドレス：email:String
日本語氏名：kanji_name:String
ローマ字氏名：romaji_name:String
------------------------------------------
IAサーバ
■p12での証明書発行
メソッド名：issue_p12
引数：
p12パスワード：p12_password:String
鍵長：key_length:int
o：o:String
ou:ou:String
cn:cn:String
emailアドレス:emailAddress:String
IssuerAltName(RA証明書のシリアル番号@ra.cacanet.org):issuerAltName:String
フレンドリー名：friendly_name:String
返値：
p12(PEM?):p12:String
証明書(PEM?)：cert:String
------------------------------------------
RAサーバ
■証明書発行依頼
メソッド名：req_p12
引数：
p12パスワード：p12_password:String
本人確認情報（本人確認情報のsha-1ハッシュ）：access_key:int
返値：
なし
永井です。
10/18の作業でのアクティビティー図を見ながらコードレビューを行った際に気
づいた点です。
（アクティビティー図は山村さんに修正してもらいブログに掲載されています。）
以下、サーバ間通信のインターフェースにける修正点です。
問題がなければブログへ載せてください。
x印の付いた行が変更箇所です。
|サーバ間通信のインターフェース
|-------------------------------------------
|EEサーバ
|■本人確認情報受付
|メソッド名：send_access_key
|引数/型：
x|セッション情報：session_id:String
x|本人確認情報（本人確認情報のsha-1ハッシュ）：access_key:String
|e-mailアドレス：email:String
|日本語氏名：kanji_name:String
|ローマ字氏名：romaji_name:String
|
|------------------------------------------
|IAサーバ
|
|■p12での証明書発行
|メソッド名：issue_p12
|引数：
|p12パスワード：p12_password:String
|鍵長：key_length:int
|o：o:String
|ou:ou:String
|cn:cn:String
|emailアドレス:emailAddress:String
|IssuerAltName(RA証明書のシリアル番号@ra.cacanet.org):issuerAltName:String
|フレンドリー名：friendly_name:String
|
|返値：
x|p12(DER):p12:String
|
|------------------------------------------
|RAサーバ
|
|■証明書発行依頼
|メソッド名：req_p12
|引数：
|p12パスワード：p12_password:String
x|セッション情報：session_id:String
|返値：
|なし
以上です。
Posted by yamasaki at 20:51 | Comments (0) | TrackBack
コミュニティPKIビルダの仕様
2004年10月11日の集中作業で変更した、PKCS#12での証明書発行のためのアクティビティ図です。
cbp-p12-20041011.png
Posted by yamamie at 20:24 | Comments (0) | TrackBack
C16rディレクトリ構成
C16rでのサーバそれぞれのファイルパスを以下に記載します。
○ライブラリ関係ファイルＰＡＴＨ ※EEサーバ，ＲＡサーバ，ＩＡサーバ共通
(RubyのライブラリPATH)/C16r/
○プログラムファイルＰＡＴＨ
[EEサーバ] ※ApacheのCGI
(任意のPATH)/C16r/EE/
[RAサーバ] ※ApacheのCGI
(任意のPATH)/C16r/RA/
[IAサーバ]
(任意のPATH)/C16r/IA/
Posted by yamamie at 17:34 | Comments (0) | TrackBack
soap4r + SSLのつまらない例
Ruby4RとSSLを使う簡単な例題
サーバのプログラム
Download file
クライアントのプログラム
Download file
サーバではon_initで@webrick_configにSSL関係の設定を行います。
Posted by sazuka at 15:15 | Comments (1) | TrackBack
ディレクトリの名前空間の構成の変更案２
ディレクトリの名前空間の構成について、再検討しました。
●クランベクターの仕様
クランベクターの実現のために、ＲＡの電子メールアドレスを使うように検討していた。しかし、証明書のバージョンについてが分からなくなる問題があることがありそうなため、以前のようにＲＡのシリアル番号を使うことにする。証明書への具体的な入れ方については、後述の「証明書の仕様」を参照。
●ディレクトリの名前空間構成
以下のように変更する。
○RA証明書のシリアル番号のOUをなくす
○OU=person/serverをディレクトリエントリーから外して、属性に変更する。
○同姓同名がいた場合は、CNに適宜数字などを入れる。
＜＜例＞＞
/C=JP/O=CACAnet Fukuoka/O=Members RAA/OU=admin/CN=YAMAMURA Tomohiro/emailAddress=yamamie@cacanet.org
●証明書の仕様
以下の内容を、拡張領域'「IssuerAltName」に入れる。
○RA証明書のシリアル番号@cacanet.org
＜＜OpenSSLの設定ファイル例＞＞
issuerAltName=email:A7FFCE925B0F4018A3D9D58340C8C6CC@cacanet.org
Posted by tashiro at 13:11 | Comments (3) | TrackBack
2004年06月06日
CommunityPKIBuilderLib version 0.2
C16rLib version 0.2をリリースしました→CommunityPKIBuilderLib-0.2.tar.gz。
Posted by fujino at 18:49 | Comments (0) | TrackBack
C16Rクラス図
RAサーバとEEサーバのクラス図です。
Download file
Posted by yamasaki at 15:49 | Comments (0) | TrackBack
2004年05月05日
EEサーバとRAサーバの状態図
EEサーバの状態図
EEserver-state.png
RAサーバの状態図
RAserver-state.png
Posted by yamasaki at 19:04 | Comments (0) | TrackBack
コミュニティPKIビルダの仕様
2004年5月5日の集中作業で決定した、PKCS#12での証明書発行のためのアクティビティ図です。
cpb-p12-20040505.png
Posted by yamasaki at 16:55 | Comments (0) | TrackBack
2004年03月28日
OpenSSLでのCSRの拡張領域について
クランベクターを実現するため、証明書のissuerAltNameにRAの電子メールアドレスを入れるという方針になっています。
その際、リクエスト(CSR)の拡張領域にissuerAltNameを入れておいて、CAがCSRに署名をする際に拡張領域をコピーする方法が分かりましたので、ここに記載します。
OpenSSLの設定ファイル（関連がある部分のみ抜粋）
*************************************************************************************************************
[ ca ]
default_ca = CA_default # The default ca section
[ CA_default ]
dir = CACAnetClassACA # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
new_certs_dir = $dir/newcerts # default place for new certs.
certificate = $dir/cacert.pem # The CA certificate
serial = $dir/serial # The current serial number
crl = $dir/crl.pem # The current CRL
private_key = $dir/private/cakey.pem# The private key
RANDFILE = $dir/private/.rand # private random number file
x509_extensions = v3_user # The extentions to add to the cert
copy_extensions = copy # この設定で、CSR拡張領域からコピーが行われる。
[ req ]
default_bits = 512
default_keyfile = cakey.pem
distinguished_name = req_distinguished_name
attributes = req_attributes
req_extensions = req_extensions # CSR拡張領域を記述するセクション名の指定
[ req_extensions ]
issuerAltName = email:${ENV::RA_EMAIL} # CSR拡張領域で issuerAltName を設定
# 以下、署名で使われる証明書拡張領域では、 issuerAltName の設定はされていない。
[ v3_user ]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
keyUsage = critical,digitalSignature,nonRepudiation,keyEncipherment,keyAgreement,dataEncipherment
extendedKeyUsage= clientAuth,codeSigning,emailProtection,timeStamping
policyConstraints=DER:3005A003020103
certificatePolicies=ia5org,@polsect
[polsect]
CPS=http://www.cacanet.org/CACAnetClassACA/ClassAMembersRACPS.html
userNotice=@notice
[ notice ]
explicitText="This certificate is issued for your PKI as a non-profit public service."
organization="Citizen's Association for Certification Authority Network Fukuoka"
noticeNumbers=1
*************************************************************************************************************
あとは、上記の設定ファイルを使って、通常通りにCSR生成と署名を行うだけです。
＜＜例＞＞
●CSRデータ
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=JP, O=CACAnet Fukuoka, OU=CACAnet Class A Members RA1, OU=person, CN=TASHIRO Katsuya/emailAddress=tashiro@cacanet.org
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (512 bit)
Modulus (512 bit):
00:a8:58:25:ad:d7:0d:62:47:76:e6:e3:80:a3:d1:
a2:a7:52:f6:8f:84:ce:61:4e:b1:a2:c5:5f:a5:68:
9b:76:97:0b:bf:40:c4:b6:4b:d6:9d:f3:38:fc:e9:
e2:a8:8d:a2:d5:16:54:1b:2b:9c:87:b6:29:98:8d:
cc:ed:ef:c4:71
Exponent: 65537 (0x10001)
Attributes:
Requested Extensions:
X509v3 Issuer Alternative Name:
email:ra@cacanet.org
Signature Algorithm: md5WithRSAEncryption
7b:4e:b8:a3:86:93:e8:8e:dc:6d:30:a7:c8:4a:ad:e9:2d:e9:
cc:f4:2d:31:b5:f6:6c:5c:7d:c8:06:7c:c7:9c:27:e9:06:99:
38:21:be:bd:a5:e4:5a:bb:7a:fb:c5:fb:9e:78:1e:c3:b7:d1:
a2:c9:76:8d:81:c3:37:7f:74:05
●証明書データ
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
8c:a2:2b:1b:9c:eb:8f:bf:d1:76:8e:90:9e:ba:87:eb
Signature Algorithm: md5WithRSAEncryption
Issuer: C=JP, O=CACAnet Fukuoka, OU=CA, CN=CACAnet Class A CA
Validity
Not Before: Mar 28 07:58:53 2004 GMT
Not After : Mar 28 07:58:53 2005 GMT
Subject: C=JP, O=CACAnet Fukuoka, OU=CACAnet Class A Members RA1, OU=person, CN=TASHIRO Katsuya/emailAddress=tashiro@cacanet.org
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (512 bit)
Modulus (512 bit):
00:a8:58:25:ad:d7:0d:62:47:76:e6:e3:80:a3:d1:
a2:a7:52:f6:8f:84:ce:61:4e:b1:a2:c5:5f:a5:68:
9b:76:97:0b:bf:40:c4:b6:4b:d6:9d:f3:38:fc:e9:
e2:a8:8d:a2:d5:16:54:1b:2b:9c:87:b6:29:98:8d:
cc:ed:ef:c4:71
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
7A:F7:A4:6F:EF:15:BF:09:48:B2:7A:B4:F2:AB:E4:A2:43:66:D4:71
X509v3 Authority Key Identifier:
keyid:4F:64:5A:38:C8:19:80:A9:D3:23:43:93:C5:35:FA:8C:27:AA:85:17
DirName:/C=JP/O=CACAnet Fukuoka/OU=CA/CN=CACAnet Class A CA
serial:00
X509v3 Key Usage: critical
Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment, Key Agreement
X509v3 Extended Key Usage:
TLS Web Client Authentication, Code Signing, E-mail Protection, Time Stamping
X509v3 Policy Constraints:
0......
X509v3 Certificate Policies:
Policy: ccitt
CPS: http://www.cacanet.org/CACAnetClassACA/ClassAMembersRACPS.html
User Notice:
Organization: Citizen's Association for Certification Authority Network Fukuoka
Number: 1
Explicit Text: This certificate is issued for your PKI as a non-profit public service.
X509v3 Issuer Alternative Name:
email:ra@cacanet.org
Signature Algorithm: md5WithRSAEncryption
b0:a1:b3:10:28:97:02:4f:90:a6:47:9a:9c:fe:e9:66:af:a9:
21:b9:fa:0b:16:b5:40:8c:99:51:57:19:d2:6e:63:2e:89:b1:
03:5f:ca:de:ca:6a:a3:d8:0a:df:a7:47:17:ec:7e:c8:a6:6d:
90:34:96:89:7f:12:59:d4:89:64
Posted by tashiro at 17:29 | Comments (0) | TrackBack
2004年03月27日
ディレクトリ構築手順
新しい仕様のディレクトリ構築を、手動にて行いました。以下に手順を載せます。
１．エントリー追加のLDIFデータ作成
$ vi testdata.ldif
****************************************************************************************************************
dn: O=CACAnet Fukuoka,C=JP
objectClass: top
objectClass: organization
o: CACAnet Fukuoka
dn: O=Members RAA,O=CACAnet Fukuoka,C=JP
objectClass: top
objectClass: organization
o: CACAnet Fukuoka
o: Members RAA
dn: OU=admin,O=Members RAA,O=CACAnet Fukuoka,C=JP
objectClass: top
objectClass: organizationalUnit
ou: admin
dn: Email=yamamie@cacanet.org,OU=admin,O=Members RAA,O=CACAnet Fukuoka,C=JP
objectClass: top
objectClass: inetOrgPerson
sn: YAMAMURA
cn: YAMAMURA Tomohiro
mail: yamamie@cacanet.org
dn: CN=YAMAMURA Tomohiro,Email=yamamie@cacanet.org,OU=admin,O=Members RAA,O=CACA
net Fukuoka,C=JP
objectClass: top
objectClass: inetOrgPerson
sn: YAMAMURA
cn: YAMAMURA Tomohiro
mail: yamamie@cacanet.org
****************************************************************************************************************
２．上記エントリーをディレクトリサーバに追加。
$ /CACAnet/app/openldap/bin/ldapadd -H 'ldap://ldap.cacanet.org/' -W -D 'cn=Manager,o=CACAnet Fukuoka,c=JP' -f testdata.ldif
Password:********
３．DER形式の証明書データを準備し、上記ディレクトリエントリーのuserCertificate;binary属性に追加するLDIFデータを作成。
$ vi cert.ldif
****************************************************************************************************************
dn: CN=YAMAMURA Tomohiro,Email=yamamie@cacanet.org,OU=admin,O=Members RAA,O=CACAnet Fukuoka,C=JP
objectClass: top
objectClass: inetOrgPerson
sn: YAMAMURA
cn: YAMAMURA Tomohiro
mail: yamamie@cacanet.org
userCertificate;binary:< file:///home/tashiro/temp/yamasaki_raa.der
****************************************************************************************************************
３．DER形式の証明書データを準備し、上記のディレクトリエントリーの属性に追加。
$ /CACAnet/app/openldap/bin/ldapmodify -H 'ldap://ldap.cacanet.org/' -W -D 'cn=M
anager,o=CACAnet Fukuoka,c=JP' -f cert.ldif
４．メールアドレスにて検索を実行。
$ /CACAnet/app/openldap/bin/ldapsearch -H 'ldap://ldap.cacanet.org/' -b 'o=CACAnet Fukuoka, c=JP' '(mail=yamamie@cacanet.org)' 'userCertificate;binary'
dn: Email=yamamie@cacanet.org,OU=admin,O=Members RAA,O=CACAnet Fukuoka,C=JP
dn: CN=YAMAMURA Tomohiro,Email=yamamie@cacanet.org,OU=admin,O=Members RAA,O=CA
CAnet Fukuoka,C=JP
userCertificate;binary:: MIIGlDCCBXygAwIBAgIQVrmhowWHM8JSaCB2a5383DANBgkqhkiG9
w0BAQUFADBbMQswCQYDVQQGEwJKUDEYMBYGA1UEChMPQ0FDQW5ldCBGdWt1b2thMQswCQYDVQQLEw
JDQTElMCMGA1UEAxMcQ0FDQW5ldCBGdWt1b2thIENvbW11bml0eSBDQTAeFw0wNDAxMTAwODMxNDZ
aFw0wNTAxMDkwODMxNDZaMIGqMQswCQYDVQQGEwJKUDEYMBYGA1UEChMPQ0FDQW5ldCBGdWt1b2th
MRQwEgYDVQQKEwtNZW1iZXJzIFJBQTEMMAoGA1UECxMDUkFBMQowCAYDVQQLEwEwMQ8wDQYDVQQLE
wZwZXJzb24xHTAbBgNVBAMTFFlBTUFTQUtJIFNoaWdlaWNoaXJvMSEwHwYJKoZIhvcNAQkBFhJ0b2
50b25AY2FjYW5ldC5vcmcwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMUPRhicle6yJgmetoL
SuqIE5Cfi3j2+DAjvhvQxERmkaaXzsiACYj9t1H0XXzrTTmCU7WBs8YOdQ4tZAanBIuyDk0KvMVqT
Wt62kqncuBtRyPO5fMNLlXmSAyMDj1LHC414g/bCHZgmP7gQ14CwGMUpHNociSMxg5+JCJowyXDrA
gMBAAGjggOGMIIDgjAdBgNVHQ4EFgQUYcGu6Wl2MlpyO0V12mzt4CnHLyMwgYMGA1UdIwR8MHqAFC
hGpymnO6zDaARmetOMUKPHdijjoV+kXTBbMQswCQYDVQQGEwJKUDEYMBYGA1UEChMPQ0FDQW5ldCB
GdWt1b2thMQswCQYDVQQLEwJDQTElMCMGA1UEAxMcQ0FDQW5ldCBGdWt1b2thIENvbW11bml0eSBD
QYIBADAOBgNVHQ8BAf8EBAMCA/gwMQYDVR0lBCowKAYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFB
QcDBAYIKwYBBQUHAwgwHQYDVR0RBBYwFIESdG9udG9uQGNhY2FuZXQub3JnMIGBBgNVHR8EejB4MD
qgOKA2hjRodHRwOi8vd3d3LmNhY2FuZXQub3JnL0NvbW11bml0eUNBL01lbWJlcnNSQUEtdjEuY3J
sMDqgOKA2hjRodHRwOi8vd3d3LmNhY2FuZXQub3JnL0NvbW11bml0eUNBL01lbWJlcnNSQUEtdjIu
Y3JsMIIB8wYDVR0gBIIB6jCCAeYwgesGCgKDOIybHAAAAAAwgdwwNwYIKwYBBQUHAgEWK2h0dHA6L
y93d3cuY2FjYW5ldC5vcmcvQ29tbXVuaXR5Q0EvQ1BTLmh0bWwwgaAGCCsGAQUFBwICMIGTMEgWQU
NpdGl6ZW4ncyBBc3NvY2lhdGlvbiBmb3IgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTmV0d29yayB
GdWt1b2thMAMCAQEaR1RoaXMgY2VydGlmaWNhdGUgaXMgaXNzdWVkIGZvciB5b3VyIFBLSSBhcyBh
IG5vbi1wcm9maXQgcHVibGljIHNlcnZpY2UuMIH1BgoCgziMmxwAAAEAMIHmMEEGCCsGAQUFBwIBF
jVodHRwOi8vd3d3LmNhY2FuZXQub3JnL0NvbW11bml0eUNBL01lbWJlcnNSQUFDUFMuaHRtbDCBoA
YIKwYBBQUHAgIwgZMwSBZBQ2l0aXplbidzIEFzc29jaWF0aW9uIGZvciBDZXJ0aWZpY2F0aW9uIEF
1dGhvcml0eSBOZXR3b3JrIEZ1a3Vva2EwAwIBARpHVGhpcyBjZXJ0aWZpY2F0ZSBpcyBpc3N1ZWQg
Zm9yIHlvdXIgUEtJIGFzIGEgbm9uLXByb2ZpdCBwdWJsaWMgc2VydmljZS4wDQYJKoZIhvcNAQEFB
QADggEBAMIGxzxMMbgBL/DqfMPnGYMGSHh4wLumuVfE/gxXH/OX2Bvv2Uec/Ov6vSywU/BnC170Ox
7T33LTZ3fnthyE6GC3Q5cYxdQhahPl6i0Ghk0tC2a6NqB0Bjfvxd1patILXy9mmRb6VHeCEx4qfQo
MKsEN97YnweafR459feR+QdQ5qEBsAtspP8OfAdLPMSiz3dZX4inFA8/QyBCazdfXdqnvIo3xL+sa
RiuY4uA3Z402n6GwbPczjFHcTsFS51oHmHXkc255eocICPcBXIkMySw5btfcQcuhEep2p0BGv0Oq3
cdGJPDcUSo5GNKeRrSZbN2WM3HMVzPnQ5JgoXdCTwg=
Posted by tashiro at 21:25 | Comments (0) | TrackBack
ディレクトリサーバの設定
OpenLDAPのslapdデーモンについての設定
***********************************************************************************************
include /usr/local/openldap/etc/openldap/schema/core.schema
include /usr/local/openldap/etc/openldap/schema/cosine.schema
include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema
pidfile /usr/local/openldap/var/slapd.pid
argsfile /usr/local/openldap/var/slapd.args
database ldbm
suffix "o=CACAnet Fukuoka,c=JP"
rootdn *******************
rootpw *********************
directory /usr/local/openldap/var/openldap-ldbm
index objectClass eq
***********************************************************************************************
Posted by tashiro at 18:57 | Comments (1) | TrackBack
クランベクターの実現方法の変更
CACAnetの証明書発行モデルには、「クラン･ベクター」という概念があります。
これは、誰が誰に証明書を発行したのかということを後で追跡可能にするというための仕組みです。具体的には、発行元と主体の証明書の識別子の対の連鎖をCACAnetが管理するということです。
このクランベクターの概念について簡単に説明します。
CACAnetは、カジュアルなPKIと、プライバシー保護を目的にしています。
実際の証明書発行のポリシーは、cpsなどで決定されますが、例えば次のようなことも許容できるようなシステムを想定しています。
●匿名の証明書
●一人に複数枚の証明書を発行する
また、カジュアルなPKIでは、「RAは必ずしも信用できない」ということも想定せざるをえません。少なくとも、次のことが条件になります
●RAによる不正が発生したときに、そのPKIの全体が破綻してはならない
つまり、RAによる不正が行われたことが判明した場合、そのRAが発行した証明書を一括して廃棄できるような仕組みを作ることによって、被害を最小限に食い止めようというはなしです。
このクランベクターの実現のために、CACAnetの証明書にはそれを発行したRAの証明書の識別子が入っています。
この識別子の入れ方が問題になりました。
これまでは、RAの証明書のシリアル番号を入れていました。
しかし、証明書の中にシリアル番号をちゃんと入れるためのフィールドがないため、苦し紛れにDNのOUにいれていました。
でも、それだとRAの証明書の更新が発生すると、その後に同一人物に発行された証明書のDNが変わってしまい、ディレクトリ的には「別人物」になってしまうという問題がありました。
そこで、証明書の中でRAの識別情報を入れる適切な場所を検討した結果、
issuerAltName にRAの電子メールアドレスを入れるという方針にしました。
★注意１
匿名証明書の場合にも電子メールアドレスは必須になってしまいます。
ただし、証明書の取得に使用するメールアドレスは基準を設けませんので、フリーメールなんかを使ってもいいわけなので、そういう意味では匿名性は保証されていると言ってよいかと思います。
★注意２
一人の人間が複数の証明書を取得する場合、メールアドレスが違っていれば問題ありません。
同じメールアドレスの証明書を複数発行してほしい場合ですが、その場合は、CNを変えると違う証明書が作れます。
Posted by yamasaki at 18:34 | Comments (0) | TrackBack
ディレクトリの名前空間の構成の変更案
現在、証明書がどのＲＡから発行されたかを検証できるようにするため（クランベクター）、
証明書のＤＮにＲＡ証明書のシリアル番号を入れるようにしています。
具体的には、２番目のOUに入れてあります。
そして、証明書のＤＮと同じ位置のディレクトリエントリーに、証明書を置いてあります。
しかし、証明書の再発行時にＲＡが変更になるなど、現在のディレクトリ名前空間構成では
いろいろと問題が発生することがわかってきました。
そこで、以下の仕様変更を提案します。
●クランベクターの仕様
●ディレクトリの名前空間構成
●証明書の仕様
●クランベクターの仕様
以前は証明書のシリアル番号によるクランベクターを考えていたが、電子メールアドレスによるクランベクターに変更する。
●ディレクトリの名前空間構成
以下のように変更する。
○RA証明書のシリアル番号のOUをなくす
○OU=person/serverをディレクトリエントリーから外して、属性に変更する。
○emailAddressをCNの階層を逆にし、それぞれの内容は自由にする。（内容の設定は必須）
＜＜例＞＞
証明書のＤＮ
/C=JP/O=CACAnet Fukuoka/O=Members RAA/OU=admin/CN=YAMAMURA Tomohiro/emailAddress=yamamie@cacanet.org
ディレクトリエントリーの場所
/C=JP/O=CACAnet Fukuoka/O=Members RAA/OU=admin/emailAddress=yamamie@cacanet.org/CN=YAMAMURA Tomohiro
●証明書の仕様
RAの電子メールアドレスを、以下の拡張領域に入れる。
○issuerAltNameのrfc822name
＜＜OpenSSLの設定ファイル例＞＞
issuerAltName=email:yamamie@cacanet.org
Posted by admin at 11:31 | Comments (0) | TrackBack
2004年02月25日
電子署名･認証フォーラム2004発表資料
2004年2月24日にJESAP主催の電子署名･認証フォーラムで発表してきました。
「電子自治体における個人情報への権限認証とアクセス制御について」という題です。
電子自治体というのはかなりこじつけで、一般的な個人情報保護方式の提案です。
Posted by yamasaki at 00:43 | Comments (1) | TrackBack
2004年02月22日
エッセイ
1. ゼロからはじめるインターネットセキュリティ講座(著者:宮川祥子氏)[Ascii NetworkPro 2000年5,6,7,8月号]
1. PKI概論
2. 認証局構築実践
3. Apache-SSL & OpenLDAPインストール実習
4. お弁当屋さんサーバの運用
2. これからのソフトウェア開発について(著者:檜山正幸氏,山崎重一郎氏)
1. これからのソフトウェア開発についてのエッセイの連載について 山崎重一郎氏
2. 自己紹介の代わりに 檜山正幸氏
3. まだ「前置き」をしたりして 檜山正幸氏
4. バッドチューニング 山崎重一郎氏
5. ソフトウェアの信頼性 檜山正幸氏
6. 盗め！ 山崎重一郎氏
7. 1000人のユーザー 檜山正幸氏
8. テストの意味論 山崎重一郎
3. PKIで作るP2P型の電子地域通貨(著者:山崎重一郎氏)[Ascii Linux Magazine 2002年8月号]
Posted by yamasaki at 18:38 | Comments (1) | TrackBack
RubyTest::Unitの使い方
以前のRuby Unit 入門のための福岡研究会で使った資料です
パワーポイント
Posted by yamasaki at 15:46 | Comments (0) | TrackBack
CACAnet福岡のCPS
CACAnet福岡のCA用CPSテキストデータです．
Posted by yamasaki at 13:00 | Comments (0) | TrackBack
証明書発行システム仕様書
* 証明書発行システム基本仕様書（PDF形式）2002/07/02
* 証明書発行システム仕様書（Word形式）2002/08/01
証明書発行システム仕様書（PDF形式）2002/08/01
* 証明書発行システム仕様議事録（Text形式）2002/08/01
* 証明書発行システム正常・異常系（Word形式）2002/07/23（暫定版）
証明書発行システム正常・異常系（PDF形式）2002/07/23（暫定版）
* Subject向け導入手引書2002/07/23（暫定版）
* RA向け導入手引書2002/07/23（暫定版）
* ディレクトリ構造2002/07/23（暫定版）
* リポジトリ仕様書（RD形式）2003/02/14（暫定版）
* OpenSSL設定ファイル(旧設定ファイル)
o ca.conf
o person.conf
o server.conf
* ca.cacanet.orgマシンテスト用 OpenSSL設定ファイル 2002/06/11
o ca.conf
o person.conf
o server.conf
* 開発用 OpenSSL設定ファイル 2002/08/20
o ca.conf
o person.conf
o server.conf
* 証明書発行システム ソースコード(RAserver) 2003/04/17
Posted by yamasaki at 12:56 | Comments (0) | TrackBack
CACAnet福岡パブリックコメント
* 「省令案に対する」通産省、郵政省、法務省向け[2000.12.18]
* 「電子署名・認証法に対する」警察庁向け[1999.12.17]
* 「電子署名・認証法に対する」通産省、郵政省、法務省向け[1999.12.17]
Posted by yamasaki at 12:53 | Comments (0) | TrackBack
CACAnet福岡イベント資料
* イムズチャレンジマインドサポートVol.2『e-生活のススメ』2001年5月25,26,27日
o インターネット盗聴デモ
o インターネットセキュリティとNPO
Posted by yamasaki at 12:41 | Comments (0) | TrackBack
2004年02月21日
CACAnet福岡研究会資料
* 電子情報通信学会のSITE研究会でのTravecoup発表 2002年12月13日 (PPT)
* RFC3280を読む会 2002年6月10日〜 日本語訳(宮崎輝樹氏編集
翻訳：宮崎さん，松岡さん，地引さん，中野さん，中前周さん，林ゆういちさん，山崎さん，田坂さん，板倉さん)
PKI用語集
* 愉快な電子認証プロジェクトその１ P2Pネットワークシステムについて 2002年4月1日 (PPT)
* 「電子商取引等に関する準則（案）」へのパブリックコメント 2002年3月18日 (HTML)
* 携帯電話を利用したモバイルPKI 2002年3月4日 (PDF)
* デジタル証明書のパス検証について 2002年2月18日 (PPT)
* OCSPの理論と実践 2002年2月4日 (PPT)
* 電子政府と政府認証基盤(GPKI) 2001年9月7日 (PPT) (PDF)
* 地域通貨とビジネス 2001年8月31日 (HTML)
* CACAnetの証明書廃棄システム説明会 2001年8月27日 (HTML)
* 初めての認証 2001年8月22日 (PPT) (PDF)
* S/MIME入門 2001年7月18日 (HTML)
* CACAnetの証明書リポジトリ説明会 2001年7月6日 (HTML)
* FreeBSDによるファイアーウォール構築術 2001年6月27日 (HTML)
* SSHとCVSを使った共同開発入門 2001年6月18日 (HTML)
* CACAnetの証明書発行システム 2001年6月15日 (HTML)
* Rubyプログラム(第２回) 2001年6月13日 (HTML)
* IPsec入門 2001年6月11日 (HTML)
* 「PKI」第11章 PKIリポジトリと関連技術 2001年6月8日 (HTML)
* Rubyプログラム(第１回) 2001年6月6日 (HTML)
* OpenLDAPの機能について 2001年6月1日 (HTML)
* LDAP入門 2001年5月14日 (HTML)
* 地域通貨と電子通貨 2001年4月27日 (HTML)
* PKIの信頼モデル 2001年4月20日 (HTML)
* 証明書失効 2001年4月6日 (HTML)
* PKI超入門プレゼン資料 (PPT)
Posted by admin at 21:53 | Comments (48)
0 件のコメント:
コメントを投稿