38th IETF Report

ICAT NewsLetter Vol.3 part I

1997.12.1

第38回 IETF会議報告

　IETF（Internet Engineering Task Force）とはInternet上のプロトコルをどのようにするか、議論をするTFであり、各カテゴリー毎にWGを作りI-D（Internet-draft）という規格のドラフトを作成する。これが諮問機関のIESG（Internet Engineering Steering Group）でRFC（Request for Comments）として認められると実質上の標準となる。

TABLE OF CONTENTS 1. PKIX
1.1 Part 1. Profile
1.2 PKIX Part 2. Operational
1.3 PKIX Part3. Management
1.4 PKIX Part4. Policy
1.5 Web based Certificate Repository
1.6 秘密鍵の格納に関して
1.7 その他

報告者：菊池浩明（東海大）

　期　間：1997年4月7日（月）～4月11日（金）
　会　場：アメリカ〔メンフィス〕 Peabody Hotel

　第38回IETFは2000人を超える参加者であった。ホストはFedexで宅配便の封筒を資料入れに配っていた（これをタダで送れるといいのだけども）。会場のPeabody Hotelは歴史を感じさせる重みのあるホテルである。
　なぜか毎日午前11時にファンファーレと共にカモがエレベータから赤いカーペットを渡ってロビーの噴水にやってくる。夜ちゃんと帰って行くようである。

1. PKIX

　PKIXは4月7日、8日の2つのスロットで行われた。座長の一人の Steve Kent 氏はお休みで、VeriSignの Warwic Ford 氏が仕切った。アジェンダは主に次のようなものであった。

PKIX Part1. Profile
PKIX Part2. Operational Protocol --【New】
PKIX Part3. Management
PKIX Part4. Policy
Web based Certificate and CRL Repository 　
New extension: Key Purpose 　
Access Description
Key Storage 　
Time Stamping, Notary

図１　Internet PKI Entitis
（draft-ietf-ipki-part1-05.txtより）

1.1　Part 1. Profile

T.Pork（NIST）

　4番目のドラフトであり、ほとんど安定してきた。大きな議論もなく、コメントを2週間待った後、Proposed Standard として提出する予定であるとのこと。いわゆる“lastcall”である。ただし、今回の会議へのI-Dは間に合わなかったので、Webで公開するとのこと。前にアナウンスしたURLからは入手できなかった）。

　SanJoseでの議論から主な変更点は次のようなものである。

only 2 private extension（caInfoAccessがなくなった？）　　
不評の sliding window for time encoding （20aa年～20bb年の間、二つの符号化が混在する）は廃止された。　　
alt name への URI が導入された（証明書を指す）。　　
CRLdist.point へも URI が導入された。　　
Online validation serviceのための URI が導入された。　　
Cylink社の特許が記載された（RSAはまだ触れていない）。　　
ASN.1の EXPLICIT/IMPLICIT の問題が正された。　　
KEA の定義が明確にされた。

　未解決の問題は次の通り。

ANS.1 '88版と '93版があり、どちらを使うべきか？（これは翌日T.Pork自身は互換性のため'88版を使うべきだという補足があった）
EAアルゴリズムそのものについての参考文献Warwickによると、Part1はまず、問題無くRFCとなるだろうとのこと。ただし他のシリーズは、まだ議論が必要である。

1.2 PKIX Part 2. Operational

Boeyen（Notel）

　特徴は次の通り

LDAP Profile
FTP Profile
Online Certificate Status Checking （OCSC）
LDAPによる Name、Cert、CRLの読み込みと、emailaddressなどの検索。

　FTPは匿名FTPによる配布。".cer"、 ".crl" という拡張子のファイルに証明書のBERのバイナリを格納したファイルが直接入る。HTTPについての標準化案も含まれているが、この後でリリースされた“Web based Certificate Repository”との調整が必要である。
　私からの、アドレスによる検索はプライバシ侵害を引き起こす可能性があるのでは？、という指摘に対して、リクエストをLADPに転送するだけでLDAPが責任を取る問題であるというスタンスを表明した。

1.3 PKIX Part3. Management

C. Adams（Nortel）

　Stephan Frawelは欠席（ICETELが忙しいのか？）　これも30分の遅れでI-Dのcut off dateに間に合わず。主な変更点は

PKCS#10（certificationRequest）が新設された。
bootstrapping時におけるPKCS message が用意される。

ことである。

1.4 PKIX Part4. Policy

S. Chokhani（CygnaCom Solutions）

　前回の議論を元に、ドラフトの書き換えを図っている。
　Certificate policy（ポリシーを定めるための枠組み）とCertification Practice statement（ポリシーの実例）の違いを強調していた。　主な質問　・Pinkersより、既存のドラフトとの関連を明確にすることが要求された。例えば、Part 3で述べられているPublishing Authorityの概念がPart 4には全くないようである。

1.5 Web based Certificate Repository

H. Kikuchi（Tokai Univ）

　Firewallを想定し、HTML言語を利用したRepository案。

例としては以下の通りである。


（draft-kikuchi-web-cert-repository-00.txtより）
　　　POST IAP/queryType HTTP/1.0
　　　name1=value1&name2=value2&...&namen=valuen　　

　　　HTTP/1.0 200 OK
　　　Date: Wednesday
　　　MIME-version: 1.0
　　　Content-type: text/html

　　　<HEAD><TITLE>queryType</TITLE></HEAD>
　　　<BODY>
　　　<H3>statusCode</H3>
　　　<H1>statusMessage</H1>
　　　information
　　　</BODY>


図２　Example of PAs hierarchy	図３　Relationship between PA and CA

詳細は

draft-kikuchi-web-cert-repository-00.txt を参照のこと。使用した発表資料も http://www.icat.or.jp/presentation/PKIX97Apr/ に置いてあるので参照のこと。

　これに対して次の質問とコメントがあった。

subject info access が不要ということだが、証明書が破棄された時はどうするか？（Russ, Housllyから）
　　－Authorityが代わりに配るのでよい。それがPart 1でこの拡張子を導入した理由らしい。
PKIX Part2とは独立に用意されたので、多少冗長なところがある。（T. Porkから）
　　－いずれ調整したい。
HTMLがhuman readableという提案だが、それは同意しかねる（T. Porkから）。
HTML encodingはBERに比べてどのくらいサイズが大きくなるのか？
　　－まだ計っていない。

1.6 秘密鍵の格納に関して

C. Allen（Consensus Development）

　あるアプリに使った秘密鍵を別のアプリで利用するにはどうしたらよいか。この問題に対する標準には次の二つが知られている。

Micorsoft PFX. PKCS#12に基づくバイナリ
ASCII Armor. PKCS#5,7,8 + Base64 で表現

　この標準化についての議論を次で行う。

        <certstorage-wg@consensus.com>
        subject=subscribe

1.7 その他

Time stamping/notaries の活動を、このWGでやるかどうかわからないが、プロトコルを決めたいので希望者はAdamsに知らせてくれとのこと。
93ANS.1は、互換性を重視するために捨てたい（T. Pork個人的に）。
CRLの圧縮に関する Part 5のドラフトを考えている。
それはスマートカードに格納するのにいいのでMLで議論したいとのこと。
Key Usgae は8ビットしかないので様々な利用、例えば、PGP用やPEM用に利用するために次の提案をしたいとのこと。

      Key Purpose ::= SEQUENCE OF OID;

　Key Usageには輸出規制をかけるためにもなくては困るので

　　  Key Usage ::= SEQUENCE {
　                  KeyUsage        BitString,
　                  SEQUENCE OF OID Optional
　                  }

　多くの同意が得られた。ISOへの提案も同時に行うことにする。

Acces Decriptionに圧縮などのアルゴリズムを入れたいので format という属性を加える提案。デフォルトはPKIX2とすればよい。

[Homepageへ戻る]	webmaster@icat.or.jp
	Last modified : Fri Oct 2 1:48 JST 1998

報告者：菊池 浩明（東海大）