2002年11月17日（日曜日）から21日（木曜日）まで、米国ジョージア州アトランタにおいて IETF ミーティングが開催された。

今回の第 55 回 IETF ミーティングへの参加者は、34カ国から 334 の組織から総勢 1,706人であった。（前回の横浜における第 54 回 IETF の参加者数が 2,064人、前々回のミネアポリスは、1,756人であった。）同時テロ以前のロンドンで行われた第 51 回IETFが 2,457人であったことを考えると、参加者数の減少については、テロの影響と米国における IT バブルの崩壊の影響があると考えられる。

セキュリティエリア各 WG における審議状況を報告する。：

• IPsec Policy WG (ipsp)
• IP Security Protocol WG（ipsec）
• Securely Available Credentials WG (sacred)
• S/MIME Mail Security WG (smime)
• Transport Layer Security WG (tls)
• Public-Key Infrastructure (X.509) WG (pkix)

http://www.ietf.org/html.charters/ipsp-charter.html

Chair(s): Hilarie Orman , Luis Sanchez

「IPsecに、セキュリティポリシーを如何に入れるかについ」て標準化している。 現在、出ている Draft には、4種類あり、各々Area Directorに 2002年 8月27日に送付し、2002年10月25日に IESGよりフィードバックを受けた。 提出中の Draft は、以下の 4文書である。：

• IPsec Configuration Policy Model (draft-ietf-ipsp-config-policy-model-06.txt)
• IP Security Policy Requirements (draft-ietf-ipsp-requirements-02.txt)
• IPsec Policy Information Base (draft-ietf-ipsp-ipsecpib-05.txt)
• IPsec Policy Configuration MIB (draft-ietf-ipsp-ipsec-conf-mib-04.txt)

ESP/AH の counter を従来の 32bitから 64bitへ変更される。これは、32bit の counter の場合、10GB のネットワーク環境では 350秒しか持たないためである。64bit にすることにより 500,000年使えるためである。

プロトコルファミリーとして PF_POLICY を追加しようとしているが、現状においては目立った動きはない。

http://www.ietf.org/html.charters/ipsec-charter.html

Chairs(s): Barbara Fraser , Theodore Ts'o

IPsec プロトコルを標準化している。現在出ている Draft には、以下の 19文書がある。：

• IP Encapsulating Security Payload　(ESP)(draft-ietf-ipsec-esp-v3-03.txt)
• Additional ECC Groutps For IKE　(draft-ietf-ipsec-ike-ecc-groups-04.txt)
• The AES Cipher Algorithms and Their Use With Ipsec (draft-ietf-ipsec-ciph-aes-cbc-04.txt)
• More MODP Diffie-Hellman groups for IKE (draft-ietf-ipsec-ike-modp-groups-04.txt)
• On the Use of SCTP with IPsec　(draft-ietf-ipsec-sctp-04.txt)
• IPsec - NAT Compatibility Requirement　(draft-ietf-ipsec-nat-reqts-02.txt)
• Negotiation of NAT-Traversal in the IKE　(draft-ietf-ipsec-nat-t-ike-04.txt)
• UDP Encapsulation of IPsec Packets　(draft-ietf-ipsec-udp-encaps-04.txt)
• Security Properties of the IPsec Protocol Suite　(draft-ietf-ipsec-properties-02.txt)
• Internet Key Exchange(IKEv2) Protocol　(draft-ietf-ipsec-ikev2-03.txt)
• The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec (draft-ietf-ipsec-ciph-aes-xcbc-mac-02.txt)
• The HMAC-SHA-256-96 Algorithm and Its Use With IPsec (draft-ietf-ipsec-ciph-sha-256-01.txt)
• Just Fast Keying (JFK) (draft-ietf-ipsec-jfk-04.txt)
• IP Authentication Header (draft-ietf-ipsec-rfc2402bis-01.txt)
• Revised Use of Identity in Successors to IKE (draft-ietf-ipsec-revised-identity-00.txt)
• Features of Proposed Successors to IKE (draft-ietf-ipsec-soi-features-01.txt)
• The Internet IP Security PKI Profile of ISAKMP and PKIX (draft-ietf-ipsec-pki-profile-01.txt)
• Extended Sequence Number Addendum to IPsec DOI for ISAKMP (draft-ietf-ipsec-esn-addendum-00.txt)
• Using AES Counter Mode With IPsec ESP (draft-ietf-ipsec-ciph-aes-ctr-01.txt)

1. SIGMA (SIGn-and-MAC)−Hugo Krawczyk

SIGMA の紹介があった。これは、DH 鍵交換手法を使った認証のアプローチであり、IKE の Main Mode と Aggressive Mode の署名において使うことができる。また、現在、提言されている IKEv2 Phase1 の鍵交換の核となるものである。SIGMAの詳細についての文書は、次の URL にある。：

http://www.ee.technion.ac.il/~hugo/sigma.ps (PS ファイル： 25ページ)

2. PKI プロファイルインターネットドラフトの更新−Brian Korver

IPsec で利用する ISAKMP と PKIX のプロファイルのドラフトが紹介された。

• draft-ietf-ipsec-pki-profile-01.txt

2年前にIPsecで利用する証明書プロファイルが提言されており期限切れとなっていたが、議論が再開されている。IPsec プロトコルで 、「いつ証明書や CRL を送信するか」、「空の CERTREQ を受け取った場合、どう処理すべきか」等、PKIに関連する問題点を挙げて検討している。

3. ESP/AH における電子署名認証−Brian Weis

ESP/AH での認証においては、通常、HMAC を使っているが、複数のグループがその鍵を持っていた場合、保証がないことを問題点として指摘している。

• draft-kobayakawa-ipsec-ipv6-pnpipsec-reqts-00.txt

4. IPv6 と IPsec の展開時の問題点−Tomoaki KOBAYAKAWA （NTT コミュニケーション）

IPv6 のマーケットや IPv6 と IPsec を展開する際のシナリオを紹介した。プロトコルやソリューションの提案ではなく、紹介するマーケットがあることからソリューションを必要としていることを説明した。その上でエンドユーザが行う設定は最低限にすること、IPv6 に対応する際に自動化するための Plug-and-play 機能、 および PKI は複雑で難しいことから使用しないソリューションを望んでいること等を説明した。

• draft-kobayakawa-ipsec-ipv6-pnpipsec-reqts-00.txt

5. Son of IKE Status−Charlie Kaufman

現在の IKE v2 のステータスを紹介した。「ユーザID／パスワードやワンタイムパスワード等、レガシーな認証も無視しないで欲しい」という要望があるようである。このことを踏まえた上で、ID ペイロードと CERT ペイロードをマージして FillID とするといった提言がなされた。これに関して白熱した検討がなされていた。

http://www.ietf.org/html.charters/sacred-charter.html

Chair(s): Stephen Farrell , Magnus Nystrom

エンドユーザが自分のクレデンシャル（一般的には鍵ペアや証明書の集まり）をデバイス等に関わらず、セキュアにどこからでも登録取得更新できるフレームワークとプロトコルの標準化を行っている。既に情報提供（Informational）RFC として RFC3157（Securely Available Credentials - Requirements）が出ている。現在提出中のDraftは以下の 2文書である。：

• Securely Available Credentials - Credential Server Framework (draft-ietf-sacred-framework-05.txt)
• Securely Available Credentials Protocol (draft-ietf-sacred-protocol-bss-04.txt)

フレームワークの文書は、IESGに提出済みである。プロトコルで MITM（Man In The Middle）問題が解決していない。この問題解決の提言を含みドラフトをアップデートする予定。

http://www.ietf.org/html.charters/smime-charter.html

Chairs: R. Housley

TLS CBC mode issue/ Eric Rescorla 

S/MIMEの標準化を行っている。既に RFC を 22種類出しており、現在出ている Draft は、10種類ある。

以下の DraftがIESGに提出済みである。：

• Securing X.400 Content with S/MIME　(draft-ietf-smime-x400wrap-05.txt)
• Transporting S/MIME Objects in X.400　(draft-ietf-smime-x400transport-05.txt)
• CMS Symmetric Key Management and Distribution (draft-ietf-smime-symkeydist-07.txt)
• Wrapping an HMAC key with a Triple-DES Key or an AES Key (draft-ietf-smime-hmac-key-wrap-00.txt)
• Use of the RSAES-OAEP Transport Algorithm in CMS (draft-ietf-smime-cms-rsaes-oaep-06.txt)

いくつかのドキュメントを Draft Standard にしたいようだが、RFC3280 の進展しないことがネックになっているようである。

また、他に以下の Draft がある。：

• Examples of S/MIME Messages (draft-ietf-smime-examples-09.txt)
• Implementing Company Classification Policy with the S/MIME Security Label (draft-ietf-smime-seclabel-04.txt)
• S/MIME Version 3.1 Certificate Handling　(draft-ietf-smime-rfc2632bis-02.txt)
• S/MIME Version 3.1 Message Specification　(draft-ietf-smime-rfc2633bis-02.txt)
• Use of the Camellia Encryption Algorithm in CMS　(draft-ietf-smime-camellia-00.txt)

Interoperability Testとして CMS、MSG、CERTとESS に関する情報を作り、IMC の Web サイトに投稿してある。これをもって RFC3369 (Cryptographic Message Syntax(CMS)) をアップデートする必要がある。これに伴い、IMGよりInteroperability Testの整理し、Examples of S/MIME Messages (draft-ietf-smime-examples-09.txt) を整理するよう要請されている。

1. S/MIME CMS-X.400 Drafts: Status & Issues−Chris Bonatti

X.400 の内容を CMS で保護する手段と X.400サーバーへの転送手段（X400Transport）の 2つのドラフトがある。現状のステータスでは、Area Director と IESG からのコメントを議論し、その後 WG メンバーと話すこととになっている。今のところ目立った問題はない。今後 RFC の Standard Track にすると共に ITU-T/ISO にフィードバックする予定である。

2. CMS Interop Matrix−Jim Schaad

CMS については、101 のステートメントにしなければならず（現在62%）、80 の特徴を持ったものにする（現在50%）。また CMS アルゴリズムについては、46 のステートメントにしなければならず（現在93%）、15の特徴を持つ（現在93%）。詳細として、SigndData は 、属性証明書や未実装の構造がある。EnvelopedDataではバージョン番号を 3 にすること、未実装のアルゴリズムや受信者の扱いといったことがある。

3. Camilla Encryption Algorithm−Akihiko Kato

Camilla は、NTT と三菱電機が共同で開発した共有鍵アルゴリズムで、CMS での利用について NTT ソフトの加藤氏が発表した。Camilla は、128ビット暗号で AES と同じブロックサイズ、キーサイズで、Royality-free ライセンスである。小さいハードウェアでも動作する特徴を持つ。詳細については、次を参照のこと。：

http://info.isl.ntt.co.jp/camellia

4. S/MIME CERT and MSG−Blake Ramsdell, Russ Housley

MSGについては CompressedData を定義したことが大きい。smime-type として"compressed-data"を追加し、拡張子を"p7z"としている。CERT に関して E-Mail アドレスの表現をより明確にしたこと、及び keyUsage に nonRepudiation と digitalSignature を明確にしたことがある。残作業として PKCS#1v1.5 や DH の警告等がある。

http://www.ietf.org/html.charters/tls-charter.html

Chair(s): Win Treese

SSL v3.0 から始まり TLS の標準化を行っている。既に TLS1.0 (RFC2246) 等 5つの RFC を出しており、現在以下の 7文書の Draft がある。：

• ECC Cipher Suites For TLS(draft-ietf-tls-ecc-02.txt)
• Addition of Camellia Ciphersuites to Transport Layer Security (TLS) ( draft-ietf-tls-camellia-02.txt)
• Using SRP for TLS Authentication (draft-ietf-tls-srp-03.txt)
• Transport Layer Security (TLS) Extensions (draft-ietf-tls-extensions-05.txt)
• Using OpenPGP keys for TLS authentication (draft-ietf-tls-openpgp-keys-02.txt)
• The TLS Protocol Version 1.1(draft-ietf-tls-rfc2246-bis-02.txt)
• Transport Layer Security Protocol Compression Methods (draft-ietf-tls-compression-03.txt)

「Transport Layer Security (TLS) Extensions」は、Proposed Standard として Last Call となっている。
「The TLS Protocol Version 1.1」は、Proposed Standard にするため検討中である。「Addition of Camellia Ciphersuites to Transport Layer Security(TLS)」は、情報提供（Informational）の RFC として公開するために提出されている。その他の 文書については、まだ検討中である。

また、これら以外に、現状 Standards Track となっている Upgrading to TLS Within HTTP/1.1(RFC2817)を Draft Standard に昇格すべきかということについても考えられているようである。

1. The TLS Protocol Version1.1−Eric Rescorla

TLS 1.1 の目的は以下である。：

• CBC の予測できてしまう IV （Initialization Vector： 初期ベクトル値）問題の解決
• TLS 1.0 における曖昧な部分の明確化
• 必須のアルゴリズムを RSA に変更（TLS1.0 においては、DSA が必須となっている）

今回は CBC の予測できてしまう IV 問題について解決案を説明した。

2. SRP for TLS−Tom Wu

SRP (Secure Remote Password) は、スタンフォード大学で研究開発されているもので、SRP-6 を TLS で使う場合の Draft が提出されている。SRP-6の詳細はhttp://srp.stanford.edu/srp6.ps を参照。SRP-6 は RFC2945 の SRP-3 を改良したものである。

3. Ciphersuite registration−Win Treese

暗号アルゴリズムを登録する際に、Standards Track にするか情報提供（Informational）にするか、違いを明らかにする説明があった。Standards Track にするためには、WG でのコンセンサスがとれていることや理論的に制限のないこと、十分な解説書があること等が 必要である。また、Informational とするには、暗号アルゴリズムに関し道理の通ったドキュメントがあることやセキュリティ上明らかな問題がないこと等がある。

4. ANSI X9.44 and IETF TLS−Russ Housley

ANSI X9.44 においては、RSA アルゴリズムを元にした鍵合意スキームを定義しようとしている（現在Draft）。スキームは実績を反映しガイドするために選ばれる。NISTの鍵管理であるFIPS はX9.44 や他の X9 標準を採用しようとしていた。

TLS WG においては、X9.44 方向性を検討する。その結果 X9 にフィードバックを行い、新しいアルゴリズムのために TLS 暗号スーツを Draft化する予定である（例えば SHA-256の採用ガイダンス等）。

5. Using SigComp in TLS?−Carsten Bormann

SigComp （Signaling compression）を TLS で使用しないかの打診があった。

• draft-ietf-rohc-sigcomp-07.txt
• draft-price-rohc-sigcomp-user-duide-01.txt

http://www.ietf.org/html.charters/pkix-charter.html

Chair(s): Stephen Kent , Tim Polk

新しく「Delegated Path Validation and Delegated Path Discovery Protocol Requirements」が RFC3379 となった。現在 21 の Draft がある。「Roadmap(draft-ietf-pkix-roadmap-09.txt)」は、PKIX WG　のガイドということで RFC にすることを IESG に却下された。 4つの文書が WG から提出され Area Director や IESG の評価を受けている。

IESG 評価中：

• Certificate Policy and Certification Practices Framework　(draft-ietf-pkix-ipki-new-rfc2527-01.txt)

Area Director 評価中：

• Permanent Identifier　(draft-ietf-pkix-pi-05.txt)

Area Directors と共に評価中：

• Wireless LAN Certificate Extensions and Attributes (draft-ietf-pkix-wlan-extns-02.txt)
• Policy Requirements for Time-Stamping Authorities　(draft-ietf-pkix-pr-tsa-02.txt)

以下の 3つの文書が消えた。：

• CMP−相互運用テストレポート待ちで再提出予定。
• CRMF−相互運用テストレポート待ちで再提出予定。
• OCSPv1−テストレポートは終了したが、Draftは消えている。再提出予定。

pkix WG における Last Call 状態の文書は、次のとおり。：

• Logotypes in X.509 certificates (draft-ietf-pkix-logotypes-08.txt)
• Proxy Certificate Profile (draft-ietf-pkix-proxy-03.txt)

以下の 2つの文書は、証明書、CRL及び暗号アルゴリズムの ASN.1 部分を更新した。それぞれ、RFC3279、RFC3280 に組み込んだ。これらの Draft は期限切れとなり消えることとなる。：

• Update for Section 3 in draft-ietf-pkix-ipki-pkalgs-05.txt (draft-ietf-pkix-new-pkalgs-asn1-01.txt)
• Update for Appendix A in draft-ietf-pkix-new-part1-12.txt (draft-ietf-pkix-new-part1-asn1-01.txt)

残り以下の Draft が Active 状態である。：

• Simple Certificate Validation Protocol (SCVP) (draft-ietf-pkix-scvp-10.txt)
• Certificate Validation Protocol (draft-ietf-pkix-cvp-01.txt)
• LDAPv3 DN strings for use with PKIs (draft-ietf-pkix-dnstrings-00.txt)
• LDAP Schema and Syntaxes for PKIs (draft-ietf-pkix-ldap-pki-schema-00.txt)
• LDAP Schema and Syntaxes for PMIs (draft-ietf-pkix-ldap-pmi-schema-00.txt)
• Attribute Certificate Policies Extension (draft-ietf-pkix-acpolicies-extn-01.txt)
• Time-Stamp Protocol (TSP) (draft-ietf-pkix-rfc3161bis-00.txt)
• Online Certificate Status Protocol, version 2 (draft-ietf-pkix-ocspv2-ext-00.txt)
• Warranty Certificate Extension (draft-ietf-pkix-warranty-extn-01.txt)
• The PKIX UserGroupName GeneralName Type (draft-ietf-pkix-usergroup-01.txt)
• Subject Identification Method (SIM) (draft-ietf-pkix-sim-00.txt)
• Repository Locator Service (draft-ietf-pkix-pkixrep-01.txt)

1. Logotype Boundaries−Stefan Santesson

X.509 の拡張領域に Logotype を設ける話があり、現在 image と audio を付けることになっている。これらのデータに image ならサイズ、audio なら時間の制限を設ける提案がなされた。

2. DPD/DPV Protocol−Tim Poke

できるだけ早くDPD/DPVプロトコルを完了しなするために以下のステップで行う。

• 要求事項定義は、既に終わっており RFC3379 となっている
• いくつかあるプロトコルの提案を 1つにしぼる
• 最終リビジョンの作成
• IESG へ提出

プロトコルの選択として、12月 6日までに各著者が要求事項にほぼ従った Draft を作り、12月13日までに ML 上で議論。12月16日-18日に ML上で投票を行う。これにより最終リビジョンを決め、その時点である問題点を満足した Draft を作る。3月の IETFミーティングまでに Area Directors に転送する。
現在候補となっているプロトコルは、以下のとおり。：

• CVP
• SCVP
• OCSPv2
• DVCS

CVP と SCVP について概要と要求事項に対する現状の問題点を指摘していた。この比較では CVP の方が要求事項にマッチしており、SCVP には多くの問題があることを強調していた。

3. SCVP−Russ Housley

既に Draft が 10回更新されている。Denis Pinkas 氏にレビューを受けいくつかの問題を指摘された。また ML 上で議論され指摘された問題点を Draft の 10 に Open Issues として記述されている。これら Open Issues の概要説明があった。Draft-11 においては、Open Issues に取り組み、WG の Last Call の準備とする。

4. OCSP−Mike Myers

プレゼンテーションなし。OCSP に基づき、DPD/DPV の要求事項をサポートするために拡張領域を使う。この拡張領域の説明を記述したドキュメントを再提出予定。

5. Proxy Certificate Profile−Von Welch

代理人に対して証明書を発行する場合の代理人の証明書プロファイルを規定しようとしている。この証明書は、EE が証明書を発行することとなる。この Draft については、Global Grid Forum（http://www.gridforum.org/security/gsi/） において作業をしており、PKIXが議論の場として最も適当であることから Draft となっている。
残りの最も重要な問題は、エンドユーザが CA ではないため、現状のパス検証アルゴリズムでは Proxy Certificate を拒否してしまうことである。参加者のコメントとしては RFC3280 のアルゴリズムを修正せずにサポートすることであった。

6. LDAPv3 Schema for X.509 Certificates−Peter Gietz

証明書や CRL を選択する際に LDAP に不足しているマッチングルール等を定めた提案である。特に同じエントリ上に複数の証明書やCRLがある場合にクライアントの実装が軽くなるよう ObjectClass や Attributeを決めている。LDAP や CIP（Common Indexing Protocol）で証明書リポジトリとして利用できるものにすべきとしている。draft-klasen-ldap-x509certificate-schema-01.txt で公開されており、これはパーソナルドラフトである。Draft-01での主な変更点は、以下のとおり。：

• x509certificate objectclassの定義バグフィックス
• 新しい属性
  x509authorityKeyIdentifier
  x509authorityCertIssuer
  x509authorityCertIssuer
  x509authorityCertSerialNumber
  x509certificateLocation
  x509certificateHolder
• 新しいオブジェクトクラス
  x509certificateHolder

尚、PKIXに登録するかは、ML において議論されることになった。

7. Attribute Certificate Policies Extension−Chris Francis

証明書の certificatePolicies と同様のシンタックスで、属性証明書にも新しい拡張として Attribute Certificate Policies 拡張を追加する提案である。draft-ietf-pkix-acpolicies-extn-01.txt で公開されている。以下の利点がある。：

• AA がそれぞれの AC にポリシーを明示することができる
• ポリシーを指定することで、検証レベルに応じた複数のポリシーの元でACを発行できる
• AA がポリシーを AC に入れることにより、検証するクライアントに重要な情報の伝達手段を提供できることとなる

8. Warranty Certificate Extension−Alice Sturgeon

証明書の中に Warranty（保証情報）を明記する提案である。draft-ietf-pkix-warranty-extn-01.txt として公開されている。
Warranty タイプとして、次のものがある。：

• Aggregated(0)： 最高限度値に到達するまで要求が果たされる。最高限度値以上の要求は果たされない。
• Per-transaction(1)： トランザクション毎に最高限度値を各要求に課す。各トランザクションは独立して考慮される。

保証の証拠があることで、リライングパーティが補償可能か否かを判断できることや、リクスが減少する可能性があること、また自動的なリスク判定ができるようになるといった利点がある。

9. Subject Identification Method(SIM)−Park Jong-Wook

新しい Draft であり、1つのエンティティが異なる Subject で証明書を複数持っている場合に紐付けできるようにする仕組みの提案である。また、バックグランドには、国によっては人や会社の ID が法律でプライベートなデータと関連しているところもあるため秘匿する必要もある。draft-ietf-pkix-sim-00.txt として公開されている。

新しくユニークな暗号化したセキュアな値の VID （Virtual Identifier）を定義しており、RFC3280、PKCS#10、CRMF、PKCS#8、PKCS#11等 の標準に埋め込むことが可能としている。VID は 、パーソナル ID の値と 160ビットの乱数値を 2回ハッシュ計算したもので、先に使った乱数値と VID を暗号化し証明書要求内に入れる。CA は、SubjectAltName に VID 値を入れるといった提案も含まれている。

10. JNSA Challenge PKI 2002 - 稲田 龍

日本の JNSA において行っている「Challenge PKI 2002」について報告した。「Challenge PKI 2002」においては、相互運用テストスイートを開発しており、マルチドメイン PKI における各種テストケースを生成できるツールと環境を提供することを報告した。2003年 4月末にはフリーで公開する予定。

本報告においては、富士ゼロックス株式会社の稲田龍氏とセコムトラストネット株式会社の吉田裕之氏の協力を得た。両名に感謝する。