49th IETF ミーティング(サンディエゴ)

インターネット・セキュリティ関連情報収集の報告

IPA セキュリティセンター

最終更新日 2001. 2.19

竹谷清康
isec-info@ipa.go.jp

出張期間: 2000年12月10日 - 12月17日 (8日間)
開催場所: アメリカ サンディアゴ

概要

PKI および暗号実装技術の動向調査を目的に IETF の Security Area の WG を中心に参加した。今回のミーティングはアメリカのサンディエゴで開催され、アメリカ、日本をはじめ世界 35ヶ国 388 の企業・組織より約 2,800名の参加があった。

セキュリティエリアの WG では、暗号実装に関する議論が多く行われた。特にsaag (Open Security Area Directorate Meeting)においては、Mandatory Encryption と AES が議題としてあがった。1997年から現時点での IETF 公開鍵暗号の Mandatory Encryption はフリーに利用できる DSA と DH であるが、必ずしも全てのベンダーが実装していないし、RSAの特許が今年の 9月に切れたこともあり、RSA も必須暗号としてはどうかという Jeffrey Schiller (Area Director/MIT)の意見にほぼ会場全体が賛成であった。(Tim Polk(NIST)は米国政府の立場上DSAの擁護発言をしていた。)また、3DES の後継である AES について Marcus Leech (Area Director/nortel)が会場の意見を聞いたところ、DRAFT では must もしくは should は使うべきに賛成の手が多く挙がった。

その他の Public-Key Infrastructure (X.509)、IP Security Protocol (ipsec)、S/MIME Mail Security、Transport Layer Securityの各WGでも暗号実装のドラフトが多く出されている。

日本や韓国の暗号技術がTransport Layer Security WGで提案されているが、AESと Kerberos 以外の DRAFT は少し時間がかかると思われる。今回のIETFには、33ヶ国2158名(前回は33ヶ国1443名)の参加があり、日本からの参加は全体の6%で米国の58%に次いで多かった。

以上

plenary(12月13日夜時点)での今回の参加状況は次の通り。
全体参加人数:2768名
参加国:35ヶ国(米国67%日本6%カナダ3%英国3%フランス3%スペイン3%)
参加企業・組織: 388企業
IPA からの参加は 1名、韓国の KISA からは 2名の参加があった。

セキュリティエリア

Open Security Area Directorate Meeting(saag)/Jeffrey I. Schiller(MIT)

今回開催のWG/BOFは次の通り。

KRB-WG - Kerberos WG
KINK - Kerberized Internet Negotiation of Keys WG
IPSEC - IP Security Protocol WG
IPSRA - IP Security Remote Access WG
IPSP - IP Security Policy WG
TLS - Transport Layer Security WG
PKIX - Public-Key Infrastructure (X.509) WG
SYSLOG - Security Issues in Network Event Logging WG
SMIME - S/MIME Mail Security WG
IDWG - Intrusion Detection Exchange Format WG
SACRED - Securely Available Credentials WG
TELSEC - Telnet Security BOF
MSEC - Multicast Security BOF

XML Digital Signatures (xmldsig)は、当初開催予定であったが開催されなかった。

セキュリティエリアのトピックスとして

  1. Mandatory Encyption/Jeffrey Schiller(Area Director/MIT)

  2. AES vs 3DES/Marcus Leech (Area Director/nortel)

が取り上げられた。

1. 公開鍵暗号のMandatory Encyption/Jeffrey Schiller(Area Director/MIT)の概要

従来、必須暗号とする暗号の条件のラフなコンセンサスは、その暗号が自由に利用可能であることであり、1997年、DH   とElgamal と DSA がその条件を満たし、今年の 9月には RSA のパテント期間が終わった。Security Area の各種プロトコルでは、DH とDSAを必須としているものが多いが現在必須暗号の位置付けになっていたが、ほとんどの実装ベンダーは各プロトコルの必須暗号を実装していないのが現状である。このような状況を踏まえて、パテントが切れた RSA 暗号を必須とするかどうか?現行の必須暗号を引き続き必須暗号とするかどうか?について、straw poll を含めて議論がなされ、RSA 暗号が必須にする意見が会場の意見であった。

2. AES vs 3DES/Marcus Leech (Area Director/nortel)の概要

3DESとその後継であるAESについて会場の意見を聞いたところ、3DES は当面必須暗号であることと AES が 各 DRAFT において must もしくは should の暗号として使うべきに賛成の手が多く挙がった。


PKIX: Public-Key Infrastructure (X.509) WG / Steve Kent (WG co-chairs)

Qualified Certificates Profile/S. Santesson(AddTrust)

このドラフト(draft-ietf-pkix-qc-06.txt)はStandards RFCとして、11月13日にRFC Editor's Queueに載った。これは、EUの標準文書(TS101862)連動しているものである。今回ブランド名に関する拡張の提案がされたが、コンセンサスはまだ得られなかった。拡張するブランドとしては、発行者ブランド・本人の組織のブランド・CAブランドでコンテンツとしては、ブランド名・ブランドロゴのハッシュ値・ロゴのURLが提案される。

Time Stamping Protocol/D. Pinkas(Bull)

draft-ietf-pkix-time-stamp-09.txt
このドラフトはすでに8月末にLast callとなり現在レビュー中である。

Permanent Identifier - D. Pinkas (Bull)

draft-ietf-pkix-pi-01.txt
このドラフトのTarget categoryは 現在Standard Trackとなっているが、chairが、standardsか informationalか experimentalのいずれRFCにするか会場の意見を聞いたところstandards の意見が多かった。また、このドラフトの問題点として、署名者の名前が結婚などにより変わった場合に、新しい署名鍵で署名することが挙げられる。

Technical Non-Repudiation - Tom Gindin (IBM)

draft-ietf-pkix-technr-03.txt  Category: Informational
当日は、Gindinが欠席のため、Polkが前回のドラフトからの変更点を説明。Receipt要件の記述、OCSP/SCVPのサポートなどを追加。

Denis Pinkas (Bull)がこのドキュメントの問題点として、time stampに含むべき情報がはっきりしていない(countersignatureかcopy of the"signature block"かentire document) や検証を署名時のみタイミングしか考えていないなどを指摘していた。またCEN/ISSSがElectronic Signature Verificationとして法的な観点を含めたドキュメントを作成中だとコメントしていた。

DPV(Delegated Path Validation)& DPD(Delegated Path Discovery)- Steve Kent (BBN)

現在SCVP (Simple Certificate Validation Protocol) とOCSPv2に関してメーリングリストで議論されている要件をまとめた説明をKent が行った。

DPDはクライアントが証明書を認識できることを前提にしているのでASN.1以外の形式は必要がない?DPVはクライアントに証明書認証のような機能は要求していないため、XML形式の選択があってもいい。ただし、考慮しなければいけないこととして、オープンな環境のサーバーか企業内などのクローズなサーバーかにより、証明書の有効性方法などを決定しておく必要がある。

CMP Interoperability testing/B. Moskowitz(ICSA)

この活動はPKIフォーラムで行われており、CMP(Certificate Management Protocol)の相互接続性をはかるもので、RFC2510RFC5211ドラフト2510bis CMPtransportがベースとなっている。EE to CAのテストは実施したが、CA to CA,EE to RA to CAはまだとのこと。暗号アルゴリズムはDSAとRSAを使用。

CMP・CRMF/C. Adams(Entrust)

draft-ietf-pkix-rfc2510bis-02.txt
draft-ietf-pkix-rfc2511bis-00.txt.
相互接続テストの結果を反映した修正を行った後、WG Last Callの予定とのこと。

Son of 2459 /Russ Housley (SPYRUS)

従来のRFC2459を証明書・失効情報のプロファイルと公開鍵・署名のアルゴリズムに分離した。

draft-ietf-pkix-new-part1-03.txt
証明書・失効情報のプロファイルの主な変更点はQualified Certificates,X.509-2000との整合やInhibit Any-Policy、Subject Directory Attributes Subject Information Access部分の変更である。X.509 の検討グループと PKIX グループの name constraints に関する相違は、permitted_subtrees の構成でX.509で合わせてくれるのがPKIXにとって好都合なので2月14日を期限に設定して回答を待っているとのこと。

draft-ietf-pkix-ipki-pkalgs-01.txt
公開鍵・署名のアルゴリズムの部分では、必須暗号を DSA にするか RSA するか議論があり、継続テーマとなった感じである。

OCSP v2 /M. Myers(VeriSign)

draft-ietf-pkix-ocspv2-01.txt
従来 OCSP Extensionとしていたが、今回 certificate ID の変更し、Myers がpath validationとpath discoveryを含めてOCSP version2 としてレゼンが行った。

Denis Pinkas (Bull) や Ambarish Malpani (ValiCert)をはじめ、多くの問題提起がなされ、今後継続的に議論されそうである。(会場はどちらかといえば、本ドラフトに反対が多数である。)

PKIX and XML - Phil Hallem-Baker (VeriSign)

XML PKI の理想的な連携モデル(XML protocol,encryption,signatures,SOAP,PKI etc)の必要性を Baker がプレゼンした。またPKI の課題として、クライアントの開発など挙げて説明。詳しくは http://www.verisign.com/developer/xml/xkms.html を参照。

SMIME

議事録の日本語訳をもって報告いたします。

Introductions - Russ Housley

Russ氏は、下記のアジェンダについてレビュウを行い、特にだれもコメントはしなかった。

    Introductions (Russ Housley)
    Working Group Status (Russ Housley)
    Interoperability Matrix Jim Schaad
    CMS and ESS Examples Paul Hoffman
    Security Policies and Labels Weston Nicolls
    Symmetric Key Distribution Sean Turner
    Domain Security (DOMSEC) Bill Ottaway
    X.400 and CMS Chris Bonatti
    Reuse of Content Encryption Keys Steve Farrell
    Advanced Encryption Standard Jim Schaad
    RSA-OAEP and RSA-PSS John Linn
    RSA as a MUST implement Blake Ramsdell
    E-Signature Formats using CMS John Ross
    E-Signature Formats using XML Denis Pinkas
    S/MIME Freeware Library John Pawling
    Wrap up Russ Housley


S/MIME Working Group Status - Russ Housley

Russ氏は、下記のRFCをインターネット・プロポーズド・スタンダードからド ラフト・スタンダードに昇格させるための戦略について概略説明した。

RFC 2630 Cryptographic Message Syntax (CMS), R. Housley, June 1999
RFC 2631 Diffie-Hellman Key Agreement Method, E. Rescorla, June 1999
RFC 2632 S/MIME Version 3 Certificate Handling, B. Ramsdell, June 1999
RFC 2633 S/MIME Version 3 Message Specification, B. Ramsdell, June 1999
RFC 2634 Enhanced Security Services for S/MIME, P. Hoffman, June 1999
RFC 2785 Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME, R. Zuccherato, March 2000. [Informational]
RFC 2876 Use of the KEA and SKIPJACK Algorithms in CMS, J. Pawling, July 2000. [Informational]
RFC 2984 Use of the CAST-128 Encryption Algorithm in CMS, C. Adams, October 2000

上記の文書はドラフトスタンダードに昇格するためには次の条件を満たさなくてはな らない:

1) RFC2026に記述された条件を満たすこと
2) 安定しており、成熟しており、役に立つ仕様であること
3) 少なくとも2つ以上の独立して実装と異なるコードベースの相互接続可能な実装があること
4) ドラフト・スタンダードはプロポーズド・スタンダードのRFC、イクスぺリメンタルRFC、を参照することはできない。

したがって、PKIX証明書およびCRLプ ロファイル「son-of-RFC2459」インターネットドラフト (I-D)(draft-ietf-pkix-new-part1-03.txt) がドラフト・スタンダードになるまで、道が閉ざされている。Russ氏は、Jim Schaad氏がRFC2630〜2634までの相互接続マトリックスを作成 したと述べた。相互接続マトリックスは、http://www.imc.org/ietf-smime/interop-matrix.html に投稿された。マトリックスには、どの仕様がテストの結果、成功したかどうか について示されている。したがって、Jim Schaad氏 とGetronics Government Solutions社は、 相互接続マトリックスへの書き込みを提供している。Jim氏はMicrosoft S/MIME v3の実装 の能力について入力した。Getronics社は、Microsoftと行った相互接続テストを含めて S/MIME Freeware Library (SFL)の能力に関して入力を行った。

Russ氏は、Paul Hoffman (IMC)氏が "Examples of S/MIME Messages" イン ターネットドラフトの改良のため相互接続テストの調整を申し出ていると述べた。彼は、 他の組織が S/MIME V3能力を実装したときには、ぜひ参加するよう要請した。Russ氏は、S/MIME WG メーリング・リストに提案すると述べた。


Interoperability Matrix - Jim Schaad

Jim氏は、RFC2630からRFC2634までに関する相互接続マトリックスについて議 論した。彼は、各RFCの節数を用いて双方向の相互接続テストの成功裡に終了したと記録 した。彼は、行われたすべての相互接続テストに基いた結果を完全に更新できていない:

         RFC Clauses Tested
        =========================
         2630 49 of 96
         2631 0 of 13
         2632 16 of 21
         2633 17 of 61
         2634 27 of 81
     RFC2630のさらに詳細な結果は:
         Signed Data              24 of 25
         Enveloped Data     11 of 25
         Digested Data              0 of 4
         Encrypted Data             0 of 4
         Authenticated Data           0 of 16
         Other MUST Implement Requirements 15 of 25
         TOTAL -                49 of 96
     RFC2634に関するさらに詳細な結果は:
         Triple Wrap - 3 of 5
         Signed Receipts - 19 of 41
         Security Labels - 5 of 11
         Equivalent Labels - 0 of 12
         Mail List - 0 of 12
         TOTAL - 27 of 81

     Jim氏は、jimsch@exmsft.com 宛に入力すべきものがあればお願いします、 と要請した。


Examples of S/MIME Messages - Paul Hoffman

Paul氏は、 新しいリリースである"Examples of S/MIME Messages" I-D<draft-ietf-smime-examples-05.txt>, November 2000 を配布したと述べ た。これは、SFL を使い、Getronicsによって作成されたサンプルデータを追加したものを含ん でいる。彼は、さらなる入力とテストが必要だと述べた。彼は、Jim Schaad氏がこの文書に 含まれるサンプルのすべてをテストしていると述べた。John Pawling氏は、トリプル・ラ ッピングのサンプル・メッセージがこの文書に追加されるべきであると薦めた。Jim 氏 は、すでにいくつかのトリプルラップされたメッセージを作成して、それをこの文書に 載せるために Paul氏に提供するつもりであると述べた。


Mapping Company Classification Policy to the S/MIME Security Label - Weston Nicolls

Weston氏は、"Implementing Company Classification Policy with the S/MIME Security Label" I-D, <draft-ietf-smime-seclabel-02.txt>, October 2000という新 しいリリースを配布したと述べた。彼は、この文書はインフォメーショナルな(情報提供として の)RFCとなることを目的としていると述べた。この文書は、RFC2634 ESSセキュリティラ ベルの仕様が、どのようにしたら、ある組織のセキュリティポリシーをサポートするた めに使われ得るか、についての例を提供している。この文書は、機密種別ポリシーや、 Amoco、Caterpillar and Whirlpool Corporationsのセキュリティ・ラベルの例を含んでいる。こ れは、模範的なセキュリティ・カテゴリー文法とサンプルを含んでいる。さらにこれは、 subject(本人)認証を含む、秘密情報の利用許可属性の例をも含んでいる。Russ Housley氏は、この文書のラスト・コールは2001年1月までに完了する べきであると提案し、反対意見はなかった。


Symmetric Key Distribution - Sean Turner

Sean氏は、 S/MIME Symmetric Key Distribution I-D, <draft-ietf-smime-symkeydist-02.txt>, October 2000 の最新リリースが配布されたと述べた。 Sean氏 は、Jim Schaad氏が symkeydist-01 I-D からsymkeydist-02 I-D への改訂において重要なコ メントを提供したと述べた。Sean氏は、2つのメッセージが追加されたと述べた: GLProvideCert と GLUpdateCert である。 GLDistributionMethod メッセージは、削除された。GLInfo, GLOwner, および GLMember の文法は、アドレス情報を含むように修正された。 RFC2797CMS経 由での証明書管理メッセージとさらに整合性をとるために、多くの変更が加えられ た。彼は、いくつの rekeyメッセージが、そして、いつrekeyメッセージが配布されるかにつ いて説明するためのテキストを追加した。rekeyデフォルトは確定された(修正された)。Sean氏は、さらに適合性についての節とAbstract Syntax Notation One (ASN.1) module を追加する必要があると述べた。また、彼は、RFC2797エラー発生時の振舞い の正しさを確認する必要があるとも述べた。


DOMSEC Draft Discussion - Bill Ottaway

Bill氏は、"Domain Security Services Using S/MIME" I-D <draft-ietf-smime-domsec-07.txt>, November 2000 の概要説明を行った。彼は、S/MIME WGメーリン グ・リストでのJim Schaadとのe-mailでのやり取りの結果としていつかのマイナーな変更 を行った。彼は、Mail List Agents (MLA) に関する章を追加した。その中で、署名が mlExpansionHistory アトリビュート、および/または、envelopedData タイ プをカプセル化していて、MLAが'domain signature' を削除しようとするときのような 状況について取り扱う。彼は、domsec-07の第5章「メーリング・リストエージェントが存 在するときのドメイン署名の適応について」("Applying a Domain Signature when Mail List Agents are present" )で記述されているこの問題についての解決策について概略説 明した。彼は、DOMSECインターネットドラフトの主な問題点が解決されたのでラストコール をかけるべきであると確信していると述べた。

Russ Housley氏は、DOMSECの文書が S/MIME WGのラストコールの準備が整 ったと提案した。この文書はイクスペリメンタルRFCとして発行するつもりである。 Russ氏は、S/MIME WGのラストコールは、2001年1月10日に終了すべきであると述べた。反対意見はなかった。


X.400 and CMS - Chris Bonatti

Chris氏は、"Transporting S/MIME Objects in X.400" I-D, <draft-ietf-smime-x400transport-01.txt> および "Securing X.400 Content with S/MIME" I-D,<draft-ietf-smime-x400wrap-01.txt> 両方とも2000年11月に配布されたも の、について
の概略説明を行った。x400wrap I-Dは、CMSをもつX.400のコンテンツを保護 する方法について詳細仕様を示している。これは、RFC2633と概略では同じような物であ り、適用可能であればRFC2633を参照するものである。これは、オーバーヘッドを減ら すためにMIMEエンコーディングの利用を最小限にするものである。 彼は、提案してい るラッピング戦略の野概要説明をした。彼は、使用しているオブジェクト・アイデンテ ィファイア、MIMEヘッダーのパラメータや分離した署名形状について議論した。彼は、す でにBill Ottaway氏とGraeme Lunt氏が提出したコメントを取り入れている。Chris氏は、一般的な製品ではdata以外 のコンテント・タイプ(たとえば signed-data とかenveloped-dataなど)のカプセル化はサポートしていないと述べた。

Jim Schaad氏は、これに対してMicrosoft、SFL、およびPeter Gutmannのcryptlibの S/MIME v3の実装は、data以外のコンテント・タイプのカプセル化もサポートしていると 述べた。x400transport I-D は、X.400 Message Transfer Agents (MTA)による配送 のためのCMS 対応のオブジェクトをパッケージ化の仕方を示している。ここでは、CMSカプセル化コンテンツがRFC822のMIMEメッセージであるようなシナリオについて議論されて いる。外側のMIMEラッパーが一般的にはX.400では必要がないとも述べている。SMTP へのゲートウェイがアーキテクチャの一部であるようなときなど、外側のMIME ラ ッパーが
望ましいときが存在するような状況についても記述されている。

Chris氏は、 使用されているオブジェクト・アイデンティファイアX.400コンテンツにおけるCMSオブ ジェクトのパッケージングおよび、未サポートの証明書のみのメッセージについて議 論した。彼は、Bill Ottaway氏が提出したコメントを取り入れている。Blake Ramsdell氏は、証明書のみのメッセージのサポートについて質問し た。Chris氏は、証明書のみのメッセージはサポートされているが、ラッパーの中などで は識別できないと答えた。Chris氏は、これらのインターネット・ドラフトがスタンダード・トラック に載ることを推奨し、WGのフィードバックを求めた。Russ Housley氏と Jeff Schiller氏 は、Chris氏の推奨に同意した。


Reuse of Content Encryption Keys - Steve Farrell

Steveは、"Reuse of CMS Content Encryption Keys" I-D, <draft-ietf-smime-rcek-00.txt>September 2000の概略説明を行った。rcek I-D は、非対称暗号 (EnvelopedDataオブジェクトを用いて)シェアード・シークレット・キーをセットアップする方法 に ついて示している。また、そのとき次ぎのメッセージの鍵暗号化キー(KEK)を導き出すた めのコンテント暗号化キー(CEK)を再利用する方法についても詳細仕様について示してい る。ここでは、再利用されるべきCEKと再利用可能な最大の回数を示すEnvelopedDataに含ま れるアトリ
ビュートを定義している。

Steveは、このインターネット・ドラフトがKEKやCEKアルゴリズムが異なっ たものでなくてはならないときのCEKの再利用のための鍵を誘導するためのスキームを 指定していると述べた。このI-Dは、この場合の新しいアトリビュートを定義している。 CEK暗号化アルゴリズムの利用のみを要求するような新しい鍵誘導機能についても記述 されている。この機能はrcek I-Dの"Using different CEK and KEK algorithms"の章に記 述されている。Blake Ramsdell氏はSteveが新しい関数を定義する替りとして、Public Key Cryptography Standard (PKCS) #5 v2の鍵誘導について考察するよう薦めた。

Steve氏は、際立った問題としては、どれくらい多くの失敗した場合や提案 された鍵誘導スキームを示すことができるかだと述べた。彼は、さらに次のバージョンを 出して、WGのラストコールをかけたいと述べた。彼は、このI-Dがスタンダード・トラック に載せること推奨した。


Advanced Encryption Standard (AES) in CMS - Jim Schaad

Jim氏は、"Use of the Advanced Encryption Algorithm in CMS" I-D,<draft-ietf-smime-aes-alg-00.txt>, November 2000について概要説明を行 った。aes-alg I-Dは、対称鍵暗号のための追加のアルゴリズムとしてCMSへAESを 取り入れるための方法を示している。Jim氏は、下記のようなAESパラメータの概要説明 を行った:

ブロック・サイズ   16バイト固定
鍵長         128, 192 または 256 bits
提案では、      128 と 256 bitsが必須

Jim氏は、aes-alg I-Dは、AESキー・ラップ・アルゴリズムを含まないと述べた。彼は、ただひとつの必須の実装要求として256-bitキー・ラップ・アルゴリズムを含 むことを提案した。Paul Hoffman 氏は、Jimが256-bitと128-bitのキーによるパフォーマ ンスの違いを知っているかどうか質問した。Jimは、256-bitキー・ラップはより長い時 間がかかるが正確な違いは知らないと答えた。

鍵管理に関しては、この I-D は、適合実装はPKCS #1 v2.0の最適化非対称 暗号パディング(OAEP付RSA)技術を用いた鍵配送をサポートしなくてはならない(MUST)と定めている。これは、適合実装がEphemeral-Static (E-S) Diffie-Hellman (D-H) with modificationsを利用した鍵合意(キー・アグリーメント)をサポートしても よい(MAY)とも定めている。さらに適合実装は対称鍵暗号のキーマネジメントをサポー トしてもよい(MAY)ことも定めている。

Paul Hoffman氏は、S/MIME WG が128-bitと256-bitの両方の利用を定めた ならば、顧客は、最大のセキュリティを得るためにいつも256-bitキーを要求するだろ うと述べた。彼は、256-bitキーの利用が重要なパフォーマンスに対する打撃となることを心配している。たとえば、256-bitキーの利用がセキュア・メール・リストのパフォーマンス に徹底的なインパクトを与えるだろうと信じている。彼は、WGが128-bitキーの利用を定める ことのみを考慮すべきであるのではないかと問い掛けた。

Jim氏は、受信者の有効な公開鍵を得るために要求される証明書処理は 128-bitと256-bitキーの間のパフォーマンスの違いをはるかに超えるものであると答えた。

ある出席者は、企業は128-bit実装のものを販売できないと述べた。なぜな らトリプルDESよりも長い鍵長の利用をすでに宣伝しているからである。


RSA-OAEP and RSA-PSS - John Linn

John氏は、CMSやS/MIMEで利用する可能性のあるRSAベースの暗号化および署名アルゴリズムの利用について概略説明を行った。彼は、現在多くのS/MIME製 品がPKCS #1 v1.5 (RFC 2313)のアドホックなパディングを用いた暗号化・署名アルゴリズ ムを定義した RSAアルゴリズムを使用していると述べた。PKCS #1 v1.5 RSAは、RFC2630 (CMS)においてオプショナルなアルゴリズムとして定められている。John氏は、 PKCS #1 v1.5のパディング・フォーマットと使用について記述した。(彼の概略スライドが 詳細を提供)彼は、PKCS #1 暗号パディングにおけるBleichenbacherの適応的選択暗号文 攻撃について説明した。その攻撃は、10万回程度の解読からの情報があれば、どれが正し いパディングかを導き出せることを示している。成功した攻撃は特定の解読結果をもたら す。それは、originator(作者)のプライベートRSAキーを導き出すわけではない。対抗策 は、復号化に関する情報が攻撃者にとって利用可能でないこと(リターン情報に関する制 約;キーのランダム化、検出したパッド・エラーでの継続)を確かめるためのプロトコル・ レベルの手段、および、改良された暗号レイヤーでのプレーンテキスト対応のパディング (OAEP)である。さらに詳しい情報は、RSA Laboratories Bulletin #7 http://www.rsalabs.com/bulletins/ から得ることができる。

PKCS #1 v2.0 (RFC 2437)は、RSAアルゴリズムを用いた OAEPを利用するこ とにより暗号パディング攻撃から守ることができる。"Use of the RSAES-OAEP Key Transport Algorithm in CMS" I-D, <draft-ietf-smime-cms-rsaes-oaep-02.txt>に記述 されているようにCMSにおいて利用可能である。John氏は、最近の強度に関する理論的結果とOAEP 証明の過程が暗号研究のコミュニティにおいて議論されてきたその結果 OAEP はRSAを利用しても強度を維持できるという結論を強固なものにした。彼は、OAEPは ランダム・オラクル・モデルにおいて魅力的な資産を提供していると指摘した。それは おそらく安全で、 RSA関数の強度に直接的に関連するレベルのセキュリティである。彼は、 OAEPはプレーンテキスト対応であるという事実も強調した。OAEPが使われると、プレーン テキストを知らない限り有効な暗号文を生成することすら不可能である;それによっ て、選択暗号文攻撃から有効に守ることができる。彼は、RSAES-OAEPステップ(彼のスライ ドに詳細が説明されている)を概説した。

PKCS #1 v2.1 (draft, September 1999; 2回目のドラフトを準備中) は、 確率的な署名スキーム(Probabilistic Signature Scheme (PSS) )を用いて潜在署名攻撃 (potential signature attacks)から守る。John氏は、OAEPと同様に、PSSは立証可能な セキュアな設計を提供すると述べた。彼は、PSSエンコーディング操作について概略説明 した(彼のスライドに詳細が説明されている)。

John氏は、S/MIMEとして提案のOAEP技術の利用に際して関連の特許につい て彼は知らないと述べた。PSS エンコーディング方式はカリフォルニア大学(UC)が 特許申請中である。UC は、IEEEスタンダードに採用されたなら、メッセージリカバリー付 署名のPSS のライセンスを免除することに合意している。

John氏は、OAEPは安定しており、PKCS #1 v2.0, IEEE P1363 および ANSI X9.44の仕様に盛り込まれていると述べた。彼は、PSSの標準化はいくつかのフォーラ ムで進められており、IEEE P1363a や PKCS #1 v2.1 の仕様に盛り込まれる予定であると 述べた。彼は、 ANSI X9F1においてPSSを盛り込むべくX9.31を再開するつもりであると述べ た。ISO 9796-2においてPSS-Rを盛り込むことが現在進行中の改訂で行われている。 John氏は、次のように提案した。短かい期間はS/MIME v3の文書はPKCS #1 v1.5を「必須の実装」("MUST implement") 要求として指定し、OAEP付のPKCS #1 v2.0 RSAを「推奨の実装」("SHOULD implement")要求と指定する。彼は、WGがOAEP付RSA をインターラクティブなCMSベースのアプリケーションに関しては「必須の実 装」("MUST implement") 要求として指定するべきであることを薦めた。John氏は、PSS署 名がAESアルゴリズムと新しいハッシュ関数を用いた長期的なソリューションとして 採用されるべきであると提案した。

ある出席者は、複数の「必須の実装」("MUST implement") 要求は、スマー トカードやパームデバイスなどのような制限されたプラットフォームにおいてサポート が困難であるかもしれない、と述べた。

Jim Schaad氏は、RSA公開鍵のフォーマットは PKCS #1 v1.5とPKCS #1 v2.0 の OAEP付RSAとで、まったく同じであることを指摘した。彼は、受信者の証明書 を基き、暗号化時に鍵配送アルゴリズムとしてどのアルゴリズムを使用するべきかを アプリケーションはどのようにして決定すると想定されるのかと質問した。これは両方の アルゴリズムが「必須の実装」("MUST implement") 要求となった場合に問題となる。Jim氏 は、RSAが PKCS #1 v2.0 RSAを使う人が公開鍵を識別するために新しいオブジェクト・ アイデンティファイアを定義することを検討しているかどうか質問した。Russ Housley氏 は、RSAは両方のアルゴリズムをサポートする同じオブジェクト・アイデンティファイ アを使うことを決定したと答えた。

John Pawling氏は、SMIMECapabilitiesアトリビュートがエンティティの好 むキー管理アルゴリズムを識別するのに利用可能であると指摘した。Jim氏は、多 くの商品が SMIMECapabilitiesアトリビュートを処理できないと答えた。彼は、アプリ ケーションは複数のキー管理アルゴリズムをサポートしてもよく、SMIMECapabilitiesアト リビュートでどのアルゴリズムをアドバタイズしてよいかという質問が生じる。 Russ Housley氏は、アプリケーションはユーザがアルゴリズムの組み合わせを選択するようなメ ニューを提供するべきであると述べた。彼は、このトピックがさらにS/MIME WGメールリス トで議論されるべきであると示唆した。


RSA As a Must Implement - Blake Ramsdell

Blake氏は、RSA特許が期限切れとなったため、PKCS #1 v1.5 RSA公開鍵ア ルゴリズムを「必須の実装」("MUST implement") のキー管理および書名アルゴリズムと して指定するようにRFC2630を変更することを提案した。

Blake氏は、2000年7月のS/MIME WG会合の参加者の大多数がPKCS #1 v1.5 RSAと DSAアルゴリズムが「必須の実装」("MUST implement")署名アルゴリズムであ るべきという選択をしたと述べた。彼は、S/MIME WGメールリストへ両方が「必須の実 装」("MUST implement")となったならベンダーは本当に両方のアルゴリズムを実装するか どうかという質問を送ったと述べた。他の人たちは、両方のアルゴリズムが「必須の実 装」("MUST implement")として指定されることが正当化されるような妥当な要求事項があ るかと訊ねた。 Blake氏は、PKCS #1 v1.5 RSAアルゴリズムは「必須の実装」("MUST implement")署名 アルゴリズムとなるべきで、DSAは「選択可の実装」("MAY implement")署 名アルゴリズムであるべきと述べた。Blake氏は、PKCS #1 v2.0 OAEP付RSAも議論されるべ きであると述べた。

Paul Hoffman氏は、「必須の実装」("MUST implement")要求の定義につい ての問題を提起した。彼は、3つの定義を説明した:

1) 現在の利用を記述する
2) 明確な将来のソリューションを引き出す
3) 最適なセキュリティ・ソリューションを提供する

彼は、この問題に興味がある人たちがS/MIME WGメールリストに投票できるようなバーでの会合を開くべきであると薦めた。

Russ Housley氏は、Paul氏が示した3つの定義が異なるいくつかのアルゴ リズムセットを指すと述べた。彼は、この問題についてセキュリティエリアディレクタに 話すと述べた。彼は、議論の特徴付けに驚いた。

Russ氏は、PKCS #1 v1.5 RSA が「必須の実装」("MUST implement")要求と して承認されるときは、S/MIME WG は採用されるべき安全装置を文書で証明しなくて はならない。 Russ氏は、次の選択肢に関して「必須の実装」("MUST implement")の署名 アルゴリズムとして会合参加者の意見を求めるため投票を行った:

1) PKCS#1 v1.5 RSA
2) DSA
3) Both

会合参加者は、意見1)と3)とに半々に意見が分かれた。ただ一人が "DSA"に投票した。

Russ氏は、「必須の実装」("MUST implement")のキー管理アルゴリズムについて会合参加者の意見を得るため次の選択肢に関して投票を行った:

1) PKCS#1 v1.5 RSA
2) PKCS#1 v2.0 RSA with OAEP
3) E-S D-H

会合参加者は、選択肢1)と2)とに半々に分かれた。ただ一人が"E-S D-H"に投票した。

Russ氏は、「必須の実装」("MUST implement")要求の定義について参加者 の意見を得るため投票を行った:

1) force a specific future solution
2) describe current usage
3) provide optimal security solution.

この投票に参加した人は多くなかった。2人が選択肢1)に投票し、4人が 選択肢2)に、1人が選択肢3)に投票した。


Electronic Signature Formats - John Ross

John氏は、"Electronic Signature Formats for long term electronic signatures" I-Dについて概説した。esformats I-Dは、European Telecommunications Standardization Institute (ETSI) Electronic Signature Infrastructure Standardization に基いており、否認が試みられた際に署名の有効性の証明を提供する処理を定義している。 esformats-02.txt は、ETSI ES 201 733に基いている。新しいバージョンは esformats-03.txt は、 ETSI TS 101 733に基いている。すべてのバージョンは、RFC2630に基いている。

John氏は、verifier conformance options (Timestamping, Secure records); Signature policy options (Explicit by object identifier, Implied by signed content / signature environment); および Content encoding indication (Content hints)など、以前のバージョンに対する拡張を含むesformats-03 I-Dでの変更にについて 概説した。

John氏は、esformats-03 I-D はインフォメーショナルなRFCになる準備ができていると提案した。計画された作業は:ETSI 実装試験; XML 署名フォーマット;と 署名ポリシーにおける更なる作業である。

John氏は、電子署名の署名ポリシーを定義している"Electronic Signature Policies"I- D, <draft-ietf-smime-espolicies-00.txt> に関して概要説明した。彼は、 espolocies-00 I-D がイクスペリメンタルなRFCになる準備ができたと提案した。
 Russ Housley氏は、電子署名フォーマットのドラフトがS/MIME WGとしてラ ストコールの準備が整っていると提案した。この文書についてインフォメーショナル RFCとするつもりである。Russ氏は、S/MIME WGでのラストコールが2001年1月10日まで に終了するべきであると提案した。反対意見はなかった。

Russ Housley氏は、署名ポリシーの文書がS/MIME WGでのラストコールの準 備が整っていると提案した。この文書は、イクスペリメンタルなRFCとするつもりであ る。Russ氏は、S/MIME WGでのラストコールは、2001年1月10日までに終了するべきであ ると提案した。反対意見はなかった。


E-Signature Formats using XML - Denis Pinkas

Denis氏は、esformats I-Dで定義されているASN.1 タイプと同等の電子署 名情報を含んでいる新しい XMLタイプを ETSIが定義しようとしている内容について概要説明 した。これらの新しいXMLタイプはW3C・IETFにより定義されたように署名XML要素への追加を含んでいる。彼は、ASN.1からXMLへの1対1のマッピングはないと指摘 した。なぜなら ASN.1構造のいくつかは(たとえば MessageDigest 署名アトリビュー トのように) XMLディジタル署名の核となる文法に取り入れられている。Denis氏は、定義 されている新しい XMLタイプをリストアップした(彼のスライドに詳細な内容が書かれて いる)。彼は、たとえば、ASN.1プロトコルを実装しているタイム・スタンプ・エージェント のような PKI エージェントによって生成された ASN.1エンコードされたデータを新しいカプセル化 XML タイプが含んでいる必要がある。彼は、この目標を成し遂げるためいくつかの提案について議論した。


S/MIME Freeware Library (SFL) - John Pawling

John氏は、Getronics Government Solutionsが開発したRFC2630と2634のフリーウェア実装であるSFLに関して概要説明した。SFLは、RFC2631を実装するために Crypto++フリーウェア・ライブラリーを利用することができる。SFLは、 RFC2632と RFC2633の使用をサポートするための機能(関数)を提供している。これは、 RedHat Linux、 Windows NT/98/00とSplaris 2.7オペレーティング・システム上でテストされ てきた。 SFLは暗号アルゴリズムに独立であることに最大限の配慮を払っている。 RSA BSAFE v4.2、 Crypto++ v3.2、Fortezza CIそしてSPYRUS SPEX/ライブラリーを利用するこ とができる。
 Getronicsは、SFLで、PKCS#11インタフェースを提供するようなセキュリテ ィ・ライブラリーなら何でも使えるように開発している。

 Getronics社は、SFLを使って、S/MIME v3 相互接続テストにおける重要な 役割を果たしてきた。Getronicsは、RFC2632 と RFC2633 にあるいくつかの仕様と同じよう にRFC 2630、2631、そして2634の主要な仕様についてテストを行った。Getronics は、"Examples of S/MIME Messages"に記述された仕様の大部分を成功裡に処理し、生成する ためにSFLを用いた。SFLが生成したデータは、Examples-05 I-Dにおいて、署名付受領 書(signed receipts)、副署(countersignatures)、セキュリティ・ラベル、メール・ リ スト情報そして signing certificate attributes などを含んでいる。

SFLとMicrosoftの間のS/MIME v3相互接続テストは、必須のもの、RSAおよ びFortezzaアルゴリズム・スイートを用いて、ほぼすべてのCMS・ESSの仕様について成 功 裡にテストされた。たとえば、成功した署名付受領書の相互接続テストは、SFLと Microsoftとの間で行われた。Getronicsは、SFLがJim Schaad氏のS/MIME v3相互接続マトリクス の中で記述している仕様の大部分を生成でき、処理できている。完全なテストドラ イバーとテストデータがSFLでは利用可能になっている。

Getronics社は、2001年1月にSFLの新しいリリースを提供しようと計画して いる。そこでは、PKCS#11能力の改良版を入れる予定である。(GemPlus、DataKeyと Litronic のPKCS#11ライブラリーを使ってテストされる) これは、AESコンテント暗号化(aes-alg-00として)とキー・ラップ(128、192、256ビットのキー;CMSト リプルDES キー・ラップ・アルゴリズムに基く)も入れる予定である。またパフォーマ ンスを向上し、メモリー使用量を減らした改良されたSNACCライブラリーを入れる予定である。

John氏は、1997 X.509 勧告で示された X.509バージョン3証明書パス・ベ リフィケーション(デルタCRLが実装されないことを除き)のフリーウェア実装である証明 書管理ライブラリー(CML)に関する情報も提供した。CMLは;X.509証明書パスとCRLを 確認し;ローカルな証明書/CRL保管機能を提供し;LDAPによるリモートディレクト リー検索を提供する。CMLは、RFC2459要求事項の大部分を満たしている。Getronicsは、 2000 X.509証明書ポリシー・プロセッシング要求事項をサポートするべくCMLを拡張する 予定である。

John氏は、X.509アトリビュート証明書または公開鍵証明書で運ばれたセキ ュリティ・ラベルやオーソライゼーションを用いた役割ベースアクセス制御を提供する Getronics製のアクセス制御ライブラリーにかする情報も提供した。彼は、DERを実装した Getronics拡張SNACC ASN.1ライブラリーについても議論した。

Getronicsフリーウェア・ライブラリーのすべてについて、自由にソース コードが http://www.GetronicsGov.com/から利用可能である。Getronicsは、フリー ウェアは一切のロイヤリティやライセンス料金なしにアプリケーションの一部として利用 することができる。それぞれのGetronicsフリーウェアライブラリーは公開ライセンスと なっている。

インターネット・メール・コンソーシアム(IMC)は、SFL,CMLそして拡張SNACCのメール・リストを立ち上げている。John氏は、SFL/CML/拡張SNACCに関する メールは、IETFメールリストではなくIMCのメールリストへ送るように指摘した。


Wrap Up - Russ Housley

Russ氏は、議論すべきその他の問題がないか質問した。特になかった。散会した。


IDWG

# 株式会社サイバー・ソリューションズのグレン マンスフィールド氏の協力により報告いたします。

1.IDSとそのデータ交換に関する要件(Requirements Document)

WGの前提となる要件としてまとめたInternet Draft(draft-ietf-idwg-requirements-02.txt) を RFC とする過程として IESG(Internet Engineering Steering Group)に提出したが、作業不足が指摘され、現在、有効期限切れとなっている。IESGからのコメントを反映させ、メーリングリストによる議論を続ける予定である。

2.データのモデル化(IDMEF Data Model)

IDMEF (Intrusion Detection Message Exchange Format)に基づく交換データのモデル化について議論されてきた。表記として XML-DTD と SMI-MIB を比較検討した結果、WG では XML-DTD を採用している。XML-DTD の表記において拡張性が乏しいことが指摘された。今後、引き続き議論を続ける予定である。

3.通信プロトコルの設計

IAP (Intrusion Alert Protocol) と既存の代替プロトコルについて議論されてきた。今後、IAPではなく、他のWGである syslog (Security Issues in Network Event Logging) で議論されている BEEP(Blocks Extensible Exchange Protocol) を推進することが決定された。

4.XML-DTDとSMI-MIBによる実装仕様

CISCO、Silicon Defence、Cyber Solutionsで実装が試行されている。XML-DTD と SMI-MIB それぞれによる相互接続性は、確認されていない。XML-DTDとSMI-MIBそれぞれについて、引き続き議論を続ける予定である。

5.所感

idwgは、そのドキュメントに対する IESG からの指摘に対応できず危機に瀕している。ただし、その過程であったIDS間通信に関する議論は、非常に有意義であった。IPAの研究開発プロジェクトの成果をもってIETFの議論に参加することは、その成果等の新しい標準技術への対応を迅速化させる。大きなインパクトが期待される成果を目指し、積極的にIETFの議論に参加すべきである。