ipa_isec_logo.gif (2411 バイト)

最終更新日:2001年 7月 2日


50th IETF ミーティング(ミネアポリス)

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

情報処理振興事業協会
セキュリティセンター

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



出張期間    平成13年 3月18日〜 3月25日(8日間)
開催場所    アメリカ ミネアポリス

概要

PKIおよび暗号実装技術の動向調査を目的にIETFのSecurity Areaの WG を中心に参加した。
今回のミーティングはアメリカのミネアポリスで開催され、2233名(登録ベース)のの参加があり、国別内訳としてはアメリカ63%、日本8%、以下カナダ4%、フランス、ドイツ、イギリス、スウェーデン、フィンランド3%韓国2%であった。
日本からは、日本インターネット協会や電子総合研究所など約170名(8%)の参加があった。
今回のミィーテングにてIETFの議長がFred BakerからHerald Alvestrend(ノルウェイ)に代わった。
Security Area のWorking Groupとしては、Public-Key Infrastructure X.509) (pkix)、S/MIME Mail Security (smime)、Securely Available Credentials (sacred)など15の WG と BOF が開催され、Transport Layer Security (tls)とXML Digital Signatures (xmldsig)Directorate Meeting)のWGは開催されなかった。
暗号実装関連のトピックスとして、S/MIME -WGにて、前回のサンディエゴでのミーティングでの意見(挙手)を踏まえ、S/MIME実装暗号技術として、署名方式はDSAと RSA(PKCS#1v1.5)、ハッシュ関数はSHA-1、鍵管理はRSA(PKCS#1v1.5)、暗号方式は Triple-DESとする方向となった。
(署名方式はDSAとRSAの2方式があるが、2方式の実装を必須とするのでなく、署名付与はどちらか一方の方式で可能で、署名検証方式として 2方式をサポートするのが当日会場の大多数の意見であった。)
2002年 7月には、第54回 IETFミーティングの日本(横浜市)開催もあり、引き続き動向に注目していきたい。

Open Plenary

3月21日午後7時30分からの開催された総会にて、IETF Chair がFred Bakerから Herald Alvestrend にバトンタッチされた。
歴代のIETF Chair:

Mike Corrigan(1987)
Phill Gross(1987-1993)
Paul Mockapetris(1994-1995)
Fred Baker(1995-2001)
Herald Alvestrend (2001-)

Security Area

Open Security Area Directorate Meeting(saag)/Jeffrey I. Schiller(MIT)
今回開催のWG/BOFは次の通り(開催順)
MSEC - Multicast Security WG F
IPSEC - IP Security Protocol
SECSH
IPSP - IP Security Policy WG
IPSRA - IP Security Remote Access WG
KRB - Kerberos WG
PKIX - Public-Key Infrastructure (X.509) WG
OPENPGP- An Open Specification for Pretty Good Privacy WG
STIME- Secure Network Time Protocol WG
HIP- Host Identity Payload BOF
IDWG - Intrusion Detection Exchange Format WG
KINK - Kerberized Internet Negotiation of Keys WG
SMIME - S/MIME Mail Security WG
SACRED - Securely Available Credentials WG

Transport Layer Security WGとXML Digital Signatures WG は、開催されなかった。

 

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

前回のミーティング以降のRFC

IESGでレビューを受けているID(インターネットドラフト)

今回のミーティングでは、新しいドラフトであるImpersonation Certificates や Group Name のほかSon of 2459、OCSP、DPD/DPVなどに について検討された。
特に中心議題はDPD/DPVであった。

Son of 2459 /Russ Housley (SPYRUS)

証明書・失効情報のプロファイルのドラフト
dradraft-ietf-pkix-new-part1-05.txt
ISO&ITU−T(X.509 の検討グループ)とPKIXのname constraintsの調整は、PKIX仕様のままで解決。
また、懸案事項だったpath length constraintsとissue CRLsが解決し、WG Last Callとなった。
path length constraintsが0の場合でも証明書を有効する。
non - CAはCRLsを発行できない。
CA 証明書ではkeyCertSignか cRLSign のbitsオンが必須である。

公開鍵・署名のアルゴリズムのドラフトは特に変更なくWG Last Callとなった。
draft-ietf-pkix-ipki-pkalgs-02.txt

RFC2560(OCSP) /A. Malpani (ValiCert)

Draft Standardに向けての状況説明。
相互接続テストはPKI Forumを中心に順調に進んでいる。
主な仕様確定内容としては、certificate status value(good、revoked、unknown)、Computation of issuerKeyHash、signatures DER、Mandatory Cryptographic Algorithms(DSAからRSAに変更する)などである。

Impersonation Certificates / Steve Tuecke (Argonne National Labs)

このドラフトは今回新しく提案されたもので、冒頭提案者がproxy certificatesと訂正。
single signon とdelegationの考え方を導入。
Proxy CertificateとはEnd Entity Certificateまたは他の Proxy Certificateに署名されたものをいう。
KeyusageやBasicConstraintでRFCとの整合性を図っているが、証明書パス検証時には問題があるとの意見がある。
TLS Delegation Protocol(draft-ietf-tls-delegation-00.txt) に作成方法を記述。
本ドラフトと同様な実装例としては、GSI(Globus Toolkits Grid Security Infrastructure)があり、100以上のサイトで導入されているとのこと。
GSI-API+X.509+PC+SSL+delegation
http://www.gridforum.org/security/gsi

Group Name/Mike StJohns (Rainmaker Technolgies)

証明書のマッピング作業を不要にする簡単なネーミングをotherName extension of the GeneralName typeとして提案。
Attribute certificatesでも利用できそうである。
定義
UserGroupName ::= SEQUENCE {
domain UTF8String,
user UTF8String,
groups SEQUENCE OF UTF8String OPTIONAL
}

SCVP /A. Malpani(ValiCert)

今回RFC3029となった。 Category: Experimental
変更点としては、実装されていないXML syntaxを削除し、CMSのプロトコル をベースとしたことである。

Policy Requirements for TSAs /Denis Pinkas (Bull)

ETSIの活動概要と新しい work itemの説明があった。

発行済みETSI標準:
TS 101 733  Electronic signature formats and Signature Policies
TS 101 862  Qualified certificate Profile
TS 101 456  Policy Requirements for CAs issuing qualified certificates

検討中ETSI標準:
TS 101 861 Time Stamping Profile

2001年の5つの新しいワークアイテム。:
1 Security management and policy requirements for CPSs issuing stamps
2 Policy Requirements for CAs issuing qualified certificates other than Qualified certificates
3 Electronic signature and encoding formats in XML
4 Technical aspects of signature policies
5 Provision of harmonised TPS status information

Policy Requirements for TSAsは、RFC2527およびTS 101 456に関連したものであり、PKIXと S/MIMEからのコメントを期待している。

ETSI-ESI WG のホームページ 
http://www.etsi.org/sec/el-sign.htm

DPD/DPV Requirements/ Steve Kent (BBN)

説明のポイントは以下の通り
SMIME ESPやOCSP nonceの対応
Policy OID plus hash,Helper Cert,Helper CRLs,Helper OCSPの記述
Singnatureの対応 optional(DPD),mandatory(DPV)
ValidationTimeの記述 optional(DPV)
今後、DPD/DPV の要件の対応と実現性を考慮して、次回8月のIETFミーティングの前 には、プロトコルの選定を行いと提案者は説明していた。

OCSPv2/ Michael Myers (VeriSign)

draft-ietf-pkix-ocspv2-02.txt
このドラフトは、OCSPでDPD & DPVを実現する仕様を記述したもので、大きく以下の構成になっている。
Protocol Overview
General Framework
Signed Requests /Response Envelope
Service Definitions
Online Revocation Status(ORS)
Delegated Path Validation (DPV)
Delegated Path Discovery (DPD)
Extensions
Nonce/ CRL References

主な考慮点は以下の通り
Nonce Relay リプレイ攻撃の対応
Reuse of BasicOCSPResponce Syntax
 ORSとDPVのCertStatusとの連動
ORSCertStatus ::= CHOICE {
good [0] IMPLICIT NULL,
revoked [1] IMPLICIT RevokedInfo,
unknown [2] IMPLICIT UnknownInfo }
DPVCertStatus ::= CHOICE {
valid [0] IMPLICIT NULL,
invalid [1] IMPLICIT NULL,
unknown [2] IMPLICIT NULL }

DPD/DPV / Denis Pinkas (Bull)

Denis PinkasがDPV とDPDの提案プレゼンテーションを行った。
(1) DPVの目的
目的は証明書の有効性について、有効"valid", 失効"invalid",不完全"incomplete"の
回答を署名付きですること。
場合によっては、有効の証拠も必要である。

(2) DPV必須要求データ:
検証する証明書情報(証明書またはESSCertID)
フラグ(証拠データの必要有無)

(3) DPV必須応答データ:
下記のデータの署名付き応答が必須である
- a status : valid, invalid, incomplete.
- the reference of the certificate being validated or the certificate itself.
- the date of validation,
- the reference of the validation policy that has been used during the
validation process or its description,
- optionally, the hash of the evidence.

(1) DPDの目的
証明書のパスを得ること。(必要に応じて関連した失効情報も)
オペレーションの状態としては、成功"success"か失敗 "failure"を返す。

(2) DPD必須要求データ
検証する証明書情報(証明書またはESSCertID)
フラグ(ESSCertIDで要求した場合は、応答として証明書が必要どうか)
フラグ(失効情報が必要かどうか、失効情報の要求は、CRLs (baseCRL/deltaCRL)と
OCSPの組み合わせで4パターン有り)
A nonce (to detect replays).

(3) DPD必須応答データ
処理完了スタータス"success"か"failure"
DPD応答データ
full path found / not found.
full revocation information found / not found.
leaf certificate found /not found.
reference of the certificate being validated or the certificate itself.
A nonce (no retry facility).

以上