IETF インターネットセキュリティに関する情報収集の報告のトップページ

最終更新日：2001年 9月12日

51st IETF ミーティング（ロンドン）

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

　

情報処理振興事業協会
セキュリティセンター
isec-info@ipa.go.jp

　

Open Plenary

今回の参加者は、アメリカイギリス日本フランスドイツ韓国をはじめとして 45ヶ国 2,457名であった。

Security Area

Open Security Area Directorate Meeting（saag）／Jeffrey I. Schiller（MIT）

今回開催の WG/BOF は次の通り(開催順)：

INCH Extended Incident Handling BOFは当初開催予定であったが中止となった。XML Digital Signatures WG- An Open Specification for Pretty Good Privacy WG- Secure Network Time Protocol WG- Intrusion Detection Exchange Format WG は、開催されなかった。

Public-Key Infrastructure (X.509) WG

CHAIRS: Stephen Kent <kent@bbn.com>
Tim Polk <tim.polk@nist.gov>

PKIX-WGの活動状況/Tim Polk (NIST)

現在のInternet-Draft数は26。Draft Standards検討中のドラフトは以下の通り。：

新しいドラフトは次の通り。

その他新しい提案

Logotypes/Stefan Santesson (Addtrust)

<draft-ietf-pkix-logotypes-00.txt>
　このドラフトは、デジタル処理だけでなくクレジットカードのロゴのように、人に も認識しやすい仕組みを考えた証明書のlogotypesについての提案である。利用業務としては、以下のようなものを想定しているらしい。

ウェブサーバーの認証証明
B2B/B2Cの e-mail
EDI などのデジタル業務でなく、健康管理業務など

証明書における logotypes として
1) Concept logotype
2) Issuer organization logotype
3) Subject organization logotype

logotypes仕様の追加方式案として

1) Policy qualifier
Policyによるコントロールが可能になる。但し、(RFC 2459) の仕様に合わない

2) Issuer and Subject Alternative names extensions
Name constraintsで下位のCAをコントロールできるメリットがある。但し、Logotypes はname formになっていなく、 logotypeデータが複数にあることは利用アプリにとって不都合である。また、IETF とITU-T の仕様問題になる可能性があ る。

3) New extension
従来の仕様への影響がなく、最もいい解決だと思えるが、Name constraints との関連を整理する必要がある。Security considerationsとしては、logotypesの検証が難しいことや下位CAによる Name constraintsの悪用などが考えられる。このドラフトは技術的な問題だけでなくアプリケーション的な要素も含んでいる。

Supplemental Public Key Algorithms/ Ari Singer (Ntru)

本ドラフトは、ロンドンmeeting後に公開されるとのこと。 このドラフトはPKIXにおける新しいアルゴリズムに対する扱い(OIDとASN.1 encodingの定義を含む)についての提案であり、SHA-2など新しいアルゴリズムの追加をdraft-ietf-pkix-ipki-pkalgs-++.txtにより可能にしようというものである。 今回は新しいアルゴリズムとしてNTRU公開鍵を提案している。

PKI Disaster Planning and Recovery/ Denis Pinkas(Integris)

End-user key, CA keyなどが解読されたり紛失した場合の災害復旧計画と復旧方法のフレームワークに関する提案である。ドラフトの記述内容としては、各種keyの説明、key解読時の対応、key紛失時の対応、key更新時の対応、key length の考え方などである。会場から、本提案は技術的課題かセキュリティポリシー課題かわからないとの意見があった。

DPD/DPV Requirements／ Steve Kent (BBN)

前回、ロンドンmeetingで提案をする予定であったが、進展がないとのこと。

DPV & DPD Protocols/ Denis Pinkas(Integris)

<draft-ietf-pkix-dpv-dpd-00.txt>
前回趣旨説明後、ドラフトが7月に提案された今回のプレゼンテーションはほぼ前回と同様であった。説明が追加された部分は以下の通り。

Validation time

Delegated Path Validation (DPV)において、証明書の有効性検証する時間の指定は、 現在の時間か過去のある時間が指定できる。過去の時間における有効性検証機能はオプションであり、その場合の検証は過去有効性検証を実施した検証データ(初期検証データ)を利用する。

Validation policy

Validation policyはCertificate requirements, Revocation requirements, Optional Time-Stamping requirementsからなり、OIDとhashで定義する。証明書検証プロトコルは、常にValidation policyを参照して、証明書が有効がどうかをチェックする。

Validation criteria

Validation criteriaは Delegated Path Discovery (DPD) にて証明書の有効パス検証を確認するルールで、一連の署名付証明書またはvalidation policyの指定により定義つけられる。その他プレゼンテーションでは、提案者はOCSP(RFC2560)は、失効証明書の情報のみ提供しているのでDPVにはなりえないと説明している。

ETSI Standards Update/John Ross (Security & Standards)

http://www.etsi.org/sec/el-sign.htm

ETSI Electronic Signature and Infrastructure Workingが作成した下記の４つのドラフトに対するコメントを求めている。：

Certificate Management Messages over CMS/Jim Schaad

< draft-ietf-pkix-rfc2797-bis-01.txt >
CMCのコア部分の更新ドラフト

CMC Transport
< draft-ietf-pkix-cmc-trans-00.txt >
HTTP, file, mail やTCPなどのCMCにおける通信記述部分.を記述したドラフト

CMC Extensions: Server Side Key Generation and Key Archival
<draft-ietf-pkix-cmc-archive-00.txt>
CMCの拡張サービスとしてServer generation of keys, and server-side archival and subsequent recovery of key material by the server を説明するドラフト

CMC Compliance Document
< draft-ietf-pkix-cmc-compl-00.txt>
CMCの実装に関するドラフトで実装暗号アルゴリズムについて記述してある。
encryption algorithmとしては, Triple-DESが MUSTである。Signaturesに関しては、DSAとRSA-SHA1の署名検証が可能で、DSA か RSA-SHA1 かのどちらかの署名作成が可能である。DH-POP Proof-of-Possession の実装がMUSTと定義してある。

S/MIME Mail Security WG (smime)

CHAIR: Russ Housley <rhousley@rsasecurity.com>

Working Group Status/Russ Housley

WG内の RFC は下記の 9つある。：

(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
(RFC 2785) Methods for Avoiding the 'Small-Subgroup' Attacks on the Diffie-Hellman Key Agreement Method for S/MIME
(RFC 2876) Use of the KEA and SKIPJACK Algorithms in CMS
(RFC 2984)Use of the CAST-128 Encryption Algorithm in S/MIME
(RFC 3058) Incorporation of IDEA encryption algorithm in S/MIME

現在RFC editor Queueのドラフトは次の通りである。：

Electronic Signature Formats for long term electronic signatures
<draft-ietf-smime-esformats-04.txt>
Electronic Signature Policies
<draft-ietf-smime-espolicies-01.txt>
Implementing Company Classification Policy with the S/MIME Security Label
<draft-ietf-smime-seclabel-04.txt>

Draft Standardの条件：

1) RFC2026に記述されている要件に合っていること
2) 安定、成熟かつ役に立つ仕様であること
3) 少なくとも２つ以上の独立した実装と異なるコードベースの相互接続性のある実装があること
4) Draft Standardは、Proposed Standard RFCsやExperimental RFCsを参照することはできない、したがってこれらのRFCsはPKIX証明書およびCRLプロファイル「Son-of-RFC2459」(I-D) (draft-ietf-pkix-new-part1-05.txt)がDraft Standardになるまで、Draft Standardになれない。

Interoperability Matrix/Jim Schaad

新しいドラフトを反映させた改訂版 RFC2630。署名データはほぼ 100%となった。

CMS
96 MUST Statements（５６％）
79 "Features"　 （４８％）
CMS Algorithm
46 MUST Statements（９３％）
15 Features 　　　（９３％）

その他のドラフト
RFC2631　　1/13
RFC2632　　16/21
RFC2633　　17/61
RFC2634　　27/81　（変更なし）

Examples of S/MIME Messages/Paul Hoffman

<draft-ietf-smime-examples-06.txt>

メーリングリストで議論しているが、数人しかドラフトをチェックしていなく、 WG で実装している人も少ないので、積極的にコメントをietf-smime-exampleのメーリ ン グリストに送って欲しいとコメントあり。

Updates to CMS/Russ Housley

<draft-ietf-smime-rfc2630bis-01.txt>

RFC2630 の改定版として作成したドラフトである。但し、暗号アルゴリズムに関する部分は、独立したドラフトとして作成した。

Cryptographic Message Syntax (CMS) Algorithms

<draft-ietf-smime-cmsalg-01.txt>
2つの課題について、当日 WGで意見交換された。

課題1ＣＭＳでの実装必須アルゴリズム

プロトコルではcmsalgで規定した必須のアルゴリズムの実装がMUSTとはしていない。
CMSプロトコルのドラフトとしては暗号アルゴリズム部分を別にしたほうがよい。
但しCMS関連ドラフトでは、個々に暗号アルゴリズムの特定をしなければいけない。
RFC2633では既に必要な記述がある。
本議論の後下記の選択投票を実施したところ、1:3の割合で2のCMSからMUSTと SHOULDの規定を削除する意見が多かった。

投票：
１．アルゴリズムに関するMUSTとSHOULDの規定を残す
２．アルゴリズムに関するMUSTとSHOULDの規定を削除する

課題２　EnvelopedData の処理

現行のVersionのつけ方は以下の通り
IF (( originatorInfo is present) AND (any version 2 attributeCert are present)) OR
( any RecipientInfo structure include pweri) OR
( any RecipientInfo structure include ori)
THEN version is 3
　ELSE
IF ((originatorInfo is present) OR
(unprotectedAttres is present) OR
(any RecipientInfo structure are a version other than 0)
THEN version is 2
　 ELSE version is 0

現在のVersionのメカニズムを残すか、下位コンポーネントを考慮したバージョン管理
をおこなうかで投票したが、会場で挙手する人がすくなく、Versionのメカニズムにあ
まりこだわらないという選択を追加して投票した結果、こだわらいに最も多く賛成が
集まった。

Updates to CERT and MSG/ Blake Ramsdell

MSG
RFC2633 RFC2633bis
署名Receiver MUST DSA MUST DSA and RSA
Sender SHOULD RSA MUST DSA or RSA
KEK MUST DH MAY DH
SHOULD RSA MUST RSA
暗号化 INDIVIDUAL ALL SPECS CMSALG
ＣＭＳ
ＣＭＳ RFC2632 RFC2632bis
署名 MUST DSA MUST ＤＳＡ
SHOULD md2/md5/　 MUST sha1 with RSA
暗号化 INDIVIDUAL ALL SPECS CMSALG
会場から、MUST/SHOULDは、技術的理由というよりビジネス的理由ではないかと意見あり。

Symmetric Key Distribution / Sean Turner

ドラフト名(CMS Symmetric Key Distribution)の他一部変更した。以下の修正により、WG Last Callの予定:

コメントへの対応：修正点
　　　　　　８章から１．３章へ
　　　　　　３．１章
　　　　　　Restricted Attribute Certificateを２章
　　　　　　SKDAlgRequest syntax NULLにした。
　　　　　　SignedData
　　　　　　第４章
　　　　　　symmetric Key GenについてＣＭＳから文章をコピー
　　　　　　Security Considerationを内容追加
　　　　　　名前変更

X.400 and CMS / Chris Bonatti

X.400 Wrapping

CMSでX.400を守る方法を指定しているドラフトである。
RFC2633bisと同じようにコメントに対応
3.2章から3.4章でContentInfoについて
3.2.1、3.3.1、3.4.1を訂正。smime type Parameter Value修正。

X.400 Transport

CMSオブジェクトをX.400のMTAが配送するためにパッケージ化する方法について記述しているドラフトである。
X.400IPMSメッセージでのフォワーディングについて修正および明確化を行った。
2.5章でEITのOID値をアサインした。EITとはsmime type parameterに相当する。

AES and RSA-OAEP in CMS/ Jim Schaad

変更点：
削除：AuthenticatedDataセクション
追加：AES overview
追加：place holder examples - need OIDs
追加：AES EncryptedData セクション

作業中の項目：
Key Wrap Algorithmを得る
AES Key wrap examplesを完成させる。
付録にASN.1を追加する
Password recipient info
その他のアルゴリズム
PSS　　−標準化の進展はない
SHA-2　−ＲＳＡまたはＮＩＳＴからＯＩＤｓのリリースはない。
ＤＳＡの鍵サイズは、２５６？

Elliptic Curve Cryptography (ECC)/ Simon Blake-Wilson

実装が3つ以上、接続テストが必要である。ラストコール？

S/MIME Gateway Protocol/ Blake Ramsdell

draft-ramsdell-enc-smime-gateway.txt
S/MIMEゲートウェイ・プロトコルのドラフトについて説明した。マサチューセッツ・ヘルス・データ・コンソーシアムを中心に相互接続試験を実施している。ヘルスケアのHIPPAがこの活動をサポートしている。

　　　　　サーバー参加者　　　S/MIMEベンダー
　　　　　Tumbleweed　　　　　Baltimore
　　　　　DICA　　　　　　　　TENFOUR SYSTEM
　　　　　VAN GUARD　　　　　VIASEC（RIP）

今後これをWGとして進めるか、別々に議論するか？
当日の意見としてはこのドラフトは、S/MIMEにとって非常に重要であるのでみなさんもぜひ読んで議論に参加して欲しい。（Paul Hoffman）キーマネジメントは本ドラフトのout of scopeである。SMTP over TLSやMan-in-Middleアタックについて質問があった。

NIST to accelerate deployment of S/MIME　-Michael Chernick

NIST が計画しているS/MIMEのインターオペラビリティ活動について Chernick (NIST)がプレゼンテーションを行った。IETFのS/MIME　WGの活動をベースにした Client Profile の作成とS/MIMEの自動テストツールをインターネット上に開発するというもので、現在コメント受付中で、コメント期限は 9月17日延期された。詳細はプレゼン資料と下記 web を参照いただきたい。

プレゼン資料(NIST)
　　　　テスト・ファシリティ
　　　　http://csrc.nist.gov/pki/smime/
　　　　ドラフト
　　　　http://csrc.nist.gov/pki/smime/draft-SMIMEprofile.pdf

ETSI activity/Denis Pinkas

http://www.etsi.org/sec/el-sign.htm
3つのドラフトについてコメント受付中(PKIXの同様の内容)：

1.XML Advanced Electronic Signature
2.Policy Requirement for time stamping Authentication
3.Polocy Requirement for CAs

１．について

Electronic Signatureフォーマットしようとして、XMLについて同じ機能を用意するCMSを使用、XMLDigSig を替わりに使う。同様に SignedDataObjectPropertiesを使う。xmlElSign として見える。W3Cで議論されたもの。

２．について

高品質のSignatureとして
１）ベースラインのポリシー
２）TSAとしての名前の決め方
３）有効期限を過ぎたタイムスタンプの検証

３．について

ＱＣ発行のためのポリシー要件について記述している。
e-Sign　コストとセキュリティレベルによって異なるレベルを持たせる。

S/MIME Freeware Library (SFL)

ジョン・ポーリングは、夏季休暇のため、替わりに同僚が発表した。前回と同様のフリーウェア・ライブラリーの説明があった。

Transport Layer Security WG (TLS)

RFC 2246

1999年に、Proposed Standard としてpublishされた TLS Protocol Version 1.0 (RFC 2246) を Draft Standard として IESG に提出することが現在のWG の最優先目的となっている。(当初2001年6月予定だったので、遅れ気味) Rric Rescorla が RFC 2246 の Authorの Tim Dierks(Certicom)と協力して編集を行なうのでコメントがあれば送ること。課題としては

などがあるが、会議では結論出ず。

TLS Extensions
/ Simon Blake-Wilson(Certicom), Magnus Nystrom(RSA Security), David Hopwood(Independent Consultant), Jan Mikkelsen(Transactionware), Tim Wright(Vodafone)

TLS Delegation Protocol / K. Jackson(LBNL), S. Tuecke, D. Engert(ANL)

Using SRP for TLS Authentication / D. Taylor(Forge Research Pty Ltd)

TLS CipherSuites

AES Ciphersuites for TLS

 AES Ciphersuitesで RSA-OAEPをサポートするかどうか

MLで議論が行なわれてきたが、ロンドン会議で改めて、挙手による投票が行なわれ、現時点ではRSA-OAEPをサポートしない

AES ciphersuites のみを Proposed Standardに進めることになった.

IANAがciphersuite番号の割当を行なうべきかどうかについて

活発に議論が行なわれ、Chairの Win Treese がIANAと相談することになった。また、patented algorithmを含むciphersuitesにRFCを与えるかについても議論になった。Chairが今後のciphersuite提案について以下の2つの提案を行なった。

1. 今後 export-gradeのciphersuiteはWG draftとして受け付けない.
2. 今後 ciphersuiteを提案する時は、experimental rangeから
テンポラリのciphersuite識別番号を指定することにする.(識別番号の衝突を防ぐため)

その他のciphersuite

ECC Cipher Suites For TLS

継続してMLでの議論が必要.

56-bit Export Cipher Suites For TLS

WGからInformational RFCとしてsubmitされることに決定.

Extensions to TLS for OpenPGP keys

継続してMLでの議論が必要.

Addition of MISTY1 to TLS

MLで議論中のため特にactionはなし.(Pending)

Addition of the Camellia Encryption Algorithm to TLS

WGからInformational RFCとしてsubmitされることに決定.

Kerberos Cipher Suites in Transport Layer Security (TLS)

Authour が欠席のため議論はMLで行なう.

NTRU Cipher Suites for TLS

継続してMLでの議論が必要.

以上

Copyright © 2001 Information-technology Promotion Agency, Japan. All rights reserved.