認証技術の国際動向 - 第42回 ietf 活動報告-

98/11/19 ICAT活動成果発表会

認証技術の国際動向- 第 42 回 IETF 活動報告 -

櫻井三子 (NEC)[email protected]


一般動向編

セキュリティエリアの PKIX WGを中心に


IETF とは Internet Engineering Task Forceよりよいインタネットアーキテクチャ、スム

ーズなオペレーションを目指すコミュニティボランティアベースの活動インタネット標準 (RFC) 化活動が中心

技術分野ごとのエリア、エリア内のワーキンググループ単位で活動普段の活動の場は ML 年３回オフラインミーティングを開催


IETF における標準化活動の典型的なステップ

individual Internet-Draft (draft- 個人名 -..)

↓WG Internet-Draft

(draft-ietf-WG 名 )↓

WG Last Call ↓

IESG Last Call↓

Proposed Standard RFC

↓Draft Standard RFC

↓Standard RFC


IETF 内のエリア

Application AreaGeneral AreaInternet AreaOperations and Management AreaRouting AreaSecurity AreaTransport AreaUser Service Area


42nd IETF ミーティング

米国シカゴにて開催期間： 8/24( 月 ) ~ 8/28( 金 )

参加者は２，０００人程度日本からは１００人程度 ?

ワーキンググループ毎のセッション１時間～２時間半 / セッション Internet-Drafts を叩き台にした議論が中心セキュリティエリアは、 8WG+2BOF

42nd IETF におけるセキュリティエリアのセッション

cat (Common Authentication Technology) aft (Authenticated Firewall Traversal) stp (Secure Transport Proxy) BOF pkix (Public-Key Infrastructure (X.509)) ipsec (IP Security Protocol ) tls (Transport Layer Security) openpgp (An Open Specification for Pretty Good

Privacy) smime (S/MIME Mail Security) secsh (Secure Shell) trustmgt (Trust Management) BOF


42nd IETF におけるセキュリティエリアのセッション

ipsec

(spki) pkix

secsh

cat

tls

smime

セキュリティインフラ系

セキュリティ応用系openpgp

trustmgt

aft, stp


セキュリティエリア全体の動向

CA 前提の PKI とその応用は収束段階へ PKIX はやっと RFC 目前に IPsec は RFC としてまとまり、 IPsecond へ

特許、ライセンス問題は少し前進保有企業が特別な利用目的に限りフリーで使用

許可する傾向が出てきたAuthentication から Authorization へ

GEN エリアで AAA(Authentication, Authorization, Accounting) BOF が開催された


PKIX WG

Public Key Infrastructure (X.509) WGX.509 の定義に基づいた公開鍵暗号のイ

ンフラをインタネットで利用していくための規格化を行う WG

最低限必要なプロトコルを早く標準化するべく活動が活発化

今回は 2 時間のセッションが 2 回あった


PKIX WG Agenda

既存トピック PKIX Cert and CRL Profile LDAP v2 Schema and Profile OCSP (Online Certificate Status

Protocol) CMP and CRMF CMMF and CMC IBM PKIX Software


PKIX WG Agenda(2)

新しいトピック Time Stamp Protocol, Notary Protocol

Web ベースの統合的 CA サービスプロトコル提案 ( 櫻井 ) CRL のサイズを抑えるための拡張フィールドの追加

提案 PKIX 全体の概観と実装のアドバイスを含めたロー

ドマップドキュメントの提案国際間でも合法的にディジタル署名を扱えるような

枠組みの提案 (Qualified Certificates)


おもな話題

主要な I-Ds の状況確認証明書と CRL のプロファイルが漸く RFC 目

前になった　→ Proposed Standard RFC へ LDAPv2 スキーマ、 CMP は IESG 預かり OCSP, CMMF, CMC, OPP(LDAPv2) は WG

Last Call


おもな話題 (2)

LDAP V2 の中で CA の証明書を格納するときの属性の使い方について議論cACertificate と crossCertificatePair

IBM が PKIX のフリーウェアを出すとのアナウンスがあったhttp://www.imc.org/imc-pfl

自己署名証明書他の CA に発行されたCA 証明書 (自己署名を除く )

他の CA に発行した証明書

forward reverse


RA

CA

CA

証明書 / CRL リポジトリ

エンドエンティティ

証明書登録

証明書 , CRL登録

鍵作成、証明書発行、更新、廃棄のためのやりとり相互認証の

ためのやりとり証明書、 CRL入手のためのやりとり/管理情報のやりとり

(a)

(b) (b)(c)

PKIX の現状

CMP

OPP(LDAPv2) OPP

(LDAPv2)

証明書はX.509v3CRL はX.509v2


CMP (Certificate Management Protocol)

PKI ヘッダ

PKI ボディ

証明書の発行、廃棄、鍵作成、鍵回復などを行うためのプロトコル

PK

I

メッセー

ジ要求や応答の種類を指定する

要求や応答に応じたフォーマットを利用する

CRMF

CMMFS/MIME との擦りあわせ案

CMC


Internet-Draft 発表報告編

Web-based Integrated CA services Protocol, ICAP(draft-sakurai-pkix-icap-00.txt)


I-D作成の背景

ICAT 広域認証技術タスクフォースの活動成果をまとめるCA パッケージ ICAP と暗号メールパッケージ

PEPOP との連携プロトコルを I-D にまとめる IETF PKIX WG の活動内容との関連性

が大きい PKIX WG に向けて情報発信実は提案は 2 度目、今回は改良


ICAP とは

典型的な CA関連サービスを、 Web ベースで統合的に提供するプロトコル証明書発行証明書入手、 CA 証明書入手、 CRL入手証明書の有効性確認etc.

独自の CAモデルに基づいて定義CA 間連携プロトコルを含めて定義


ICAP におけるCA の構成要素

CA を 4 つの機能からなると定義Registration Authority (RA)

証明書を発行してよいかどうか判断する機能パスワード認証のためのデータベースを管理

Issuing Authority (IA) 証明書や CRL に署名を行う機能 CA の鍵を管理アプリケーション別証明書プロファイルを管理


ICAP におけるCA の構成要素 (続き )

Publishing Authority (PA) 証明書や CRL を配布する機能証明書や CRL を管理他の PA と連携

Validation Authority (VA）個々の証明書の有効性を判定する機能応答時に署名するための鍵を管理他の VA と連携


ICAP における CAモデル

End Entity outside of firewall

End

Entity

RA IA

VA PA

RA IA

PA VA

firewall firewall

CA 他組織の CA

内外


ICAP が提供する CA関連サービス

RA IA

VA PA

certreqrevokerequpdatereq

verifyreq

lookupreqcalookupreqcrlreq

PAVA


ICAP 要求 / 応答フォーマット

シンプルかつアプリケーションフレンドリ要求

HTTP の POST メソッドを利用 CGI を想定し、パラメータを CGI変数として渡す

応答 text/plain フォーマットを利用 3桁の数字を使ったステータス情報を返すステータス情報の後に応答データが続く


Example

% telnet cahost1 80Trying 123.16.5.41 …Connected to cahost1.Escape character is ‘^]’.POST /cgi-bin/lookupreq HTTP/1.0Content-length: 41

[email protected]&Latest=1HTTP/1.1 200 OKDate: Sat, 25 Oct 1997 09:34:17 GMTContent-Type: text/plain

lookupreq200 accept your request MIIDmTCCA…..

要求

応答


“lookupreq” におけるPA-PA プロトコル

仮想的な階層を利用各管理ドメインを定

義Referral model

RootPA が URL を返す

Chaining modelRootPA が応答を返す

RootPA

PA1 PA2

RootPA

PA1 PA2

12

3

4

1 2

34ターゲットターゲット


要求メッセージに含まれる証明書からターゲット PA の URL を取り出しアクセスする

cRLDistributionPoints という証明書拡張フィールドを利用

“calookupreq” における PA-PA プロトコル , “verifyreq” における VA-VA プロトコルも同様

“crlreq” におけるPA-PA プロトコル

PA1 PA21

2

ターゲット


PKIX WG で検討中の関連プロトコル

certreqlookupreq

calookupreqcrlreq

verifyreqrevokerequpdatereq

ICAP

CMP

OPP(HTTP)

OPP(LDAP)

OCSP

CertificateManagementProtocol

OperationalProtocols

WEB basedCA Access Protocol

OnlineCertificateStatusProtocol

WebCAP


ICAP vs WebCAP

ICAP WebCAP要求時の HTTP メソッド

POST 独自メソッドを含む複数から選択

要求/応答フォーマット

text/plain1 回の送信に要求は 1つ

text/xml1 回の送信に要求は複数可

PA のホスト名とPA が扱う証明書の名前空間との関係

独立PA の管理範囲を複数のドメインで構成可能

制限ありus.oracle.comなら C=US,O=ORACLE のみ


標準化に向けての目標は？

現在の PKIX WG 関連ドラフトは既に 18 とかなり細分化が進んでいる

本ドラフトは、 PKIX WG の複数のドラフトに関連しているため、このまま標準化へ持っていくのは難しそう

→ まずは、 PKIX WG ドラフトとしてみとめられることを目標に発表！

→ しかし、今のところ反応は少ない


今までに寄せられた反応

テキストフォーマットの利用に関するコメントなぜ全てを　 ASN.1 で定義しないのか？→ PKIX WG は ASN.1 賛成派 !? cf. アンチ X.509 の SPKI WG = アンチ ASN.1 text/plain ではなく、新しい MIME タイプの定義

をしてはどうか ?実装に関するコメント

入手できるかどうか？


まとめ

IETF への提案は、戦略とタイミングが重要PKIX の基本プロトコルが固まりつつある状況下

での ICAP の提案は ...ICAT からの I-D 発信によって、成果を次に

つなげる可能性は広がった今後改良点を反映させて改訂する予定仕様の大部分を実装したパッケージをソースコ

ードを含めて国内に配布

認証技術の国際動向 - 第42回 ietf 活動報告-

Documents