48th IETF ミーティング(ピッツバーグ)

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

IPA セキュリティセンター

最終更新日 2000.12.26

宮川寧夫
竹谷清康
山口嘉毅
isec-info@ipa.go.jp

1.全体概要

 48th IETFは、7月30日から 8月4日までピッツバーグ(米国) で開催された。その参加状況は、2158名・490企業・33カ国であり、 参加国の比率は上位からアメリカ 58%、日本6%、イギリス4%、ドイツ4%、 カナダ4%であった。また、参加企業は上位からシスコ、ノーテル、ルーセント、 ノキア、エリクソンであった。IPAからの参加者は2名であった。 次回のミーティング、49th IETFは2000年12月11日から12月15日まで サンディエゴ(米国)で開催される予定である。

2.IETFの概要

 IETF (Internet Engineering Task Force)は、インターネット関連技術 の標準化団体である。ここでは、RFC(request for comments)として、 インターネット標準技術についての一連の文書群を取りまとめている。 具体的には、RFCとなる前段階の文書「Internet Draft」について議論 し、次の種類のRFCを作成している。

  現在、IETF を構成する次の8つのエリアにおいて、 約80個のWG(Working Group)と16個のBOF(Birds of a Feather)によって セッションが行われた。

  また、全体ミーティングであるOpen Plenaryでは、 今回の技術的な話題として、SNMPとSMIを拡張・改善する技術が紹介された。 SNMPによるネットワーク管理の1つの接続において、多数のMIBを利用すると パフォーマンスが低下する問題を指摘し、データ通信をまとめる技術によって SNMPが改善されることが紹介された。また、IRTF(Internet Research Task Force) のNMRG(Network Management Research Group)で検討が進められきた SMIng(SMI next generation)が紹介された。 今後、その成果をIETFへ反映させていきたいという内容であった。

3.SecurityAreaの概要

  現在、情報セキュリティに関するエリア(SEC) に存在するWGの中で、今回セッションが行われたのは、次のWGであった。

  また、今後にWG として立ち上がるものとして セッションが行われたのは、次のBOFであった。

  各セッションでは、Internet Draftの内容に関する議論と標準化に向け たスケジュールの提示がなされた。SECでは、上記WGのセッション以外 にエリア全体に関するセッション、saag(Open Security Area Directorate Meeting) が行われた。その内容は、各WGの議論について の簡単な報告と次の発表などが行われた。

フリーディスカッションが行われた。今後のインタネットドラフトにおける必須暗号を決める必要があるかについて議論が行われたが、各ドラフトにおけるセキュリティ要件やレベルが異なるので、実装する暗号を限定する必要がない意見が大方を占めた。IETFの活動では、 実装技術を対象とするものであり、アルゴリズムそのものを議論の対象とすることは 適切でないとしながらも、ある程度保証された暗号技術として AESのサポートが必要であることは確認された。それにともない、 既存のRFCにおいて暗号技術を適用している部分を再検討する必要であることや、 今後の議論において、NISTでの評価手法が参考になることなどが指摘された。

IETFにおける暗号アルゴリズムの実装状況

各WGでは、どの暗号が各セキュリティ要件を最も満たしているか検討している。そのため、全てのドラフト(クライアント/サーバが必要としている暗号)で共通利用が可能な暗号モジュールが一つも無い。 

RFC1507からRFC2876までの必須または推奨暗号技術

暗号技術

必須

推奨

3DES

6

7

DES

16

20

SHA-1

17

23

MD2

1

6

MD5

19

11

DSA

10

2

RSA

7

17

D-H

11

4

 2000年 9月が今後の実装暗号に関しての転換時期

1RSA特許権が切れる。

2NISTAESを決定する。

3NIST2048bit DSASHA-2を決定する。

 今後の考え方を整理するため、暗号アルゴリズムWGや専門家によるパネルディスカッションを開催する必要があるのではないかと提案があった。

 本提案に関して、Chairをはじめ大方の意見としては、次の通りであった。状況認識としては、間違っていないが、WGや専パネルディスカッションを直ちに実施する段階ではない。各ドラフトにおけるセキュリティ要件やレベルが異なるので実装する暗号を限定する必要がない。

pkixPublic-Key Infrastructure (X.509) WG)では今回からNISTTim Polkco-chairに就任した。(デファクト・スタンダードを決める IETF で政府関係者が議長を務めるのは、PKI の標準が IETF 中心に決められているため)WGの現在テーマは、暗号アルゴリズム、タイムスタンプ、法的要件の証明書、証明書の有効性確認方法である。

tls (Transport Layer Security)では、WAP対応の開発とともに実装暗号がテーマで、今回は日本からmisty1cameliaepoc esignの暗号のプレゼンテーションがあった。(韓国からはSEED HAS-160を利用したドラフトが提案されている。)

また、Kerberos関連のWG BOFの活動が今までになく活発であった。


idwg 報告

山口嘉毅

  1998年10月に侵入検知技術のWGであるidwgが発足し、 これまでに次の事項について議論がされ、 Internet Draftが作成されてきた。

  最新のInternet Draft等は、チェアが運用する次 URL のサイトにて公開されている。 http://www.silicondefense.com/idwg/

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

IESG(Internet Engineering Steering Group) に提出しコメントが提示されている Internet Draft (draft-ietf-idwg-requirements-02.txt) は、有効期限が切れてしまったが、IESGのコメントを反映させ、 メーリングリストによる議論を続ける予定である。 2000年10月、Inforamtional RFCとすることを目標とされた。

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

時間の表記、センサではなくアナイザが必要とするデータ項目などの事 項に関するメーリングリストによる議論を続ける予定である。 2000年11月、Proposed RFCとしてIESGに提出することを目標とされた。

3.XMLとMIBの比較 (XML-DTD vs SMI-MIB)

更新された文書についてメーリングリストによる議論を続ける予定である。 2000年10月、Inforamtional RFCとすることを目標とされた。

4.XMLによる実装 (XML-DTD)

これまで議論されてきたIDEF(Intrusion Detection Exchange Format) に基づくXMLの仕様を利用して、XML DTDをXMLスキーム(XML Scheme)と いうものに拡張させる予定である。

5.MIBによる実装 (SMI-MIB)

 XMLアラートをMIBにマッピングする手法があり、今後その具体的な仕様 について議論する予定である。

6.通信プロトコルの設計(IAP, Intrusion Alert Protocol)

 既存の代替プロトコルについても議論されているが、 IAP(Intrusion Alert Protocol)についてメーリングリストによる議論を 続ける予定である。 2000年11月、Proposed RFCとしてIESGに提出することを目標とされた。

7.所感

最新のインターネット標準をIPAの研究開発事業に活かすことや、逆に、 IPAの研究開発事業の成果を標準とする機会をつくることを目的に、IPA と国内の技術者との連携をより密にする必要がある。

以 上


Public-Key Infrastructure (X.509) WGpkix

竹谷清康

LDAP v3 Profile D. ChadwickUniversity of Salford

draft-ietf-pkix-ldap-v3-02.txt ( 9月 2日に draft-ietf-pkix-ldap-v3-03.txt が公開された)

draft-ietf-pkix-ldap-schema-00.txt( 9月 8日に draft-ietf-pkix-ldap-schema-01.txt が公開された)

前回のバージョンでは、LDAPv3サーバのプロトコルとスキーマを同じドラフトに記述していたが、今回LDAP WGとの関係もあり、2つのドラフトに分割した。

Son of 2459 T. PolkNIST

従来の RFC2459 を証明書・失効情報のプロファイルと公開鍵・署名のアルゴリズム部分(従来の第7章)に分離。PKI暗号関連のドラフトを 6月14日に新しく作成。

draft-ietf-pkix-ipki-pkalgs-00.txt

暗号関連のドラフトでは、PKIで利用するハッシュ関数・署名アルゴリズム・鍵管理アルゴリズムについて記述。

ハッシュ関数 MD2 MD5 SHA-1
署名アルゴリズム  RSAPKCS #1 DSA  ECDSAANSI X9.62
鍵管理アルゴリズム RSA Keys Diffie-HellmanANSI X9.42Key Exchange Algorithm (KEA)

証明書・失効情報のプロファイルのドラフト

draft-ietf-pkix-new-part1-02.txt

Federal Bridge CAプロジェクトの証明書パス検証の課題として、

@確認された non-critical extention の取り扱い

AX.509 テキストの不整合

B実装におけるパス検証の違い

が報告された。

今後の追加作業としては

などがある。8月末のWG last call予定で作業を進めているとのこと。

 

Qualified Certificates (QC)/S. SantessonAddTrust

draft-ietf-pkix-qc-05.txt

多少の修正を加えて、近々最終ドラフトをセキュリティエリアのディレクターに送付する予定とのこと。( 8月16日に draft-ietf-pkix-qc-06.txt が公開された。)

 

Permanent Identifiers D, PinkasBull

draft-ietf-pkix-pi-01.txt

QCドラフトで議論されていた、個人をいかに特定するかについてのドラフトが新たに提案された。ASN.1の記述は以下の通り。

id-on-permanentIdentifier   AttributeType ::= { id-on 2 }

PermanentIdentifier ::=     SEQUENCE {

assignerAuthority        GeneralName OPTIONAL,

identifier                Name

}

assignerAuthority directoryName (which is a Name) registeredID (which is an OID) を指定する。DirectoryNameの場合は、その permanent identifier は、該当CA内で唯一となる。registeredID の場合は, その permanent identifier はグローバルに唯一となる。 

Time Stamping ProtocolD. PinkasBull

タイム・スタンピング・サービスは、特定時刻の前にデータが存在していたことを証明できるようにするものである。この文書は、TSA( Time Stamping Authority )に送られるリクエストと返送されるレスポンスのフォーマットを記述する。また、リクエスト処理とレスポンス生成に関して、TSA 運用のためのいくつかのセキュリティ関連の要件 についても確立する。TSA は、TTP( Trusted Third Party ) サービスとして運用される可能性がある。しかし、 他の運用モデルも適切である可能性がある。例:組織体によっては、内部のタイム・スタンピング目的のために TSA を要求する可能性がある。非否認( Non-repudiation )サービス [ISONR] は、特定時刻より前にデータの存在を確立する能力を要求する。このプロトコルは、そのようなサービスをサポートするための部品として使用されることになる。公開鍵証明書の有効期間内にデジタル署名が生成されたことを証明する方法の一例が、補遺に記述されている。

draft-ietf-pkix-time-stamp-09.txt(10月12日に draft-ietf-pkix-time-stamp-10.txt 、10月24日に draft-ietf-pkix-time-stamp-11.txt 、11月21日に draft-ietf-pkix-time-stamp-12.txt が公開された。)

version7 からの変更点は、以下の通り。

プレゼンテーション資料:
http://www.ietf.org/proceedings/00jul/SLIDES/pkix-tsp/index.html

son of 2459に変更依頼中とのこと。)

 

OCSP Extensions M. MyersVeriSign

昨年提案された OCSP Extension のドラフト(Son of 2560)に関してのプレゼンが行われた。

OCSP は既に RFC 2560 になっており、フレームワークとして最適であるとの考えのもと、今回 path discovery のドラフトと path validation のドラフトを作成するとの発表であった。( 9月18日に draft-ietf-pkix-ocsp-path-00.txt が公開され、9月19日に draft-ietf-pkix-ocsp-valid-00.txt が公開された。)

D. Pinkas OCSP関連について、4つのコメント(課題)をプレゼンテーションした。

1)証明書パスの有効性は何によって判断するか

security policy define by an OID
or multiple roots,Certification Policy constraints and naming constraints

2The delegated path construction features---とは

Collect all
Collect only the certification chain
Collect the certification chain and the associated revocation information

3revocation information とは

anything
CRLs
OCSP responses

また、上記の情報は、該当証明書のみについてか、全ての証明書パスについて必要か

4)仮にすべての検証をサーバーが行ったとしても、検証に使った情報は、要求により取り出すことが可能でなければいけない。

 

SCVP A. MalpaniValiCert

draft-ietf-pkix-scvp-03.txt

今回もSVCPOCSPX比較のプレゼンを行った。

Remote Path ProcessingRPP要件は下記の項目である。:

RPP実現手段としては、OCSPXSVCPがある。既にOCSPが標準になりつつあり、OCSPを利用して OCSPXにすることはいい方法。しかし、OCSPXには、いくつかの問題がある。OCSPX は、複雑にしすぎたOCSPである。(全て、拡張機能で行い、処理も遅い。)OCSPのドラフトは現在無い。(過去提案されたが、有効期間が切れている。)プレゼンの結論として、SVCPのドラフトは、既に4版で、1ヵ月以内に実行可能プログラムができる。SVCPは、ASN.1XLMの対応も可能である。SVCPこそ、みんなが待っていたものである。と説明している。

 

Attribute Certificates S. FarrellBaltimore

draft-ietf-pkix-ac509prof-04.txt

X.509-2000 との整合性などを修正したとのこと。( 8月 8日に draft-ietf-pkix-ac509prof-05.txt が公開された。)

 

Repository Locator P. Hallem-BakerVerisign

draft-ietf-pkix-pkixrep-00.txt

今回新しく提案されたドラフトでPKI repository locator serviceについて記述している。今後 LDAP WG DNS WG とも連携を取りながら進める。

 

CMP C. AdamsEntrust

draft-ietf-pkix-rfc2510bis-01.txt

今回は特に大きな変更はなく、PKIフォーラムの結果をみて変更予定とのこと。

 

CMP Interoperability testingB. MoskowitzICSA

この活動はPKIフォーラムで行われており、CMPCertificate Management Protocol)の相互接続性をはかるもので、RFC2510,RFC2511ドラフト2510bis CPMtransport がベースとなっている。

現在参加している組織は、Certicom Cylink Entegrity Entrust TCTrustcenter SSH Sun(java) 、参加を検討している組織としては、Baltimore IBM NIST Open CA RSAResearch Utimaco そしてJonahさんである。

10月の NISSChttp://csrc.nist.gov/nissc/ )で公開デモを予定している。

この活動により、CA のポリシーがエンドエンティティの利用に大きく影響を及ぼすことが判明し、RFC 2510の更新にも役立つと説明している。

Certificate Management Messages over CMS (CMC)の相互接続の活動も今後必要であると説明していた。


S/MIME Mail Security WGsmime

竹谷清康

RFC2630-2634の相互接続テストが開始されているが、あまり進んでいない様子である。

RFC 2630: Cryptographic Message Syntax
RFC 2631: Diffie-Hellman Key Agreement Method
RFC 2632: S/MIME Version 3 Certificate Handling
RFC 2633: S/MIME Version 3 Message Specification
RFC 2634: Enhanced Security Services for S/MIME

前回のミーティング ETSI から提案されたElectronic Signature Formats for long term electronic signaturedraft-ietf-smime-esformats-00.txt)は、今回2つのドキュメント(Electronic Signature FormatsElectronic Signature Policies)に分割されて提案された。これらのドラフトは informational RFCで、ETSI ES 201 733 V.1.1.32000-05)と技術仕様は同じである。ETSIは、今後タイムスタンプを必須としない long term electronic signature XML をベースとした long term electronic signature の検討を進めるとのこと。

WG において、S/MIMEの実装暗号アルゴリズムについて意見を参加者に聞いたところ、共通鍵は、3-DES のみ、AES のみ、 両方の3者はほぼ同数であった。署名も、RSA のみ、DSA のみ、両方の3者は僅差ではほぼ同数で、僅差ではあるが両方が1番多かった。鍵管理は RSAPKCS#1 V1.5)が最も多く 次にD-Hで 両方はほとんど手が挙がらなかった。S/MIME v2 との互換性が1番重要であると WG は判断した。(ただし挙手したのは 20名程度で観客が多かった。)

(参考)

議事録 仮訳

S/MIME WG の現状(Russ Housley)

下記の RFC をプロポーズド・スタンダードからドラフト・スタンダードへ進めるための戦略について概略説明した。

  • RFC 2630 Cryptographic Message Syntax, 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 theDiffie-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]

上記文書をドラフト・スタンダードへ進めるに当たって下記のような要件を満たす必要がある。

1)RFC2026に記述された要件を満たす

2)安定、成熟、有用な仕様であること

3)少なくとも2つ以上独立した相互接続性のある実装が必要であり、それらは異なるコードを元にした実装であること

4)ドラフト・スタンダードは、プロポーズド・スタンダードのRFCや、ExperimentalなRFCを参照することができない。したがって上記 RFC は、PKIX証明書とCRLプロファイル"son-of-RFC 2459"のインターネット・ドラフト draft-ietf-pkix-new-part1-02.txt)がドラフト・スタンダード(ラスト・コールは2000年8月7日までに開始されると想定された)に進むまで、先に進むことはできない。

Russ は、Jim Schaad氏がRFC2630〜2634の相互接続マトリックスを作成中と報告。
相互接続マトリックスは、<http://www.imc.org/ietf-smime/interop-matrix.html>に掲載される。
マトリックスは、各詳細仕様が実装されているかいないかを示している。これまでマイクロソフトとワング・ガバメント・サービス(WGS)、Getronics Companyが相互接続マトリックスに入力を提供した。WGSは、S/MIMEフリーウェア・ライブラリー(SFL)の能力に関する入力をマイクロソフトと共同で相互接続テストを行うとともに提供してきた。

Russは、Paul Hoffman(IMC)が相互接続テストをコーディネートを提供し、S/MIME メッセージの用例のインターネット・ドラフトを拡張させてきたことについて説明した。彼は、相互接続試験にそれ以外の組織が参加しなかったことについても触れた。S/MIME v3の機能について開発した他の組織の人がぜひ参加するように要請した。

S/MIME v3のいくつかの機能で少なくとも2つ以上の実装の間で相互接続試験が行われていないものがある。例えば、EncryptedData、AuthenticatedData、DigestedData コンテント・タイプについては、2者の間ではテストされていないとRussは指摘した。

Russは、RFC2630は、次のように記述を変更するべきであると提案した。 

- EnvelopedData and SignedData は実装されなくてはならない(MUST)かつ

- EncryptedData, DigestedData, AuthenticatedData は実装されてもよい(MAY)

Russは、IETF S/MIME WGメーリング・リストに提出すると言った。



相互接続マトリックス(Jim Schaad)

Jimは、RFC 2630 から 2634までの相互接続マトリックスについて議論した。各RFCにおける双方向の相互接続テストで成功した節の数について発表した。かれは、行われたすべての相互接続テストについてに基づく結果を完全に更新したわけではないと述べた。

RFC テストした節

2630 45 of 96
2631 0 of 13
2632 16 of 21
2633 17 of 61
2634 0 of 81

Jimは、他の人に入力するために情報を jimsch@exmsft.com あてに送るよう要請した。



+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

CERTDIST Draft Discussion - Jim Schaad

Jim は、the Certificate Distribution Specification I-D<draft-ietf-smime-certdist-05.txt>, May 2000について述べた。
メーリングリストでの議論に基づいて、証明書発行に際して、第二のサポート情報である次のようなSMIMECapabilities attributeについての3つの考え方があるとJimは述べた。

1) attribute certificates (AC)を利用する
2) 署名されたオブジェクトの中にユーザの証明書を置く (certdist-05を参照)
3) 署名されたオブジェクトからユーザの証明書を省く

Jimは、ACストラテジーの有利な点はX.500スキーマにうまくマッチする点であると述べた。この利点は、ACが「新しく」かつ、これが必ずしもACの良い使い方であるとは限らない点である。

Jimは、署名されたオブジェクトにユーザの証明書を含めるというストラテジーの利点は要求された情報のすべてを検索するため唯一のロケーションであるということである。欠点は、潜在的に一貫性の問題があるということと、ディレクトリーから検索されるべき複雑な要素が存在することである。

Jimは、以下の選択肢について会合参加者の意見を得るための投票を行った。

1)コンセンサスを得るための努力を続ける
2)コンセンサスなしにスタンダード・トラックに採択する
3)コンセンサスなしにexperimental トラックに採択する

会合参加者の大多数は選択肢1を選んだ。

Blake Ramsdell氏は、S/MIME WG メーリングリストに加えてIETF PKIX WGのメーリングリストでもこれらの問題が討議されるべきであるかどうか質問した。Russは、これらに興味のある人はS/MIMEメーリングリストに参加しているので、PKIXメーリングリストでこの問題を討議する必要はないと簡単に述べた。


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Symmetric Key Distribution - Jim Schaad for Sean Turner

Jimは、S/MIME 対称鍵配送に関するインターネットドラフト<draft-ietf-smime-symkeydist-01.txt>, July 2000について報告した。Jimは、Sean がsymkeydist-01のドラフトに合併されるという条件でsymkeydist-01へ重要なコメントを提供した。

Jimは、対称鍵配送ストラテジーに対する主要なアーキテクチャの変更が行われたと述べた。鍵管理エージェント(KMA)とグループ管理エージェント(GMA)は、ひとつの構成要素として統合され、グループリストエージェント(GLA)と呼ばれている。この変更は重複したKMAチェックを取り除くためのものである。この変更は、KMAとGMAが同じ箱に実装されることがあるという仮定に基づいて行われたものである。

Jimは、対称鍵配送ストラテジーについて、主なプロトコルの変更が行われたと説明した。新しいコンテントタイプを定義する代りにsymkeydist-01はデータの交換はRFC2797(CMSを用いた証明書管理メッセージ)に基づいたプロトコルを仕様すると明記している。

アーキテクチャやプロトコルを変更した結果としてこの文書には多くのその他の修正が行われた。

Jimは、control attributesに関する以下のような実装上の要件について説明した。

Implementation
Requirement Control Attribute
==================================
MAY glUseKEK
MAY glDelete
MAY glAddMembers
MAY glDeleteMembers
MAY glRekey
MAY glAddOwners
MAY glRemoveOwners
MAY glkCompromise
SHOULD glkRefresh
MAY glSuccessInfo
MAY glFailInfo
MAY glAQueryRequest
MAY glAQueryResponse
MUST glKey

Jimは、ユーザとGLAの間のプロトコル変換は「実装上必須」の要件に変更されると述べた。さらにKMAとGLAとの間のプロトコル変換は「実装上必須」の要件として存続するとも述べた。



+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

この "Implementing Company Classification Policy with the S/MIMESecurity Label" I-D, <draft-ietf-smime-seclabel-01.txt>, July 2000,は、Weston Nicollsにより執筆されたものである。Westonは、会合で説明する予定であったが、航空機の遅延のため、出席できなかった。このトピックについては何も報告がなされなかった。


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Message Compression - Ned Freed

Ned Freedは、圧縮を扱うためのMIMEエンコーディングを提案している。彼の提案は、署名または暗号化される前にMIMEエンコーディングを用いてメッセージを圧縮するというものである。 Ned Freedは、今回の会合に出席できず、このトピックについて何も報告はなかった。


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

DOMSEC Draft Discussion - Bill Ottaway

Billは、"Domain Security Services Using S/MIME" I-D<draft-ietf-smime-domsec-06.txt>, July 2000について、報告を行った。Billは、前回のS/MIME WG会合から2つの DOMSEC ドラフトの発表を行ったと述べた。DOMSEC-05では、Luis Barrigaからの指摘に基づいた明確化と、signatureType attributeのオブジェクト識別子を追加した。DOMSEC-06では、Jim Schaadからの指摘に基づいた訂正と明確化と、ASN.1の追加モジュールが含まれている。

Billは、Jim Schaadからのいくつかの技術的な提案とともにいくつかの課題についてその場で討論を行った。E-メールでは、Jim Schaadは「Section 3.0 Bullet 1: この考えは私を悩ませている。degenerateされたcerts only メッセージのような場合を除いて署名データのオブジェクトの中には少なくとも1つ以上の署名があると仮定されるようなプログラムがいくつかあると私は考える。」と言っている。Blake Ramsdellは、あるアプリケーションはsignerInfos のないsignedDataはcerts-only メッセージであると解釈すると何度も言っている。Billの立場は、CMS(section 5.1)がzero signerInfos があってもよいと記述しているので、対応した実装はzero signerInfos のsignedDataを処理できるようにするべきであるということになる。他の会合出席者に対して、DOMSECがsignerInfos を持たないsignedDataオブジェクトの使用を省くように変更するべきかどうか訊ねた。会合参加者は、だれも応えなかった。

Eメールでは、Jim Schaadは、「Section 4 Paragraph Last-2 にて、どうしたらこれを守らせることができるか? 鍵の配送に関して、送信者は匿名で、鍵合意については送信者の証明書はしばしば検証されない。さらにドメイン構成要素はうまく合うように変更可能であるし、または送信者のドメイン名でない私のドメイン名に合うようにするべく、再度暗号化が施された私のドメイン構成要素であるかもしれない。」と言っている。Billの立場は、「CMSで示されている仕様に対して余分なものは、DOMSECで定義された、名前付けの規約と名前のマッピングの規約が使われていることだけである。これは、公開鍵を置くために指定されている。例えば、もしドメインが受信者w.ottaway@eris.dera.gov.uk のドメインに関する公開鍵を置く必要があるなら、そのときdomain-confidentiality-authority@eris.dera.gov.uk に属する公開鍵が置いてある必要がある、または、もし存在しなければ、上位のドメイン名の公開鍵が置いてある必要がある。」というものである。Billは、DOMSECメッセージが作成者のドメインと、実際の受信側ユーザではなく受信側のドメインの間で暗号化されるとも述べた。テキストは、作成者のドメイン・エージェントが受信者の名前をどのように参照することができるかを説明する目的で意図されていると述べた。テキストについて彼は明確化するつもりである。Billは、未解決の課題が解決されるべきであり、その後DOMSECドレフとがラストコールのために発表されるべきでると信じていると述べた。


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

RSA As a Must Implement - Blake Ramsdell

Blake Ramsdellは、RFC2630がRSA公開鍵アルゴリズムを「実装上必須」の鍵管理アルゴリズムとして必要とするために変更されるべきであると提案した。なぜならRSAの特許が2000年9月20日に切れるためである。彼は、「実装上必須」の署名アルゴリズムとしてRSA公開鍵暗号アルゴリズムを必要とするようにRFC2630を変更することについての質問を提案した。

John Pawlingは、RSA公開鍵アルゴリズムに関連した特許について誰か応用した(応用特許を持っている)人はいないかを質問した。Russ Housleyは可能性があると言った。なぜなら特許のファイルは広告されるまで秘密にされているからである。例として、ある組織がディフィーヘルマン鍵合意方式に対する"small-subgroup" 攻撃を排除するための方式に関する特許を持っていることを彼は述べた。RSA公開鍵アルゴリズムに関連する特許に関しては誰も表明がないと述べた。John Linnは、RSAはRSA公開鍵アルゴリズムに関連するいかなる特許を持っていない(彼の知る限りは)と述べた。

Pat Cainは、この重要な変更がS/MIME v3 RFCsをインターネット・プロポーズド・スタンダードからインターネット・ドラフト・スタンダードへ進めるのを遅らせるのではないか心配していると述べた。Jim Schaadは、この変更はS/MIME v3 規格を実装するプロセスを遅らせはしないと回答した。Russ Housleyは、この変更は恐らくS/MIME v3 RFCsをインターネット・プロポーズド・スタンダードからインターネット・ドラフト・スタンダードへ進めるための時計をリセットするだろうと述べた。

ある参加者は、PKCS #1は十分にテストされていないと指摘した。他の参加者はWGが特許の影響に加えて暗号アルゴリズムの品質を考慮する必要があると述べた。

Jim Schaadは、DSAは「実装上必須」の署名アルゴリズムとして留まるべきである、なぜなら署名値はバイト数を減らすことが必要とされており、すでに広く実装され必要とされているからである、と述べた。

Russ Housleyは、RFC2630セキュリティの考察セクションがPKCS #1 v2.0最適の非対称暗号パディング(OAEP付RSA)技術が PKCS#1 v1.5 RSA 鍵管理アルゴリズムのかわりに使われるべきであると推奨していると述べた。したがって、もしも Ephemeral-Static Diffie-Hellmanがもはや実装上の必須アルゴリズムでないならば、彼はその置き換えとしてOAEP付のRSAの仕様を推奨する。

Jim Schaadは、RFC2630からアルゴリズム関連のテキストを分離することが新たな6ヶ月の待機期間が必要になってしまうかどうか質問した。Russはそのような変更だけであれば、新たな6ヶ月の待機期間は必要だとは思わないと回答した。なぜならそれがRFC2630の核心の要件に影響を与えないからである。

Phillip Hallam-Bakerは、製品の"S/MIME v3"マークはすべてのS/MIME実装と相互接続性があることを意味しており、D-HよりもむしろOAEP付のRSAを支持するという彼の信念を表明した。

ある参加者は、OAEP付のRSAがPKCS#1 v1.5 RSAを実装しているS/MIME製品との間のbackward互換性を破るかどうか質問した。Russはbackward互換性を破ると回答した。

Blake Ramsdellは、OAEP付RSAを使うことはEphemeral-Static (E-S) D-Hを使うよりはより良い選択であることを指摘した。なぜなら同じRSA証明書がPKCS#1 v1.5 RSAとOAEP付RSAの両方で利用可能であるから。

Russは「実装上の必須」の鍵管理アルゴリズムに関する以下の選択に関連した意見を会合参加者に投票するように求めた。

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

投票した会合参加者の大多数は、選択肢1を選んだ。

ある参加者は、OAEP付のRSAに関連する特許が出されていないか質問した。RussがOAEPの著者がOAEPに関連した特許は出していないと語ったと回答した。

Dave Soloは、WGは署名と「実装上の必須」の署名アルゴリズム要件の検証を分けて討議できるかどうか質問した。RussはDaveの要求に応えて会合参加者の投票による意見を求めた。投票した会合参加者の大多数は、署名と「実装上の必須」の署名アルゴリズム要件の検証を分けるべきでないとした。

Russは、「実装上の必須」の署名アルゴリズムについての以下の選択肢の中から会合参加者の意見を得るため投票を求めた。

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

投票した会合参加者の大多数は、選択肢3の両方であった。

Russは、S/MIME WG メーリングリストにこれらの提案を発表すると述べた。早ければ、これらの変更は2000年9月になるだろうと付け加えた。

ある参加者がどのくらいの組織がOAEPを実装したか質問した。RussはOAEPを含んだ実装はまだ知らないとの回答した。

ある参加者がベンダーは連邦政府の調達目標のためNISTが承認したアルゴリズムを使用するように要求されていると述べた。Russは X9.42 D-H と X9.44 RSA は両方とも承認されていると述べた。

Russは、NIST AES の勝者が2000年の9月に発表されると述べた。彼は、WGがトリプルDESのかわりにAESが実装上の必須の対称鍵暗号アルゴリズムであるべきかどうか議論するべきであると示唆した。Dave Soloは、AESは、まだ理論上のものに過ぎないと述べた。

Russは、「実装上の必須」の対称鍵暗号アルゴリズムについての以下の選択肢の意見を得るため会合参加者の投票を求めた。

1) Triple-DES
2) AES

投票は、ほぼ同数の選択肢に分かれた。

Pat Cainは、S/MIME v3 規格は現時点ではトリプルDESを引き続き必須とし、しかし今後AESをWGとしては考慮することができるとすることを推奨した。

Phillip Hallam-Bakerは、S/MIME v3 規格はトリプルDESとAESの両方を必須とするべきであると述べた。

Carlisle Adamsは、AESが「実装上の必須」の対称鍵暗号アルゴリズムでなければならないという信念を述べた。Pat Cainは、AESは,来年末までは実装されないかもしれないと回答した。Jim Schaadは、OAEP付のRSAも実装が遅れると述べた。

ある会合参加者はAESがまだ発表されていないと述べたが、Carlisle Adamsは5つのAES候補が良く知られていると回答した。これらの人々の間で5つのAES候補の実装が始められている。

Russは、S/MIME WG メーリングリストにこれらの提案を発表すると何度も述べた。


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Examples of S/MIME Messages - Paul Hoffman

Paul Hoffmanは、会合に参加する予定だったが S/MIME WG と時間が重なったWGに参加するため,説明はなかった。


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Electronic Signature Formats - John Ross

Johnは、"Electronic Signature Formats for long term electronic signatures"I-D, <draft-ietf-smime-esformats-01.txt>, July 2000 について説明した。esformats-01 ドラフトは、ETSI電子署名基盤標準化に基づいている。

Johnは、esformats-00ドラフトが2つの文書に分割されたことを報告した。ひとつは、電子署名フォーマットをカバーし、情報提供のためのRFCとして提案されている。網ひとつは署名ポリシーをカバーし、experimental RFCとして提案されている。

Johnは、esformats-01 が以下の RFC を用いていると説明した。:

-RFC 2630 Cryptographic Message Syntax (CMS)
-RFC 2459 PKIX Certificate and CRL Profile
-RFC (to be published) PKIX Timestamping protocol
-RFC on "Attribute Certificates"

彼は、esformats-01 I-D が否認が企てられた時の署名検証の証拠を提供するプロセスを定義していることを概要説明した。

Johnは、esformats-01の内容が技術的にETSI ES 201 733 V.1.1 の文書と等価であると述べた。ETSIはこの文書の著作権を持っている。Johnは<http://www.etsi.org>からダウンロードできる、この文書の個人的な複写を持っていると述べた。彼は、2つの新しい作業項目:タイム・スタンピングを必須としない長期間使用可能な署名フォーマットと、XML署名シンタックスに基づく長期間使用可能な署名フォーマット、があることを述べた。


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Signature Policy Format - Denis Pinkas

Denisは、"Electronic Signature Policies" I-D, <draft-ietf-smime-espolicies-00.txt>について説明した。

Denisは、ETSI ES 201 733 V.1.1.3(2000-05)文書に基づいて定義された署名ポリシーに基づいていると述べた。ETSIは、この文書の著作権を持っている。Denisは、このドラフトが電子署名の署名ポリシーを定義していると述べた。彼は,署名の有効期間が確定できると言う条件の下で、署名ポリシーを電子署名の生成と検証のための規則集として定義している。彼は、与えられた法的/契約上の環境がその要件に合うように特定の署名ポリシーとして認識されると述べた。彼は、署名ポリシーはグローバルにユニークなリファレンスを持っていて、署名計算の一部分として署名者による電子署名に結び付けられている。署名ポリシーは人間が読むことができる形で利用可能となっている必要があり、したがって適応される法的および契約上の環境の要件に合うことを評価することができると彼は述べた。電子署名の自動的な処理を可能にするため、コンピュータが処理可能な形で電子署名の生成や検証のための電子的な規則を電子署名ポリシーの別の部分が明示することについて彼は説明した。現在の文書がASN.1と説明した提案されたシンタックスを用いて署名ポリシーのフォーマットを定義していると述べた。

Denisは、ドラフトの section 5 について、以下を含む適合性の要件を定義するための作業が続いていると述べて説明を終わった。5.1 署名ポリシー定義 - 署名ポリシー発行者によって発行された如何なる署名   ポリシーは以下を含むべきである ...(SHALL)5.2 署名システムに関して - 署名システムは ... にしたがって定義された署名ポリシーの署名者ルールに対して、[ES-FORMATS] にしたがって定義された電子署名を処理できなくてはならない。(MUST)5.3 検証システムに関して - 検証システムは、 ... にしたがって定義された署名ポリシーの検証者ルールに対して、[ES-FORMATS]にしたがって定義された電子署名を処理できなくてはならない。(MUST)

ある参加者は署名に関連したひとつ以上のタイム・スタンプが存在することに関しての課題があるかどうか質問した。Denisは、署名ポリシーは単一か、多数のTSAsを必須としてもよいと回答している。例えば、別々のTSAsが送信者と受信者について明示してもよい。Carlisle Adamsは、ETSIに関するタイムフレームについて質問した。Denisは、電子署名フォーマットについてのASN.1は安定しているが、署名ポリシーの ASN.1シンタックスはまだ活発に議論されていないと回答した。彼は、年末までには安定した署名ポリシーの文書が出来上がると確信している。

John Rossが、両方の文書のコメントを要請した。


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

まとめ - Russ Housley

Russは、それ以外の議論すべき課題があるかどうか訊いた。会合参加者は何も言わなかった。

以上



Transport Layer SecurityWG(tls)

竹谷清康

1996年設立時に創られた TLS WG charter を今回見直すことになり、WG としては TLS をインターネット標準として広めることを主目的として活動することになった。

マイルストーン(計画)は以下の通り。:

2000年11月 First revised draft of TLS specification

2001年 4月Submit specification to IESG for consideration as Draft Standard

WTLSTim Wright Vodafone and chair WAP Security Group

WAP Forumから提案は、TLSのワイアレス向け仕様をIETFと共同することである。

暗号実装提案

今回のミーティングでは、TLSで使える暗号として日本から Misty-1CamelliaEPOCPSECの提案があった。 既に、韓国からは、SEED/HAS-160のドラフトが提出されている。

End-to-end Security for Small Devices Vipul Gupta (Sun)

TLSの実装例に関するプレゼンテーションがあった。

http://playground.sun.com/~vgupta/KSSL


更新履歴

PKIX の Time Stamping Protocol について、最新のインターネットドラフト(v.12)をリンク。(2000.12.26)

PKIX の Time Stamping Protocol と、OCSP Extensions について加筆。(2000.10.25)