会議は、1998年8月24日から8月28日の期間、米国シカゴの Sheraton Chicago Hotel & Towers にて開催された。参加者総数は約 2,000 名であり、日本からの参加者は 100名程度である。今回も会議期間中は、1時間〜2時間半のセッションが1日に4〜6 程度というスケジュールであった。 一般動向報告編では、セキュリティエリア全体の動向、およびICAT の活動と最も関 連の深い PKIX の話題について報告する。

    　　　　　　┌−−−−−−−−−−−−−−−−−−−┐
　　　　　　　　│　　　　　　　TRUSTMGT　　　　　　　　│
　　　　    　　├−−−−−−┬−−−−−−−−┬−−−┤
    応用系      │　　　　　　｜OpenPGP 　SMIME ｜SECSH │
　　　  　　　　│　AFT,STP 　｜　　　  ｜　TLS ｜　　　│
　　　　    　　│　　　　　　｜　　 　 ｜IPSEC ｜　　　│
　　　　　　　  ├−−−−−−┼−−−−┼−−−┼−−−┤
    インフラ系　│　 　CAT　  ｜(SPKI)  ｜PKIX  ｜　　　│
　　    　　　　└−−−−−−┴−−−−┴−−−┴−−−┘

今回のセキュリティエリアのセッションでは、IPSEC、TLSをはじめとして、X.509 の 定義に基づいた公開鍵暗号のインフラを軸とした技術は収束しはじめ、一段落しつつ あるという印象を持った。X.509 の定義に基づいた公開鍵暗号のインフラを決める PKIX についても、今まで1つも RFC になっていなかったが、公開鍵証明書フォーマ ットの部分を皮切りにいくつかのプロトコルが近日中に RFC となる見込みである。 また、全体的に、認証方式（Authentication）が落ち着きを見せはじめたのに続いて 、今度はアクセス権の管理方式（Authorization）をキーワードとした議論が出始め 、新たな展開がはじまったと感じた。セキュリティエリアだけではなく、一般エリア （GEN）で AAA（Authentication、Authorization、Accounting） BOF が開催された ことが注目の高さの一端を伺わせる。

暗号アルゴリズムや方式に関わる特許およびライセンス問題については、全て把握し きれないといった問題はあるが、特許やライセンスを保有する企業が、特別な利用目 的に限ってライセンスフリーで使用を許可するケースが増えてきた。これは技術が広 がる意味で望ましい傾向になってきているといえる。特許やライセンスについて保有 企業から見解の出されている件については、IETF の Intellectual Property Rights のページ

• Established Projects:
  1. PKIX Cert and CRL Profile
  2. LDAP v2 Schema and Profile
  3. OCSP
  4. CMP and CRMF
  5. CMMF and CMC
  6. IBM PKIX Software
• New Topics:
  7. Timestamp Protocol
  8. Notary Protocol
  9. Web-based Integrated CA services Protocol、ICAP
  10. Enhanced CRL Distribution Options
  11. PKIX Roadmap
  12. Qualified Certificates

• IESG Last Call
  　
  • 1. の draft-ietf-pkix-ipki-part1-09
• IESG 預り
  　
  • 2. の draft-ietf-pkix-ldapv2-schema-01 　
  • 4. の draft-ietf-pkix-ipki3cmp-08
• WG Last Call 　
  • 3. の draft-ietf-pkix-ocsp-05 　
  • 5. の draft-ietf-pkix-cmmf-02、draft-ietf-pkix-cmc-01 　
  • draft-ietf-pkix-ipki2opp-07

（1）〜（5）までは、変更点を中心とした説明が行われた。 盛り上がった話題は、（2）LDAPv2 の中で CA の証明書を格納する際に、 cACertificate attributes と crossCertificatePair attributes のどちらの属性を 使うのがよいか、という点であった。セッションでは 6つの場合分けをして Interoperability や Path Development について比較した後、以下の2つの場合に絞 りこんだ。IETF後 ML上で投票中である。

1. cACertificate はドメイン内の CA から発行された CA の証明書や自己署名証明 書を格納するのに利用する。crossCertificatePair の forward element にはドメイ ン外の CA から発行された証明書を格納し、reverse element にはドメイン外に対し て発行した証明書を格納するのに利用する。
2. cACertificate はドメイン内の CA から発行された CA の証明書や自己署名証明 書を格納するのに利用する。crossCertificatePair の forward element にはある CA に対して発行された全ての証明書を格納し、reverse element にはある CA が発 行した全ての CA の証明書を格納するのに利用する（つまり、cACertificate は crossCertificatePair の部分集合になる）。

（1） PKIXの実装 今まで、PKIX の Sample Implementation がなく全体が見えにくかったが、ロードマ ップが出てきたり、IBM によるフリーソフトが出たことで、PKIX のメインプロトコ ルの実装が加速するのではないかと思う。しかし、どちらかというと CA運用会社が 中心となっている PKIX に関して、なぜ IBM 社が出てきたのかという背景はわから ない（他の人に伺ってみたところ、IBM 社の（TV の CM でもやっている） e-businessの方針と関連があるのでは、という答えが返ってきてなんとなくわかった 気がしているところである）。

（2） PKIXの発音 PKI は「ぴーけいあい」だがPKIX は「ぴーきぃくす」（「ぴー」にアクセント）と 発音していた。前回 IETF に参加したときには気づかなかった。

（3） IPSEC、TLS、他のプロトコルの使い分け IPSEC、TLS、SOCKS、SECSH などのセキュリティ関連プロトコルの使い分けや線引き についてはよく聞かれることである。IETF の各セッションでも少しはこの話題が出 るが、あまり深い議論になることはなく、ひとまずそれぞれ独立に RFC にしてまと めていきましょう、となる。やはり、サービスを提供する側がある程度考えていく他 なさそうである。

ＩI．ICAT 関連活動

I-D には、WG ドラフト （draft-ietf-WG名 ではじまる I-D） とパーソナルドラフ ト（draft-個人名 ではじまる I-D） との2種類があるが、ドラフトを RFC とする近 道は、まず WG ドラフトとしてから WG内で議論しまとめていくことである。しかし 、あるドラフトがどのようなプロセスを経て WG ドラフトとして認められるのかは不 明であったため、PKIX WG チェアに問い合わせたが、結局回答を得られないまま、パ ーソナルドラフトとして7月末に提出した。

Reddy氏も IETF に参加していたため、会場で1時間程度のローカルミーティングを行 った。ミーティングでは、主に両I-D の違いを確認した。大きな違いは、データフォ ーマット（ICAP は text/plain、WebCAP は XML）だけであるが、両者ともに譲れな い点であることもわかった。CA 間連携の方式は、若干の違いがあるものの、基本的 には ICAP が提案している referral モデルに賛成とのことであった。 両I-D をマージするかどうかについては結論が出なかったが、今後も電子メールで意 見交換を続けることになった。

ICAP の場合、活動母体である ICAT の活動の終了により、標準化活動としてICAT か ら内容を提案しつづけることは難しい状況になるが、逆に ICAT に閉じることなく、 よりオープンに議論できる状況になるともいえる。名前も内容も非常に似た WebCAP については、I-D を出すまでは対抗案として意識していたが、PKIX 全体の中では、 ICAP 支持案と捉えて一緒にまとめていく方が有利かもしれない（英語で議論するこ とに関しても）。ただし、WebCAP とマージする場合には、現在の ICAP の実装とは 切り離して考えることになるだろう。

今後どうするにしろ、今回の I-D は、ICAT に集まった技術者間の交流がなければま とまらなかった。この場をお借りして、ICAT 関係者各位に改めて感謝の意を表した い。

[Homepageへ戻る]	webmaster@icat.or.jp
	Last modified : Sat Mar 6 20:25 JST 199