RFC3820 日本語訳
3820 Internet X.509 Public Key Infrastructure (PKI) Proxy CertificateProfile. S. Tuecke, V. Welch, D. Engert, L. Pearlman, M. Thompson. June 2004. (Format: TXT=86374 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Tuecke
Request for Comments: 3820 ANL
Category: Standards Track V. Welch
NCSA
D. Engert
ANL
L. Pearlman
USC/ISI
M. Thompson
LBNL
June 2004
Tueckeがコメントのために要求するワーキンググループS.をネットワークでつないでください: 3820年のANLカテゴリ: 標準化過程V.ウェルチNCSA D.Engert ANL L.パールマンUSC/ISI M.トンプソンLBNL2004年6月
Internet X.509 Public Key Infrastructure (PKI)
Proxy Certificate Profile
インターネットX.509公開鍵暗号基盤(PKI)プロキシ証明書プロフィール
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This document forms a certificate profile for Proxy Certificates, based on X.509 Public Key Infrastructure (PKI) certificates as defined in RFC 3280, for use in the Internet. The term Proxy Certificate is used to describe a certificate that is derived from, and signed by, a normal X.509 Public Key End Entity Certificate or by another Proxy Certificate for the purpose of providing restricted proxying and delegation within a PKI based authentication system.
このドキュメントはProxy Certificatesのための証明書プロフィールを形成します、RFC3280で定義されるX.509公開鍵暗号基盤(PKI)証明書に基づいて、インターネットでの使用のために。 存在という用語Proxy Certificateごとに、PKIのベースの認証システムの中でproxyingと委譲を制限しました。
Tuecke, et al. Standards Track [Page 1] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke、他 規格はX.509プロキシ証明書プロフィール2004年6月にRFC3820を追跡します[1ページ]。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of Approach . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Background . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Motivation for Proxying. . . . . . . . . . . . . . . . . 5
2.4. Motivation for Restricted Proxies. . . . . . . . . . . . 7
2.5. Motivation for Unique Proxy Name . . . . . . . . . . . . 8
2.6. Description Of Approach. . . . . . . . . . . . . . . . . 9
2.7. Features Of This Approach. . . . . . . . . . . . . . . . 10
3. Certificate and Certificate Extensions Profile . . . . . . . . 12
3.1. Issuer . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2. Issuer Alternative Name. . . . . . . . . . . . . . . . . 12
3.3. Serial Number. . . . . . . . . . . . . . . . . . . . . . 12
3.4. Subject. . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5. Subject Alternative Name . . . . . . . . . . . . . . . . 13
3.6. Key Usage and Extended Key Usage . . . . . . . . . . . . 13
3.7. Basic Constraints. . . . . . . . . . . . . . . . . . . . 14
3.8. The ProxyCertInfo Extension. . . . . . . . . . . . . . . 14
4. Proxy Certificate Path Validation. . . . . . . . . . . . . . . 17
4.1. Basic Proxy Certificate Path Validation. . . . . . . . . 19
4.2. Using the Path Validation Algorithm. . . . . . . . . . . 23
5. Commentary . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Relationship to Attribute Certificates . . . . . . . . . 24
5.2. Kerberos 5 Tickets . . . . . . . . . . . . . . . . . . . 28
5.3. Examples of usage of Proxy Restrictions. . . . . . . . . 28
5.4. Delegation Tracing . . . . . . . . . . . . . . . . . . . 29
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 30
6.1. Compromise of a Proxy Certificate. . . . . . . . . . . . 30
6.2. Restricting Proxy Certificates . . . . . . . . . . . . . 31
6.3. Relying Party Trust of Proxy Certificates. . . . . . . . 31
6.4. Protecting Against Denial of Service with Key Generation 32
6.5. Use of Proxy Certificates in a Central Repository. . . . 32
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 33
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. Normative References . . . . . . . . . . . . . . . . . . 33
8.2. Informative References . . . . . . . . . . . . . . . . . 33
9. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 34
Appendix A. 1988 ASN.1 Module. . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Full Copyright Notice. . . . . . . . . . . . . . . . . . . . . . . 37
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 アプローチ. . . . . . . . . . . . . . . . . . . . . 4 2.1の概要。 用語。 . . . . . . . . . . . . . . . . . . . . . . 4 2.2. バックグラウンド. . . . . . . . . . . . . . . . . . . . . . . 5 2.3。 Proxyingに関する動機。 . . . . . . . . . . . . . . . . 5 2.4. 制限されたプロキシに関する動機。 . . . . . . . . . . . 7 2.5. ユニークなプロキシ名. . . . . . . . . . . . 8 2.6に関する動機。 アプローチの記述。 . . . . . . . . . . . . . . . . 9 2.7. この特徴にアプローチします。 . . . . . . . . . . . . . . . 10 3. 証明書と証明書拡張子は.123.1の輪郭を描きます。 発行人. . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2。 発行人代替名。 . . . . . . . . . . . . . . . . 12 3.3. 通し番号。 . . . . . . . . . . . . . . . . . . . . . 12 3.4. 受けることがある。 . . . . . . . . . . . . . . . . . . . . . . . . 13 3.5. 対象の代替名. . . . . . . . . . . . . . . . 13 3.6。 主要な用法と拡張主要な用法. . . . . . . . . . . . 13 3.7。 基本的な規制。 . . . . . . . . . . . . . . . . . . . 14 3.8. ProxyCertInfo拡張子。 . . . . . . . . . . . . . . 14 4. プロキシ証明書経路合法化。 . . . . . . . . . . . . . . 17 4.1. 基本的なプロキシ証明書経路合法化。 . . . . . . . . 19 4.2. 経路合法化アルゴリズムを使用します。 . . . . . . . . . . 23 5. 論評. . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.1。 証明書. . . . . . . . . 24 5.2を結果と考える関係。 ケルベロス5チケット. . . . . . . . . . . . . . . . . . . 28 5.3。 Proxy Restrictionsの使用法に関する例。 . . . . . . . . 28 5.4. 委譲のたど. . . . . . . . . . . . . . . . . . . 29 6ること。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 30 6.1. プロキシ証明書の感染。 . . . . . . . . . . . 30 6.2. プロキシ証明書. . . . . . . . . . . . . 31 6.3を制限します。 パーティが信じるプロキシ証明書の信用。 . . . . . . . 31 6.4. キー生成32 6.5でサービス妨害から守ります。 中央倉庫でのプロキシ証明書の使用。 . . . 32 7. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 33 8. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 33 8.1。 引用規格. . . . . . . . . . . . . . . . . . 33 8.2。 有益な参照. . . . . . . . . . . . . . . . . 33 9。 承認。 . . . . . . . . . . . . . . . . . . . . . . . 34 付録A.1988ASN.1モジュール。 . . . . . . . . . . . . . . . . . . 作者の35のものが.36の完全な版権情報を扱います。 . . . . . . . . . . . . . . . . . . . . . . 37
Tuecke, et al. Standards Track [Page 2] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke、他 規格はX.509プロキシ証明書プロフィール2004年6月にRFC3820を追跡します[2ページ]。
1. Introduction
1. 序論
Use of a proxy credential [i7] is a common technique used in security systems to allow entity A to grant to another entity B the right for B to be authorized with others as if it were A. In other words, entity B is acting as a proxy on behalf of entity A. This document forms a certificate profile for Proxy Certificates, based on the RFC 3280, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile" [n2].
プロキシ資格証明書[i7]の使用が実体AがBが他のものと共にまるでそれがA.In他の単語であるかのように認可される権利を別の実体Bに与えるのを許容するのにセキュリティシステムで使用される、一般的なテクニックである、Thisが記録する実体A.を代表したプロキシがProxy Certificatesのための証明書プロフィールを形成するとき、実体Bは行動しています、RFC3280に基づいて、「インターネットX.509公開鍵暗号基盤証明書とCRLプロフィール」[n2。]
In addition to simple, unrestricted proxying, this profile defines:
簡単で、無制限なproxyingに加えて、このプロフィールは以下を定義します。
* A framework for carrying policies in Proxy Certificates that
allows proxying to be limited (perhaps completely disallowed)
through either restrictions or enumeration of rights.
* proxyingが権利の制限か列挙のどちらかで限られているのを(恐らく完全に禁じられた)許容するProxy Certificatesの携帯方針のためのフレームワーク。
* Proxy Certificates with unique names, derived from the name of the
end entity certificate name. This allows the Proxy Certificates
to be used in conjunction with attribute assertion approaches such
as Attribute Certificates [i3] and have their own rights
independent of their issuer.
* 終わりの実体証明書名の名前から得られたユニークな名前があるプロキシCertificates。 これで、Proxy CertificatesはAttribute Certificates[i3]などの属性主張アプローチに関連して使用されて、それらの発行人の如何にかかわらずそれら自身の権利を持っています。
Section 2 provides a non-normative overview of the approach. It begins by defining terminology, motivating Proxy Certificates, and giving a brief overview of the approach. It then introduces the notion of a Proxy Issuer, as distinct from a Certificate Authority, to describe how end entity signing of a Proxy Certificate is different from end entity signing of another end entity certificate, and therefore why this approach does not violate the end entity signing restrictions contained in the X.509 keyCertSign field of the keyUsage extension. It then continues with discussions of how subject names are used by this proxying approach, and features of this approach.
セクション2はアプローチの非標準の概要を提供します。 Proxy Certificatesを動機づけて、アプローチの簡潔な概要を与えて、それは、用語を定義することによって、始まります。 そして、それは、Proxy Certificateの終わりの実体署名が別の終わりの実体証明書の終わりの実体署名とどのように異なっているか、そして、したがって、このアプローチがなぜkeyUsage拡張子のX.509 keyCertSign分野に保管されていた終わりの実体署名制限に違反しないかを説明するためにCertificate Authorityと異なるとしてProxy Issuerの概念を紹介します。 そして、それは対象の名前がアプローチをproxyingしながらこれによってどう使用されるかに関する議論、およびこのアプローチの特徴を続行します。
Section 3 defines requirements on information content in Proxy Certificates. This profile addresses two fields in the basic certificate as well as five certificate extensions. The certificate fields are the subject and issuer fields. The certificate extensions are subject alternative name, issuer alternative name, key usage, basic constraints, and extended key usage. A new certificate extension, Proxy Certificate Information, is introduced.
セクション3はProxy Certificatesの情報量に関する要件を定義します。 このプロフィールは5つの証明書拡張子と同様に基本の証明書の2つの分野を扱います。 証明書分野は、対象と発行人分野です。 証明書拡張子は、対象の代替名と、発行人代替名と、主要な用法と、基本的な規制と、拡張主要な用法です。 新しい証明書拡張子(Proxy Certificate情報)は紹介されます。
Section 4 defines path validation rules for Proxy Certificates.
セクション4はProxy Certificatesのために経路合法化規則を定義します。
Section 5 provides non-normative commentary on Proxy Certificates.
セクション5はProxy Certificatesの非標準の論評を提供します。
Section 6 discusses security considerations relating to Proxy Certificates.
セクション6はProxy Certificatesに関連するセキュリティ問題について論じます。
Tuecke, et al. Standards Track [Page 3] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke、他 規格はX.509プロキシ証明書プロフィール2004年6月にRFC3820を追跡します[3ページ]。
References, listed in Section 8, are sorted into normative and information references. Normative references, listed in Section 8.1, are in the form [nXX]. Informative references, listed in Section 8.2, are in the form [iXX].
セクション8にリストアップされた参照は標準と情報参照に分類されます。 セクション8.1にリストアップされた引用規格がフォーム[nXX]にあります。 セクション8.2にリストアップされた有益な参照がフォーム[iXX]にあります。
Section 9 contains acknowledgements.
セクション9は承認を含みます。
Following Section 9, contains the Appendix, the contact information for the authors, the intellectual property information, and the copyright information for this document.
次のセクション9 Appendix、作者への問い合わせ先、知的所有権情報、およびこのドキュメントのための著作権情報を含んでいます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [n1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[n1]で説明されるように本書では解釈されることであるべきです。
2. Overview of Approach
2. アプローチの概要
This section provides non-normative commentary on Proxy Certificates.
このセクションはProxy Certificatesの非標準の論評を提供します。
The goal of this specification is to develop a X.509 Proxy Certificate profile and to facilitate their use within Internet applications for those communities wishing to make use of restricted proxying and delegation within an X.509 Public Key Infrastructure (PKI) authentication based system.
この仕様の目標がX.509 Proxy Certificateプロフィールを開発して、制限されたproxyingを利用したがっているそれらの共同体のインターネットアプリケーションの中で彼らの使用を容易にすることであり、X.509公開鍵暗号基盤(PKI)認証の中の委譲はシステムを基礎づけました。
This section provides relevant background, motivation, an overview of the approach, and related work.
このセクションはアプローチであって、関連する仕事の概要を関連バックグラウンド、動機に提供します。
2.1. Terminology
2.1. 用語
This document uses the following terms:
このドキュメントは次の用語を使用します:
* CA: A "Certification Authority", as defined by X.509 [n2]
* カリフォルニア: 「認証局」X.509によって定義されて、[n2]
* EEC: An "End Entity Certificate", as defined by X.509. That is,
it is an X.509 Public Key Certificate issued to an end entity,
such as a user or a service, by a CA.
* EEC: X.509によって定義されるように「終わりの実体証明書。」 すなわち、それはカリフォルニアによってユーザかサービスなどの終わりの実体に発行されたX.509 Public Key Certificateです。
* PKC: An end entity "Public Key Certificate". This is synonymous
with an EEC.
* PKC: 終わりの実体「公開鍵証明書。」 これはEECと同義です。
* PC: A "Proxy Certificate", the profile of which is defined by this
document.
* PC: 「プロキシ証明書。」それのプロフィールはこのドキュメントによって定義されます。
Tuecke, et al. Standards Track [Page 4] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke、他 規格はX.509プロキシ証明書プロフィール2004年6月にRFC3820を追跡します[4ページ]。
* PI: A "Proxy Issuer" is an entity with an End Entity Certificate
or Proxy Certificate that issues a Proxy Certificate. The Proxy
Certificate is signed using the private key associated with the
public key in the Proxy Issuer's certificate.
* パイ: 「プロキシ発行人」はProxy Certificateを発行するEnd Entity CertificateかProxy Certificateがある実体です。 Proxy Issuerの証明書で公開鍵に関連している秘密鍵を使用することでProxy Certificateは署名されます。
* AC: An "Attribute Certificate", as defined by "An Internet
Attribute Certificate Profile for Authorization" [i3].
* 西暦: 「承認のためのインターネット属性証明書プロフィール」[i3]によって定義されるように「属性証明書。」
* AA: An "Attribute Authority", as defined in [i3].
* AA: [i3]で定義されるように「属性権威。」
2.2. Background
2.2. バックグラウンド
Computational and Data "Grids" have emerged as a common approach to constructing dynamic, inter-domain, distributed computing environments. As explained in [i5], large research and development efforts starting around 1995 have focused on the question of what protocols, services, and APIs are required for effective, coordinated use of resources in these Grid environments.
コンピュータとData「グリッド」はダイナミックな相互ドメイン、分散コンピューティング環境を構成することへの一般的なアプローチとして現れました。 [i5]で説明されるように、1995年頃に始まる大きい研究開発取り組みはどんなプロトコル、サービス、およびAPIがこれらのGrid環境におけるリソースの有効で、連携している使用に必要であるかに関する質問に焦点を合わせました。
In 1997, the Globus Project (www.globus.org) introduced the Grid Security Infrastructure (GSI) [i4]. This library provides for public key based authentication and message protection, based on standard X.509 certificates and public key infrastructure, the SSL/TLS protocol [i2], and delegation using proxy certificates similar to those profiled in this document. GSI has been used, in turn, to build numerous middleware libraries and applications, which have been deployed in large-scale production and experimental Grids [i1]. GSI has emerged as the dominant security solution used by Grid efforts worldwide.
1997年に、グローバスProject(www.globus.org)はGrid Security Infrastructure(GSI)[i4]を導入しました。 このライブラリは、本書では輪郭を描かれたものと同様のプロキシ証明書を使用することでベースの認証、標準のX.509証明書と公開鍵認証基盤に基づいたメッセージ保護、SSL/TLSプロトコル[i2]、および委譲を公開鍵に提供します。 GSIは、多数のミドルウェアライブラリとアプリケーションを建設するのに順番に使用されました。(アプリケーションは大量生産と実験的なGrids[i1]で配布されました)。 GSIは世界中のGrid取り組みによって使用される優位なセキュリティソリューションとして現れました。
This experience with GSI has proven the viability of restricted proxying as a basis for authorization within Grids, and has further proven the viability of using X.509 Proxy Certificates, as defined in this document, as the basis for that proxying. This document is one part of an effort to migrate this experience with GSI into standards, and in the process clean up the approach and better reconcile it with existing and recent standards.
GSIのこの経験は、Gridsの中に承認の基礎としての制限されたproxyingの立証された生存力を持って、さらにX.509 Proxy Certificatesを使用する生存力を立証しました、本書では定義されるように、そのproxyingの基礎として。 このドキュメントは規格へのGSIと共にこの経験を移行させて、プロセスが掃除するコネをアプローチに移行させて、存在と最近の規格とそれをより仲直りさせる取り組みの一部です。
2.3. Motivation for Proxying
2.3. Proxyingに関する動機
A motivating example will assist in understanding the role proxying can play in building Internet based applications.
動機づけている例は、役割のproxyingがビルインターネットでベースのアプリケーションを使うことができるのを理解しているのを助けるでしょう。
Steve is an engineer who wants to use a reliable file transfer service to manage the movement of a number of large files around between various hosts on his company's Intranet-based Grid. From his laptop he wants to submit a number of transfer requests to the service and have the files transferred while he is doing other
スティーブは彼の会社のイントラネットベースのGridで様々なホストの間の多くの大きいおよそファイルの動きを管理するのに信頼できるファイル転送サービスを利用したがっている技術者です。 彼のラップトップから、多くの転送要求をサービスに提出して、彼は他に彼がしている間に移されたファイルが欲しいです。
Tuecke, et al. Standards Track [Page 5] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke、他 規格はX.509プロキシ証明書プロフィール2004年6月にRFC3820を追跡します[5ページ]。
things, including being offline. The transfer service may queue the requests for some time (e.g., until after hours or a period of low resource usage) before initiating the transfers. The transfer service will then, for each file, connect to each of the source and destination hosts, and instruct them to initiate a data connection directly from the source to the destination in order to transfer the file. Steve will leave an agent running on his laptop that will periodically check on progress of the transfer by contacting the transfer service. Of course, he wants all of this to happen securely on his company's resources, which requires that he initiate all of this using his PKI smartcard.
オフラインであることを含むもの。 転送を起こす前に、転送サービスはしばらく(例えば、低いリソース用法の何時間もの期間の後まで)要求を列に並ばせるかもしれません。 転送サービスは、ファイルを移すために次に、各ファイルのためにソースとあて先ホストの各人に接して、データ接続を開始するよう彼らに直接ソースから目的地まで命令するでしょう。 スティーブは、エージェントが転送サービスに連絡することによって転送の進歩について定期的に検査する彼のラップトップで動いているままにするでしょう。 もちろん、彼はこのすべてが彼の会社のリソースでしっかりと起こって欲しいです(彼が彼のPKIスマートカードを使用することでこのすべてを開始するのを必要とします)。
This scenario requires authentication and delegation in a variety of places:
このシナリオはさまざまな場所で認証と委譲を必要とします:
* Steve needs to be able to mutually authenticate with the reliable
file transfer service to submit the transfer request.
* 互いにできるスティーブの必要性は信頼できることで転送要求を提出するファイル転送サービスを認証します。
* Since the storage hosts know nothing about the file transfer
service, the file transfer service needs to be delegated the
rights to mutually authenticate with the various storage hosts
involved directly in the file transfer, in order to initiate the
file transfer.
* 以来、ストレージホストはファイル転送サービス(権利がファイル転送を開始するために直接ファイル転送にかかわる様々なストレージホストと共に互いに認証するサービスが、代表として派遣される必要があるファイル転送)に関して何も知りません。
* The source and destination hosts of a particular transfer must be
able to mutual authenticate with each other, to ensure the file is
being transferred to and from the proper parties.
* 特定の転送のソースとあて先ホストが互いにできるに違いない、認証、互いと共に、パーティーと、そして、適切なパーティーからファイルを確実にするのを移しています。
* The agent running on Steve's laptop must mutually authenticate
with the file transfer service in order to check the result of the
transfers.
* スティーブのラップトップで動くと転送の結果をチェックするためにファイル転送サービスで互いに認証されなければならないエージェント。
Proxying is a viable approach to solving two (related) problems in this scenario:
Proxyingはこのシナリオの2つ(関係する)の問題を解決することへの実行可能なアプローチです:
* Single sign-on: Steve wants to enter his smartcard password (or
pin) once, and then run a program that will submit all the file
transfer requests to the transfer service, and then periodically
check on the status of the transfer. This program needs to be
given the rights to be able to perform all of these operations
securely, without requiring repeated access to the smartcard or
Steve's password.
* シングルサインオン: 次に、スティーブは、一度彼のスマートカードパスワード(または、ピン)を入力して、すべてのファイル転送要求を転送サービスに提出するプログラムを動かして、次に、定期的に転送の状態について検査したがっています。 このプログラムは、しっかりとこれらの操作のすべてを実行できる権利が与えられている必要があります、スマートカードかスティーブのパスワードへの繰り返されたアクセスを必要としないで。
* Delegation: Various remote processes in this scenario need to
perform secure operations on Steve's behalf, and therefore must be
delegated the necessary rights. For example, the file transfer
* 委譲: このシナリオの様々なリモートプロセスによるスティーブの代理に安全な操作を実行するのが必要であり、したがって、代表として派遣して、必要がまっすぐになるということでなければなりません。 例えば、ファイル転送
Tuecke, et al. Standards Track [Page 6] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke、他 規格はX.509プロキシ証明書プロフィール2004年6月にRFC3820を追跡します[6ページ]。
service needs to be able to authenticate on Steve's behalf with
the source and destination hosts, and must in turn delegate rights
to those hosts so that they can authenticate with each other.
できるサービスの必要性は、彼らが代表として派遣することができるようにそれらのホストへの権利をスティーブに代わってソースとあて先ホストをもって認証して、順番に代表として派遣しなければなりません。互いと共に認証します。
Proxying can be used to secure all of these interactions:
これらの相互作用のすべてを機密保護するのにProxyingを使用できます:
* Proxying allows for the private key stored on the smartcard to be
accessed just once, in order to create the necessary proxy
credential, which allows the client/agent program to be authorized
as Steve when submitting the requests to the transfer service.
Access to the smartcard and Steve's password is not required after
the initial creation of the proxy credential.
* Proxyingは、スマートカードの上に保存された秘密鍵が一度だけアクセスされるのを許容します、必要なプロキシ資格証明書(転送サービスに要求を提出するとき、クライアント/エージェントプログラムがスティーブとして認可されるのを許容する)を作成するために。 スマートカードとスティーブのパスワードへのアクセスはプロキシ資格証明書の初期の作成の後に必要ではありません。
* The client program on the laptop can delegate to the file transfer
service the right to act on Steve's behalf. This, in turn, allows
the service to authenticate to the storage hosts and inherit
Steve's privileges in order to start the file transfers.
* ラップトップの上のクライアントプログラムはスティーブの代理に影響する権利をファイル転送サービスへ代表として派遣することができます。 これで、サービスは、ストレージにホストを認証して、ファイル転送を始めるために順番にスティーブの特権を引き継ぎます。
* When the transfer service authenticates to hosts to start the file
transfer, the service can delegate to the hosts the right to act
on Steve's behalf so that each pair of hosts involved in a file
transfer can mutually authenticate to ensure the file is securely
transferred.
* サービスがファイル転送、サービスを始めるためにホストに認証する転送がホストに委任できるとき、したがってスティーブの代理に影響するファイル転送にかかわったホストの各組がファイルを確実にするために互いに認証できる権利はしっかりと譲渡されます。
* When the agent on the laptop reconnects to the file transfer
service to check on the status of the transfer, it can perform
mutual authentication. The laptop may use a newly generated proxy
credential, which is just created anew using the smartcard.
* ラップトップの上のエージェントが転送の状態について検査するためにファイル転送サービスに再接続するとき、それは互いの認証を実行できます。 ラップトップは新たに生成しているプロキシ資格証明書を使用するかもしれません。(それは、スマートカードを使用することでただ新たに作成されます)。
This scenario, and others similar to it, is being built today within the Grid community. The Grid Security Infrastructure's single sign- on and delegation capabilities, built on X.509 Proxy Certificates, are being employed to provide authentication services to these applications.
このシナリオ、およびそれと同様の他のものは今日、Grid共同体の中に造られています。 これらのアプリケーションへのGrid Security InfrastructureのX.509 Proxy Certificatesで築き上げられたオン、そして、委譲能力が提供する就職であるというサインのただ一つの認証サービス。
2.4. Motivation for Restricted Proxies
2.4. 制限されたプロキシに関する動機
One concern that arises is what happens if a machine that has been delegated the right to inherit Steve's privileges has been compromised? For example, in the above scenario, what if the machine running the file transfer service is compromised, such that the attacker can gain access to the credential that Steve delegated to that service? Can the attacker now do everything that Steve is allowed to do?
起こる1回の関心が代表として派遣して、スティーブの特権を引き継ぐ権利が感染されたということであったマシンであるなら起こることですか? 例えば、上のシナリオでは、スティーブがファイル転送サービスを実行するマシンは感染されます、攻撃者が資格証明書へのアクセスを得ることができるようなものによってそのサービスに委任したなら、どうなるでしょうか? 攻撃者は現在、スティーブがすることができるすべてができますか?
A solution to this problem is to allow for restrictions to be placed on the proxy by means of policies on the proxy certificates. For example, the machine running the reliable file transfer service in
この問題への解決は制限がプロキシに関してプロキシ証明書に関する方針によって課されるのを許容することです。 例えば、信頼できるファイル転送サービスへ駆け込むマシン
Tuecke, et al. Standards Track [Page 7] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke、他 規格はX.509プロキシ証明書プロフィール2004年6月にRFC3820を追跡します[7ページ]。
the above example might only be given Steve's right for the purpose of reading the source files and writing the destination files. Therefore, if that file transfer service is compromised, the attacker cannot modify source files, cannot create or modify other files to which Steve has access, cannot start jobs on behalf of Steve, etc. All that an attacker would be able to do is read the specific files to which the file transfer service has been delegated read access, and write bogus files in place of those that the file transfer service has been delegated write access. Further, by limiting the lifetime of the credential that is delegated to the file transfer service, the effects of a compromise can be further mitigated.
上記の例は、ソースファイルを読む目的へのスティーブの権利を与えて、目的ファイルを書くことであるだけであるかもしれません。 したがって、そのファイル転送サービスが感染されるなら、攻撃者がソースファイルを変更できないで、スティーブがアクセスを持って、スティーブを代表して仕事を始めることができないなど他のファイルを作成できませんし、変更できません。 攻撃者ができるだろうすべては詳細がファイルする代表として派遣された読書アクセスであり、それらに代わってファイル転送サービスが代表として派遣されたとにせのファイルに書くのをファイル転送サービスがさせる読書がアクセサリーを書くということです。 さらに、ファイル転送サービスへ代表として派遣される資格証明書の生涯を制限することによって、感染の効果をさらに緩和できます。
Other potential uses for restricted proxy credentials are discussed in [i7].
[i7]で制限されたプロキシ資格証明書への他の潜在的用途について議論します。
2.5. Motivation for Unique Proxy Name
2.5. ユニークなプロキシ名に関する動機
The dynamic creation of entities (e.g., processes and services) is an essential part of Grid computing. These entities will require rights in order to securely perform their function. While it is possible to obtain rights solely through proxying as described in previous sections, this has limitations. For example what if an entity should have rights that are granted not just from the proxy issuer but from a third party as well? While it is possible in this case for the entity to obtain and hold two proxy certifications, in practice it is simpler for subsequent credentials to take the form of attribute certificates.
実体(例えば、プロセスとサービス)のダイナミックな作成はGridコンピューティングの不可欠の部分です。 これらの実体は、しっかりとそれらの機能を実行するために権利を必要とするでしょう。 唯一前項で説明されるようにproxyingすることで権利を得るのが可能ですが、これには、制限があります。 例えば、実体がプロキシ発行人だけから与えるのではなく、また、第三者から与えられる権利を持つべきであると、どうなるでしょうか? 実体が2つのプロキシ証明を得て、保持するのが、この場合可能ですが、実際には、その後の資格証明書が属性証明書の形を取るのは、より簡単です。
It is also desirable for these entities to have a unique identity so that they can be explicitly discussed in policy statements. For example, a user initiating a third-party FTP transfer could grant each FTP server a PC with a unique identity and inform each server of the identity of the other, then when the two servers connected they could authenticate themselves and know they are connected to the proper party.
また、これらの実体にはユニークなアイデンティティがあるのも、施政方針で明らかにそれらについて議論できるくらい望ましいです。 例えば、第三者FTP転送を起こすユーザがユニークなアイデンティティがあるPCをそれぞれのFTPサーバに与えて、もう片方のアイデンティティの各サーバを知らせることができて、2つのサーバが接続したとき、次に、それらは、自分たちを認証して、適切なパーティーに接続されるのを知るかもしれません。
In order for a party to have rights of it's own it requires a unique identity. Possible options for obtaining an unique identity are:
パーティーがそれのものの権利を自己にするように、それはユニークなアイデンティティを必要とします。 ユニークなアイデンティティを得るための可能なオプションは以下の通りです。
1) Obtain an identity from a traditional Certification Authority
(CA).
1) 伝統的な認証局(カリフォルニア)からアイデンティティを得てください。
2) Obtain a new identity independently - for example by using the
generated public key and a self-signed certificate.
2) 独自、例えば、発生している公開鍵と自己署名入りの証書を使用することによって、新しいアイデンティティを得てください。
3) Derive the new identity from an existing identity.
3) 既存のアイデンティティから新しいアイデンティティを得てください。
Tuecke, et al. Standards Track [Page 8] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke、他 規格はX.509プロキシ証明書プロフィール2004年6月にRFC3820を追跡します[8ページ]。
In this document we describe an approach to option #3, because:
本書では私たちがオプション#3にアプローチを説明する、:
* It is reasonably light-weight, as it can be done without
interacting with a third party. This is important when
creating identities dynamically.
* それは第三者と対話しないでそれができるように合理的に軽量です。 ダイナミックにアイデンティティを作成するとき、これは重要です。
* As described in the previous section, a common use for PCs is
for restricted proxying, so deriving their identity from the
identity of the EEC makes this straightforward. Nonetheless
there are circumstances where the creator does not wish to
delegate all or any of its rights to a new entity. Since the
name is unique, this is easily accomplished by #3 as well, by
allowing the application of a policy to limit proxying.
* 前項で説明されるように、PCの一般の使用は制限されたproxyingのためのものです、そう派生しているので、EECのアイデンティティからの彼らのアイデンティティでこれは簡単になります。 それにもかかわらず、事情がクリエイターが新しい実体への権利のすべてかいずれも代表として派遣したがっていないところにあります。 名前がユニークであるので、これはまた、#3によって容易に達成されます、方針の適用がproxyingを制限するのを許容することによって。
2.6. Description Of Approach
2.6. アプローチの記述
This document defines an X.509 "Proxy Certificate" or "PC" as a means of providing for restricted proxying within an (extended) X.509 PKI based authentication system.
このドキュメントは(広げられる)のX.509 PKIベースの認証システムの中の制限されたproxyingに備える手段とX.509「プロキシ証明書」か「PC」を定義します。
A Proxy Certificate is an X.509 public key certificate with the following properties:
Proxy Certificateは以下の特性があるX.509公開鍵証明書です:
1) It is signed by either an X.509 End Entity Certificate (EEC), or
by another PC. This EEC or PC is referred to as the Proxy Issuer
(PI).
1) それはX.509 End Entity Certificate(EEC)、または別のPCによって署名されます。 このEECかPCがProxy Issuer(PI)と呼ばれます。
2) It can sign only another PC. It cannot sign an EEC.
2) それは別のPCしか署名することができません。 それはEECに署名することができません。
3) It has its own public and private key pair, distinct from any
other EEC or PC.
3) それには、それ自身のいかなる他のEECかPCとも異なった公衆と秘密鍵組があります。
4) It has an identity derived from the identity of the EEC that
signed the PC. When a PC is used for authentication, in may
inherit rights of the EEC that signed the PC, subject to the
restrictions that are placed on that PC by the EEC.
4) それで、PCに署名したEECのアイデンティティからアイデンティティを得ます。 PCが認証に使用されるとき、中では、そのPCに関してEECによって課される制限を条件としてPCに署名したEECの権利は世襲されるかもしれません。
5) Although its identity is derived from the EEC's identity, it is
also unique. This allows this identity to be used for
authorization as an independent identity from the identity of the
issuing EEC, for example in conjunction with attribute assertions
as defined in [i3].
5) EECのアイデンティティからアイデンティティを得ますが、また、それもユニークです。 これは、このアイデンティティが承認に独立しているアイデンティティとして発行しているEECのアイデンティティから使用されるのを許容します、例えば、[i3]で定義される属性主張に関連して。
6) It contains a new X.509 extension to identify it as a PC and to
place policies on the use of the PC. This new extension, along
with other X.509 fields and extensions, are used to enable proper
path validation and use of the PC.
6) それはそれがPCであると認識して、PCの使用に関する方針を置く新しいX.509拡張子を含んでいます。 この新しい拡大であり、他のX.509と共に、分野と拡大はPCの適切な経路合法化と使用を可能にするのにおいて使用されています。
Tuecke, et al. Standards Track [Page 9] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke、他 規格はX.509プロキシ証明書プロフィール2004年6月にRFC3820を追跡します[9ページ]。
The process of creating a PC is as follows:
PCを作成するプロセスは以下の通りです:
1) A new public and private key pair is generated.
1) 新しい公衆と秘密鍵組は発生しています。
2) That key pair is used to create a request for a Proxy Certificate
that conforms to the profile described in this document.
2) その主要な組は、本書では説明されたプロフィールに従うProxy Certificateを求める要求を作成するのに使用されます。
3) A Proxy Certificate, signed by the private key of the EEC or by
another PC, is created in response to the request. During this
process, the PC request is verified to ensure that the requested
PC is valid (e.g., it is not an EEC, the PC fields are
appropriately set, etc).
3) EECの秘密鍵か別のPCによって署名されるProxy Certificateは要求に対応して作成されます。 このプロセスの間、PC要求は、要求されたPCが確実に有効になるようにするために確かめられます(例えば、それがEECでない、PC分野は適切に設定されますなど)。
When a PC is created as part of a delegation from entity A to entity B, this process is modified by performing steps #1 and #2 within entity B, then passing the PC request from entity B to entity A over an authenticated, integrity checked channel, then entity A performs step #3 and passes the PC back to entity B.
PCが委譲の一部として実体Aから実体Bまで作成されるとき、このプロセスが実体Bの中でステップ#1、と#2を実行することによって変更されて、実体Bから実体AまでのPC要求がその時認証されて、保全チェックのチャンネルの上に通って、次に、実体Aは、ステップ#3を実行して、実体BにPCを戻します。
Path validation of a PC is very similar to normal path validation, with a few additional checks to ensure, for example, proper PC signing constraints.
PCの経路合法化は通常の経路合法化と非常に同様です、例えば確実にするいくつかの追加チェックで、適切なPC署名規制。
2.7. Features Of This Approach
2.7. このアプローチの特徴
Using Proxy Certificates to perform delegation has several features that make it attractive:
委譲を実行するのにProxy Certificatesを使用するのにおいて、それを魅力的にするいくつかの特徴があります:
* Ease of integration
* 統合の容易さ
o Because a PC requires only a minimal change to path validation,
it is very easy to incorporate support for Proxy Certificates
into existing X.509 based software. For example, SSL/TLS
requires no protocol changes to support authentication using a
PC. Further, an SSL/TLS implementation requires only minor
changes to support PC path validation, and to retrieve the
authenticated subject of the signing EEC instead of the subject
of the PC for authorization purposes.
o PCが経路合法化への最小量の変化だけを必要とするので、既存のX.509ベースのソフトウェアにProxy Certificatesのサポートを組み入れるのは非常に簡単です。 例えば、SSL/TLSは、PCを使用することで認証をサポートするためにプロトコル変化を全く必要としません。 さらに、SSL/TLS実装は、PC経路合法化をサポートして、承認目的のためにPCの対象の代わりに署名EECの認証された対象を検索するためにマイナーチェンジだけを必要とします。
o Many existing authorization systems use the X.509 subject name
as the basis for access control. Proxy Certificates can be
used with such authorization systems without modification,
since such a PC inherits its name and rights from the EEC that
signed it and the EEC name can be used in place of the PC name
for authorization decisions.
o 多くの既存の承認システムがアクセスコントロールの基礎としてX.509の対象の名を使用します。 そのような承認システムと共に変更なしでプロキシCertificatesを使用できます、そのようなPCがそれに署名したEECからその名前と権利を受け継いで、承認決定のためのPC名に代わってEEC名は使用できるので。
Tuecke, et al. Standards Track [Page 10] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke、他 規格はX.509プロキシ証明書プロフィール2004年6月にRFC3820を追跡します[10ページ]。
* Ease of use
* 使いやすさ
o Using PC for single sign-on helps make X.509 PKI authentication
easier to use, by allowing users to "login" once and then
perform various operations securely.
o シングルサインオンにPCを使用するのは、一度ユーザが「ログインすること」を許容することによってX.509 PKI認証を使用するのをより簡単にして、次に、しっかりと様々な操作を実行するのを助けます。
o For many users, properly managing their own EEC private key is
a nuisance at best, and a security risk at worst. One option
easily enabled with a PC is to manage the EEC private keys and
certificates in a centrally managed repository. When a user
needs a PKI credential, the user can login to the repository
using name/password, one time password, etc. Then the
repository can delegate a PC to the user with proxy rights, but
continue to protect the EEC private key in the repository.
o For many users, properly managing their own EEC private key is a nuisance at best, and a security risk at worst. One option easily enabled with a PC is to manage the EEC private keys and certificates in a centrally managed repository. When a user needs a PKI credential, the user can login to the repository using name/password, one time password, etc. Then the repository can delegate a PC to the user with proxy rights, but continue to protect the EEC private key in the repository.
* Protection of private keys
* Protection of private keys
o By using the remote delegation approach outlined above, entity
A can delegate a PC to entity B, without entity B ever seeing
the private key of entity A, and without entity A ever seeing
the private key of the newly delegated PC held by entity B. In
other words, private keys never need to be shared or
communicated by the entities participating in a delegation of a
PC.
o By using the remote delegation approach outlined above, entity A can delegate a PC to entity B, without entity B ever seeing the private key of entity A, and without entity A ever seeing the private key of the newly delegated PC held by entity B. In other words, private keys never need to be shared or communicated by the entities participating in a delegation of a PC.
o When implementing single sign-on, using a PC helps protect the
private key of the EEC, because it minimizes the exposure and
use of that private key. For example, when an EEC private key
is password protected on disk, the password and unencrypted
private key need only be available during the creation of the
PC. That PC can then be used for the remainder of its valid
lifetime, without requiring access to the EEC password or
private key. Similarly, when the EEC private key lives on a
smartcard, the smartcard need only be present in the machine
during the creation of the PC.
o When implementing single sign-on, using a PC helps protect the private key of the EEC, because it minimizes the exposure and use of that private key. For example, when an EEC private key is password protected on disk, the password and unencrypted private key need only be available during the creation of the PC. That PC can then be used for the remainder of its valid lifetime, without requiring access to the EEC password or private key. Similarly, when the EEC private key lives on a smartcard, the smartcard need only be present in the machine during the creation of the PC.
* Limiting consequences of a compromised key
* Limiting consequences of a compromised key
o When creating a PC, the PI can limit the validity period of the
PC, the depth of the PC path that can be created by that PC,
and key usage of the PC and its descendents. Further, fine-
grained policies can be carried by a PC to even further
restrict the operations that can be performed using the PC.
These restrictions permit the PI to limit damage that could be
done by the bearer of the PC, either accidentally or
maliciously.
o When creating a PC, the PI can limit the validity period of the PC, the depth of the PC path that can be created by that PC, and key usage of the PC and its descendents. Further, fine- grained policies can be carried by a PC to even further restrict the operations that can be performed using the PC. These restrictions permit the PI to limit damage that could be done by the bearer of the PC, either accidentally or maliciously.
Tuecke, et al. Standards Track [Page 11] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke, et al. Standards Track [Page 11] RFC 3820 X.509 Proxy Certificate Profile June 2004
o A compromised PC private key does NOT compromise the EEC
private key. This makes a short term, or an otherwise
restricted PC attractive for day-to-day use, since a
compromised PC does not require the user to go through the
usually cumbersome and time consuming process of having the EEC
with a new private key reissued by the CA.
o A compromised PC private key does NOT compromise the EEC private key. This makes a short term, or an otherwise restricted PC attractive for day-to-day use, since a compromised PC does not require the user to go through the usually cumbersome and time consuming process of having the EEC with a new private key reissued by the CA.
See Section 5 below for more discussion on how Proxy Certificates relate to Attribute Certificates.
See Section 5 below for more discussion on how Proxy Certificates relate to Attribute Certificates.
3. Certificate and Certificate Extensions Profile
3. Certificate and Certificate Extensions Profile
This section defines the usage of X.509 certificate fields and extensions in Proxy Certificates, and defines one new extension for Proxy Certificate Information.
This section defines the usage of X.509 certificate fields and extensions in Proxy Certificates, and defines one new extension for Proxy Certificate Information.
All Proxy Certificates MUST include the Proxy Certificate Information (ProxyCertInfo) extension defined in this section and the extension MUST be critical.
All Proxy Certificates MUST include the Proxy Certificate Information (ProxyCertInfo) extension defined in this section and the extension MUST be critical.
3.1. Issuer
3.1. Issuer
The Proxy Issuer of a Proxy Certificate MUST be either an End Entity Certificate, or another Proxy Certificate.
The Proxy Issuer of a Proxy Certificate MUST be either an End Entity Certificate, or another Proxy Certificate.
The Proxy Issuer MUST NOT have an empty subject field.
The Proxy Issuer MUST NOT have an empty subject field.
The issuer field of a Proxy Certificate MUST contain the subject field of its Proxy Issuer.
The issuer field of a Proxy Certificate MUST contain the subject field of its Proxy Issuer.
If the Proxy Issuer certificate has the KeyUsage extension, the Digital Signature bit MUST be asserted.
If the Proxy Issuer certificate has the KeyUsage extension, the Digital Signature bit MUST be asserted.
3.2. Issuer Alternative Name
3.2. Issuer Alternative Name
The issuerAltName extension MUST NOT be present in a Proxy Certificate.
The issuerAltName extension MUST NOT be present in a Proxy Certificate.
3.3. Serial Number
3.3. Serial Number
The serial number of a Proxy Certificate (PC) SHOULD be unique amongst all Proxy Certificates issued by a particular Proxy Issuer. However, a Proxy Issuer MAY use an approach to assigning serial numbers that merely ensures a high probability of uniqueness.
The serial number of a Proxy Certificate (PC) SHOULD be unique amongst all Proxy Certificates issued by a particular Proxy Issuer. However, a Proxy Issuer MAY use an approach to assigning serial numbers that merely ensures a high probability of uniqueness.
Tuecke, et al. Standards Track [Page 12] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke, et al. Standards Track [Page 12] RFC 3820 X.509 Proxy Certificate Profile June 2004
For example, a Proxy Issuer MAY use a sequentially assigned integer or a UUID to assign a unique serial number to a PC it issues. Or a Proxy Issuer MAY use a SHA-1 hash of the PC public key to assign a serial number with a high probability of uniqueness.
For example, a Proxy Issuer MAY use a sequentially assigned integer or a UUID to assign a unique serial number to a PC it issues. Or a Proxy Issuer MAY use a SHA-1 hash of the PC public key to assign a serial number with a high probability of uniqueness.
3.4. Subject
3.4. Subject
The subject field of a Proxy Certificate MUST be the issuer field (that is the subject of the Proxy Issuer) appended with a single Common Name component.
The subject field of a Proxy Certificate MUST be the issuer field (that is the subject of the Proxy Issuer) appended with a single Common Name component.
The value of the Common Name SHOULD be unique to each Proxy Certificate bearer amongst all Proxy Certificates with the same issuer.
The value of the Common Name SHOULD be unique to each Proxy Certificate bearer amongst all Proxy Certificates with the same issuer.
If a Proxy Issuer issues two proxy certificates to the same bearer, the Proxy Issuer MAY choose to use the same Common Name for both. Examples of this include Proxy Certificates for different uses (e.g., signing vs encryption) or the re-issuance of an expired Proxy Certificate.
If a Proxy Issuer issues two proxy certificates to the same bearer, the Proxy Issuer MAY choose to use the same Common Name for both. Examples of this include Proxy Certificates for different uses (e.g., signing vs encryption) or the re-issuance of an expired Proxy Certificate.
The Proxy Issuer MAY use an approach to assigning Common Name values that merely ensures a high probability of uniqueness. This value MAY be the same value used for the serial number.
The Proxy Issuer MAY use an approach to assigning Common Name values that merely ensures a high probability of uniqueness. This value MAY be the same value used for the serial number.
The result of this approach is that all subject names of Proxy Certificates are derived from the name of the issuing EEC (it will be the first part of the subject name appended with one or more CN components) and are unique to each bearer.
The result of this approach is that all subject names of Proxy Certificates are derived from the name of the issuing EEC (it will be the first part of the subject name appended with one or more CN components) and are unique to each bearer.
3.5. Subject Alternative Name
3.5. Subject Alternative Name
The subjectAltName extension MUST NOT be present in a Proxy Certificate.
The subjectAltName extension MUST NOT be present in a Proxy Certificate.
3.6. Key Usage and Extended Key Usage
3.6. Key Usage and Extended Key Usage
If the Proxy Issuer certificate has a Key Usage extension, the Digital Signature bit MUST be asserted.
If the Proxy Issuer certificate has a Key Usage extension, the Digital Signature bit MUST be asserted.
This document places no constraints on the presence or contents of the key usage and extended key usage extension. However, section 4.2 explains what functions should be allowed a proxy certificate by a relying party.
This document places no constraints on the presence or contents of the key usage and extended key usage extension. However, section 4.2 explains what functions should be allowed a proxy certificate by a relying party.
Tuecke, et al. Standards Track [Page 13] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke, et al. Standards Track [Page 13] RFC 3820 X.509 Proxy Certificate Profile June 2004
3.7. Basic Constraints
3.7. Basic Constraints
The cA field in the basic constraints extension MUST NOT be TRUE.
The cA field in the basic constraints extension MUST NOT be TRUE.
3.8. The ProxyCertInfo Extension
3.8. The ProxyCertInfo Extension
A new extension, ProxyCertInfo, is defined in this subsection. Presence of the ProxyCertInfo extension indicates that a certificate is a Proxy Certificate and whether or not the issuer of the certificate has placed any restrictions on its use.
A new extension, ProxyCertInfo, is defined in this subsection. Presence of the ProxyCertInfo extension indicates that a certificate is a Proxy Certificate and whether or not the issuer of the certificate has placed any restrictions on its use.
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
id-pe-proxyCertInfo OBJECT IDENTIFIER ::= { id-pe 14 }
id-pe-proxyCertInfo OBJECT IDENTIFIER ::= { id-pe 14 }
ProxyCertInfo ::= SEQUENCE {
pCPathLenConstraint INTEGER (0..MAX) OPTIONAL,
proxyPolicy ProxyPolicy }
ProxyCertInfo ::= SEQUENCE { pCPathLenConstraint INTEGER (0..MAX) OPTIONAL, proxyPolicy ProxyPolicy }
ProxyPolicy ::= SEQUENCE {
policyLanguage OBJECT IDENTIFIER,
policy OCTET STRING OPTIONAL }
ProxyPolicy ::= SEQUENCE { policyLanguage OBJECT IDENTIFIER, policy OCTET STRING OPTIONAL }
If a certificate is a Proxy Certificate, then the proxyCertInfo extension MUST be present, and this extension MUST be marked as critical.
If a certificate is a Proxy Certificate, then the proxyCertInfo extension MUST be present, and this extension MUST be marked as critical.
If a certificate is not a Proxy Certificate, then the proxyCertInfo extension MUST be absent.
If a certificate is not a Proxy Certificate, then the proxyCertInfo extension MUST be absent.
The ProxyCertInfo extension consists of one required and two optional fields, which are described in detail in the following subsections.
The ProxyCertInfo extension consists of one required and two optional fields, which are described in detail in the following subsections.
3.8.1. pCPathLenConstraint
3.8.1. pCPathLenConstraint
The pCPathLenConstraint field, if present, specifies the maximum depth of the path of Proxy Certificates that can be signed by this Proxy Certificate. A pCPathLenConstraint of 0 means that this certificate MUST NOT be used to sign a Proxy Certificate. If the pCPathLenConstraint field is not present then the maximum proxy path length is unlimited. End entity certificates have unlimited maximum proxy path lengths.
The pCPathLenConstraint field, if present, specifies the maximum depth of the path of Proxy Certificates that can be signed by this Proxy Certificate. A pCPathLenConstraint of 0 means that this certificate MUST NOT be used to sign a Proxy Certificate. If the pCPathLenConstraint field is not present then the maximum proxy path length is unlimited. End entity certificates have unlimited maximum proxy path lengths.
Tuecke, et al. Standards Track [Page 14] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke, et al. Standards Track [Page 14] RFC 3820 X.509 Proxy Certificate Profile June 2004
3.8.2. proxyPolicy
3.8.2. proxyPolicy
The proxyPolicy field specifies a policy on the use of this certificate for the purposes of authorization. Within the proxyPolicy, the policy field is an expression of policy, and the policyLanguage field indicates the language in which the policy is expressed.
The proxyPolicy field specifies a policy on the use of this certificate for the purposes of authorization. Within the proxyPolicy, the policy field is an expression of policy, and the policyLanguage field indicates the language in which the policy is expressed.
The proxyPolicy field in the proxyCertInfo extension does not define a policy language to be used for proxy restrictions; rather, it places the burden on those parties using that extension to define an appropriate language, and to acquire an OID for that language (or to select an appropriate previously-defined language/OID). Because it is essential for the PI that issues a certificate with a proxyPolicy field and the relying party that interprets that field to agree on its meaning, the policy language OID must correspond to a policy language (including semantics), not just a policy grammar.
The proxyPolicy field in the proxyCertInfo extension does not define a policy language to be used for proxy restrictions; rather, it places the burden on those parties using that extension to define an appropriate language, and to acquire an OID for that language (or to select an appropriate previously-defined language/OID). Because it is essential for the PI that issues a certificate with a proxyPolicy field and the relying party that interprets that field to agree on its meaning, the policy language OID must correspond to a policy language (including semantics), not just a policy grammar.
The policyLanguage field has two values of special importance, defined in Appendix A, that MUST be understood by all parties accepting Proxy Certificates:
The policyLanguage field has two values of special importance, defined in Appendix A, that MUST be understood by all parties accepting Proxy Certificates:
* id-ppl-inheritAll indicates that this is an unrestricted proxy
that inherits all rights from the issuing PI. An unrestricted
proxy is a statement that the Proxy Issuer wishes to delegate all
of its authority to the bearer (i.e., to anyone who has that proxy
certificate and can prove possession of the associated private
key). For purposes of authorization, this an unrestricted proxy
effectively impersonates the issuing PI.
* id-ppl-inheritAll indicates that this is an unrestricted proxy that inherits all rights from the issuing PI. An unrestricted proxy is a statement that the Proxy Issuer wishes to delegate all of its authority to the bearer (i.e., to anyone who has that proxy certificate and can prove possession of the associated private key). For purposes of authorization, this an unrestricted proxy effectively impersonates the issuing PI.
* id-ppl-independent indicates that this is an independent proxy
that inherits no rights from the issuing PI. This PC MUST be
treated as an independent identity by relying parties. The only
rights this PC has are those granted explicitly to it.
* id-ppl-independent indicates that this is an independent proxy that inherits no rights from the issuing PI. This PC MUST be treated as an independent identity by relying parties. The only rights this PC has are those granted explicitly to it.
For either of the policyLanguage values listed above, the policy field MUST NOT be present.
For either of the policyLanguage values listed above, the policy field MUST NOT be present.
Other values for the policyLanguage field indicates that this is a restricted proxy certification and have some other policy limiting its ability to do proxying. In this case the policy field MAY be present and it MUST contain information expressing the policy. If the policy field is not present the policy MUST be implicit in the value of the policyLanguage field itself. Authors of additional policy languages are encouraged to publicly document their policy language and list it in the IANA registry (see Section 7).
Other values for the policyLanguage field indicates that this is a restricted proxy certification and have some other policy limiting its ability to do proxying. In this case the policy field MAY be present and it MUST contain information expressing the policy. If the policy field is not present the policy MUST be implicit in the value of the policyLanguage field itself. Authors of additional policy languages are encouraged to publicly document their policy language and list it in the IANA registry (see Section 7).
Tuecke, et al. Standards Track [Page 15] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke, et al. Standards Track [Page 15] RFC 3820 X.509 Proxy Certificate Profile June 2004
Proxy policies are used to limit the amount of authority delegated, for example to assert that the proxy certificate may be used only to make requests to a specific server, or only to authorize specific operations on specific resources. This document is agnostic to the policies that can be placed in the policy field.
Proxy policies are used to limit the amount of authority delegated, for example to assert that the proxy certificate may be used only to make requests to a specific server, or only to authorize specific operations on specific resources. This document is agnostic to the policies that can be placed in the policy field.
Proxy policies impose additional requirements on the relying party, because only the relying party is in a position to ensure that those policies are enforced. When making an authorization decision based on a proxy certificate based on rights that proxy certificate inherited from its issuer, it is the relying party's responsibility to verify that the requested authority is compatible with all policies in the PC's certificate path. In other words, the relying party MUST verify that the following three conditions are all met:
Proxy policies impose additional requirements on the relying party, because only the relying party is in a position to ensure that those policies are enforced. When making an authorization decision based on a proxy certificate based on rights that proxy certificate inherited from its issuer, it is the relying party's responsibility to verify that the requested authority is compatible with all policies in the PC's certificate path. In other words, the relying party MUST verify that the following three conditions are all met:
1) The relying party MUST know how to interpret the proxy policy and
the request is allowed under that policy.
1) The relying party MUST know how to interpret the proxy policy and the request is allowed under that policy.
2) If the Proxy Issuer is an EEC then the relying party's local
policies MUST authorize the request for the entity named in the
EEC.
2) If the Proxy Issuer is an EEC then the relying party's local policies MUST authorize the request for the entity named in the EEC.
3) If the Proxy Issuer is another PC, then one of the following MUST
be true:
3) If the Proxy Issuer is another PC, then one of the following MUST be true:
a. The relying party's local policies authorize the Proxy Issuer
to perform the request.
a. The relying party's local policies authorize the Proxy Issuer to perform the request.
b. The Proxy Issuer inherits the right to perform the request from
its issuer by means of its proxy policy. This must be verified
by verifying these three conditions on the Proxy Issuer in a
recursive manner.
b. The Proxy Issuer inherits the right to perform the request from its issuer by means of its proxy policy. This must be verified by verifying these three conditions on the Proxy Issuer in a recursive manner.
If these conditions are not met, the relying party MUST either deny authorization, or ignore the PC and the whole certificate chain including the EEC entirely when making its authorization decision (i.e., make the same decision that it would have made had the PC and it's certificate chain never been presented).
If these conditions are not met, the relying party MUST either deny authorization, or ignore the PC and the whole certificate chain including the EEC entirely when making its authorization decision (i.e., make the same decision that it would have made had the PC and it's certificate chain never been presented).
The relying party MAY impose additional restrictions as to which proxy certificates it accepts. For example, a relying party MAY choose to reject all proxy certificates, or MAY choose to accept proxy certificates only for certain operations, etc.
The relying party MAY impose additional restrictions as to which proxy certificates it accepts. For example, a relying party MAY choose to reject all proxy certificates, or MAY choose to accept proxy certificates only for certain operations, etc.
Note that since a proxy certificate has a unique identity it MAY also have rights granted to it by means other than inheritance from it's issuer via its proxy policy. The rights granted to the bearer of a PC are the union of the rights granted to the PC identity and the
Note that since a proxy certificate has a unique identity it MAY also have rights granted to it by means other than inheritance from it's issuer via its proxy policy. The rights granted to the bearer of a PC are the union of the rights granted to the PC identity and the
Tuecke, et al. Standards Track [Page 16] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke, et al. Standards Track [Page 16] RFC 3820 X.509 Proxy Certificate Profile June 2004
inherited rights. The inherited rights consist of the intersection of the rights granted to the PI identity intersected with the proxy policy in the PC.
inherited rights. The inherited rights consist of the intersection of the rights granted to the PI identity intersected with the proxy policy in the PC.
For example, imagine that Steve is authorized to read and write files A and B on a file server, and that he uses his EEC to create a PC that includes the policy that it can be used only to read or write files A and C. Then a trusted attribute authority grants an Attribute Certificate granting the PC the right to read file D. This would make the rights of the PC equal to the union of the rights granted to the PC identity (right to read file D) with the intersection of the rights granted to Steve, the PI, (right to read files A and B) with the policy in the PC (can only read files A and C). This would mean the PC would have the following rights:
For example, imagine that Steve is authorized to read and write files A and B on a file server, and that he uses his EEC to create a PC that includes the policy that it can be used only to read or write files A and C. Then a trusted attribute authority grants an Attribute Certificate granting the PC the right to read file D. This would make the rights of the PC equal to the union of the rights granted to the PC identity (right to read file D) with the intersection of the rights granted to Steve, the PI, (right to read files A and B) with the policy in the PC (can only read files A and C). This would mean the PC would have the following rights:
* Right to read file A: Steve has this right and he issued the PC
and his policy grants this right to the PC.
* Right to read file A: Steve has this right and he issued the PC and his policy grants this right to the PC.
* Right to read file D: This right is granted explicitly to the PC
by a trusted authority.
* Right to read file D: This right is granted explicitly to the PC by a trusted authority.
The PC would NOT have the following rights:
The PC would NOT have the following rights:
* Right to read file B: Although Steve has this right, it is
excluded by his policy on the PC.
* Right to read file B: Although Steve has this right, it is excluded by his policy on the PC.
* Right to read file C: Although Steve's policy grants this right,
he does not have this right himself.
* Right to read file C: Although Steve's policy grants this right, he does not have this right himself.
In many cases, the relying party will not have enough information to evaluate the above criteria at the time that the certificate path is validated. For example, if a certificate is used to authenticate a connection to some server, that certificate is typically validated during that authentication step, before any requests have been made of the server. In that case, the relying party MUST either have some authorization mechanism in place that will check the proxy policies, or reject any certificate that contains proxy policies (or that has a parent certificate that contains proxy policies).
In many cases, the relying party will not have enough information to evaluate the above criteria at the time that the certificate path is validated. For example, if a certificate is used to authenticate a connection to some server, that certificate is typically validated during that authentication step, before any requests have been made of the server. In that case, the relying party MUST either have some authorization mechanism in place that will check the proxy policies, or reject any certificate that contains proxy policies (or that has a parent certificate that contains proxy policies).
4. Proxy Certificate Path Validation
4. Proxy Certificate Path Validation
Proxy Certification path processing verifies the binding between the proxy certificate distinguished name and proxy certificate public key. The binding is limited by constraints which are specified in the certificates which comprise the path and inputs which are specified by the relying party.
Proxy Certification path processing verifies the binding between the proxy certificate distinguished name and proxy certificate public key. The binding is limited by constraints which are specified in the certificates which comprise the path and inputs which are specified by the relying party.
Tuecke, et al. Standards Track [Page 17] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke, et al. Standards Track [Page 17] RFC 3820 X.509 Proxy Certificate Profile June 2004
This section describes an algorithm for validating proxy certification paths. Conforming implementations of this specification are not required to implement this algorithm, but MUST provide functionality equivalent to the external behavior resulting from this procedure. Any algorithm may be used by a particular implementation so long as it derives the correct result.
This section describes an algorithm for validating proxy certification paths. Conforming implementations of this specification are not required to implement this algorithm, but MUST provide functionality equivalent to the external behavior resulting from this procedure. Any algorithm may be used by a particular implementation so long as it derives the correct result.
The algorithm presented in this section validates the proxy certificate with respect to the current date and time. A conformant implementation MAY also support validation with respect to some point in the past. Note that mechanisms are not available for validating a proxy certificate with respect to a time outside the certificate validity period.
The algorithm presented in this section validates the proxy certificate with respect to the current date and time. A conformant implementation MAY also support validation with respect to some point in the past. Note that mechanisms are not available for validating a proxy certificate with respect to a time outside the certificate validity period.
Valid paths begin with the end entity certificate (EEC) that has already been validated by public key certificate validation procedures in RFC 3280 [n2]. The algorithm requires the public key of the EEC and the EEC's subject distinguished name.
Valid paths begin with the end entity certificate (EEC) that has already been validated by public key certificate validation procedures in RFC 3280 [n2]. The algorithm requires the public key of the EEC and the EEC's subject distinguished name.
To meet the goal of verifying the proxy certificate, the proxy certificate path validation process verifies, among other things, that a prospective certification path (a sequence of n certificates) satisfies the following conditions:
To meet the goal of verifying the proxy certificate, the proxy certificate path validation process verifies, among other things, that a prospective certification path (a sequence of n certificates) satisfies the following conditions:
(a) for all x in {1, ..., n-1}, the subject of certificate x is the
issuer of proxy certificate x+1 and the subject distinguished
name of certificate x+1 is a legal subject distinguished name to
have been issued by certificate x;
(a) for all x in {1, ..., n-1}, the subject of certificate x is the issuer of proxy certificate x+1 and the subject distinguished name of certificate x+1 is a legal subject distinguished name to have been issued by certificate x;
(b) certificate 1 is valid proxy certificate issued by the end entity
certificate whose information is given as input to the proxy
certificate path validation process;
(b) certificate 1 is valid proxy certificate issued by the end entity certificate whose information is given as input to the proxy certificate path validation process;
(c) certificate n is the proxy certificate to be validated;
(c) certificate n is the proxy certificate to be validated;
(d) for all x in {1, ..., n}, the certificate was valid at the time
in question; and
(d) for all x in {1, ..., n}, the certificate was valid at the time in question; and
(e) for all certificates in the path with a pCPathLenConstraint
field, the number of certificates in the path following that
certificate does not exceed the length specified in that field.
(e) for all certificates in the path with a pCPathLenConstraint field, the number of certificates in the path following that certificate does not exceed the length specified in that field.
At this point there is no mechanism defined for revoking proxy certificates.
At this point there is no mechanism defined for revoking proxy certificates.
Tuecke, et al. Standards Track [Page 18] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke, et al. Standards Track [Page 18] RFC 3820 X.509 Proxy Certificate Profile June 2004
4.1. Basic Proxy Certificate Path Validation
4.1. Basic Proxy Certificate Path Validation
This section presents the algorithm in four basic steps to mirror the description of public key certificate path validation in RFC 3280: (1) initialization, (2) basic proxy certificate processing, (3) preparation for the next proxy certificate, and (4) wrap-up. Steps (1) and (4) are performed exactly once. Step (2) is performed for all proxy certificates in the path. Step (3) is performed for all proxy certificates in the path except the final proxy certificate.
This section presents the algorithm in four basic steps to mirror the description of public key certificate path validation in RFC 3280: (1) initialization, (2) basic proxy certificate processing, (3) preparation for the next proxy certificate, and (4) wrap-up. Steps (1) and (4) are performed exactly once. Step (2) is performed for all proxy certificates in the path. Step (3) is performed for all proxy certificates in the path except the final proxy certificate.
Certificate path validation as described in RFC 3280 MUST have been done prior to using this algorithm to validate the end entity certificate. This algorithm then processes the proxy certificate chain using the end entity certificate information produced by RFC 3280 path validation.
Certificate path validation as described in RFC 3280 MUST have been done prior to using this algorithm to validate the end entity certificate. This algorithm then processes the proxy certificate chain using the end entity certificate information produced by RFC 3280 path validation.
4.1.1. Inputs
4.1.1. Inputs
This algorithm assumes the following inputs are provided to the path processing logic:
This algorithm assumes the following inputs are provided to the path processing logic:
(a) information about the entity certificate already verified using
RFC 3280 path validation. This information includes:
(a) information about the entity certificate already verified using RFC 3280 path validation. This information includes:
(1) the end entity name,
(1) the end entity name,
(2) the working_public_key output from RFC 3280 path validation,
(2) the working_public_key output from RFC 3280 path validation,
(3) the working_public_key_algorithm output from RFC 3280,
(3) the working_public_key_algorithm output from RFC 3280,
(4) and the working_public_key_parameters output from RFC 3280
path validation.
(4) and the working_public_key_parameters output from RFC 3280 path validation.
(b) prospective proxy certificate path of length n.
(b) prospective proxy certificate path of length n.
(c) acceptable-pc-policy-language-set: A set of proxy certificate
policy languages understood by the policy evaluation code. The
acceptable-pc-policy-language-set MAY contain the special value
id-ppl-anyLanguage (as defined in Appendix A) if the path
validation code should not check the proxy certificate policy
languages (typically because the set of known policy languages is
not known yet and will be checked later in the authorization
process).
(c) acceptable-pc-policy-language-set: A set of proxy certificate policy languages understood by the policy evaluation code. The acceptable-pc-policy-language-set MAY contain the special value id-ppl-anyLanguage (as defined in Appendix A) if the path validation code should not check the proxy certificate policy languages (typically because the set of known policy languages is not known yet and will be checked later in the authorization process).
(d) the current date and time.
(d) the current date and time.
Tuecke, et al. Standards Track [Page 19] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke, et al. Standards Track [Page 19] RFC 3820 X.509 Proxy Certificate Profile June 2004
4.1.2. Initialization
4.1.2. Initialization
This initialization phase establishes the following state variables based upon the inputs:
This initialization phase establishes the following state variables based upon the inputs:
(a) working_public_key_algorithm: the digital signature algorithm
used to verify the signature of a proxy certificate. The
working_public_key_algorithm is initialized from the input
information provided from RFC 3280 path validation.
(a) working_public_key_algorithm: the digital signature algorithm used to verify the signature of a proxy certificate. The working_public_key_algorithm is initialized from the input information provided from RFC 3280 path validation.
(b) working_public_key: the public key used to verify the signature
of a proxy certificate. The working_public_key is initialized
from the input information provided from RFC 3280 path
validation.
(b) working_public_key: the public key used to verify the signature of a proxy certificate. The working_public_key is initialized from the input information provided from RFC 3280 path validation.
(c) working_public_key_parameters: parameters associated with the
current public key, that may be required to verify a signature
(depending upon the algorithm). The
proxy_issuer_public_key_parameters variable is initialized from
the input information provided from RFC 3280 path validation.
(c) working_public_key_parameters: parameters associated with the current public key, that may be required to verify a signature (depending upon the algorithm). The proxy_issuer_public_key_parameters variable is initialized from the input information provided from RFC 3280 path validation.
(d) working_issuer_name: the issuer distinguished name expected in
the next proxy certificate in the chain. The working_issuer_name
is initialized to the distinguished name in the end entity
certificate validated by RFC 3280 path validation.
(d) working_issuer_name: the issuer distinguished name expected in the next proxy certificate in the chain. The working_issuer_name is initialized to the distinguished name in the end entity certificate validated by RFC 3280 path validation.
(e) max_path_length: this integer is initialized to n, is decremented
for each proxy certificate in the path. This value may also be
reduced by the pcPathLenConstraint value of any proxy certificate
in the chain.
(e) max_path_length: this integer is initialized to n, is decremented for each proxy certificate in the path. This value may also be reduced by the pcPathLenConstraint value of any proxy certificate in the chain.
(f) proxy_policy_list: this list is empty to start and will be filled
in with the key usage extensions, extended key usage extensions
and proxy policies in the chain.
(f) proxy_policy_list: this list is empty to start and will be filled in with the key usage extensions, extended key usage extensions and proxy policies in the chain.
Upon completion of the initialization steps, perform the basic certificate processing steps specified in 4.1.3.
Upon completion of the initialization steps, perform the basic certificate processing steps specified in 4.1.3.
4.1.3. Basic Proxy Certificate Processing
4.1.3. Basic Proxy Certificate Processing
The basic path processing actions to be performed for proxy certificate i (for all i in [1..n]) are listed below.
The basic path processing actions to be performed for proxy certificate i (for all i in [1..n]) are listed below.
(a) Verify the basic certificate information. The certificate MUST
satisfy each of the following:
(a) Verify the basic certificate information. The certificate MUST satisfy each of the following:
Tuecke, et al. Standards Track [Page 20] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke, et al. Standards Track [Page 20] RFC 3820 X.509 Proxy Certificate Profile June 2004
(1) The certificate was signed with the
working_public_key_algorithm using the working_public_key and
the working_public_key_parameters.
(1) The certificate was signed with the working_public_key_algorithm using the working_public_key and the working_public_key_parameters.
(2) The certificate validity period includes the current time.
(2) The certificate validity period includes the current time.
(3) The certificate issuer name is the working_issuer_name.
(3) The certificate issuer name is the working_issuer_name.
(4) The certificate subject name is the working_issuer_name with a
CN component appended.
(4) The certificate subject name is the working_issuer_name with a CN component appended.
(b) The proxy certificate MUST have a ProxyCertInfo extension.
Process the extension as follows:
(b) The proxy certificate MUST have a ProxyCertInfo extension. Process the extension as follows:
(1) If the pCPathLenConstraint field is present in the
ProxyCertInfo field and the value it contains is less than
max_path_length, set max_path_length to its value.
(1) If the pCPathLenConstraint field is present in the ProxyCertInfo field and the value it contains is less than max_path_length, set max_path_length to its value.
(2) If acceptable-pc-policy-language-set is not id-ppl-
anyLanguage, the OID in the policyLanguage field MUST be
present in acceptable-pc-policy-language-set.
(2) If acceptable-pc-policy-language-set is not id-ppl- anyLanguage, the OID in the policyLanguage field MUST be present in acceptable-pc-policy-language-set.
(c) The tuple containing the certificate subject name, policyPolicy,
key usage extension (if present) and extended key usage extension
(if present) must be appended to proxy_policy_list.
(c) The tuple containing the certificate subject name, policyPolicy, key usage extension (if present) and extended key usage extension (if present) must be appended to proxy_policy_list.
(d) Process other certificate extensions, as described in [n2]:
(d) Process other certificate extensions, as described in [n2]:
(1) Recognize and process any other critical extensions present in
the proxy certificate.
(1) Recognize and process any other critical extensions present in the proxy certificate.
(2) Process any recognized non-critical extension present in the
proxy certificate.
(2) Process any recognized non-critical extension present in the proxy certificate.
If either step (a), (b) or (d) fails, the procedure terminates, returning a failure indication and an appropriate reason.
If either step (a), (b) or (d) fails, the procedure terminates, returning a failure indication and an appropriate reason.
If i is not equal to n, continue by performing the preparatory steps listed in 4.1.4. If i is equal to n, perform the wrap-up steps listed in 4.1.5.
If i is not equal to n, continue by performing the preparatory steps listed in 4.1.4. If i is equal to n, perform the wrap-up steps listed in 4.1.5.
4.1.4. Preparation for next Proxy Certificate
4.1.4. Preparation for next Proxy Certificate
(a) Verify max_path_length is greater than zero and decrement
max_path_length.
(a) Verify max_path_length is greater than zero and decrement max_path_length.
(b) Assign the certificate subject name to working_issuer_name.
(b) Assign the certificate subject name to working_issuer_name.
Tuecke, et al. Standards Track [Page 21] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke, et al. Standards Track [Page 21] RFC 3820 X.509 Proxy Certificate Profile June 2004
(c) Assign the certificate subjectPublicKey to working_public_key.
(c) Assign the certificate subjectPublicKey to working_public_key.
(d) If the subjectPublicKeyInfo field of the certificate contains an
algorithm field with non-null parameters, assign the parameters
to the working_public_key_parameters variable.
(d) If the subjectPublicKeyInfo field of the certificate contains an algorithm field with non-null parameters, assign the parameters to the working_public_key_parameters variable.
If the subjectPublicKeyInfo field of the certificate contains an
algorithm field with null parameters or parameters are omitted,
compare the certificate subjectPublicKey algorithm to the
working_public_key_algorithm. If the certificate
subjectPublicKey algorithm and the working_public_key_algorithm
are different, set the working_public_key_parameters to null.
証明書のsubjectPublicKeyInfo分野がヌルパラメタがあるアルゴリズム分野を含んでいるか、またはパラメタが省略されるなら、働く_公共の_主要な_アルゴリズムに証明書subjectPublicKeyアルゴリズムをたとえてください。 証明書subjectPublicKeyアルゴリズムと働く_公共の_主要な_アルゴリズムが異なるなら、働く_公共の_主要な_パラメタをヌルに設定してください。
(e) Assign the certificate subjectPublicKey algorithm to the
working_public_key_algorithm variable.
(e) 働く_の公共の_主要な_アルゴリズム変数に証明書subjectPublicKeyアルゴリズムを割り当ててください。
(f) If a key usage extension is present, verify that the
digitalSignature bit is set.
(f) 主要な用法拡大が存在しているなら、digitalSignatureビットが設定されることを確かめてください。
If either check (a) or (f) fails, the procedure terminates, returning a failure indication and an appropriate reason.
チェック(a)か(f)のどちらかが失敗するなら、手順は終わって、失敗指示と適切な理由を返します。
If (a) and (f) complete successfully, increment i and perform the basic certificate processing specified in 4.1.3.
(a)と(f)が首尾よく完成して、iを増加して、処理が指定した基本の証明書を実行する、4.1 .3。
4.1.5. Wrap-up Procedures
4.1.5. 結論手順
(a) Assign the certificate subject name to working_issuer_name.
(a) 働く_発行人_名に証明書対象名を割り当ててください。
(b) Assign the certificate subjectPublicKey to working_public_key.
(b) 働く_公共の_キーに証明書subjectPublicKeyを割り当ててください。
(c) If the subjectPublicKeyInfo field of the certificate contains an
algorithm field with non-null parameters, assign the parameters
to the proxy_issuer_public_key_parameters variable.
(c) 証明書のsubjectPublicKeyInfo分野が非ヌルパラメタがあるアルゴリズム分野を含むなら、プロキシ_発行人の公共の_主要な_パラメタ_変数にパラメタを割り当ててください。
If the subjectPublicKeyInfo field of the certificate contains an
algorithm field with null parameters or parameters are omitted,
compare the certificate subjectPublicKey algorithm to the
proxy_issuer_public_key_algorithm. If the certificate
subjectPublicKey algorithm and the
proxy_issuer_public_key_algorithm are different, set the
proxy_issuer_public_key_parameters to null.
証明書のsubjectPublicKeyInfo分野がヌルパラメタがあるアルゴリズム分野を含んでいるか、またはパラメタが省略されるなら、プロキシ_発行人の_の公共の_主要な_アルゴリズムに証明書subjectPublicKeyアルゴリズムをたとえてください。 証明書subjectPublicKeyアルゴリズムとプロキシ_発行人の_の公共の_主要な_アルゴリズムが異なるなら、プロキシ_発行人の_の公共の_主要な_パラメタをヌルに設定してください。
(d) Assign the certificate subjectPublicKey algorithm to the
proxy_issuer_public_key_algorithm variable.
(d) プロキシ_発行人の公共の_主要な_アルゴリズム_変数に証明書subjectPublicKeyアルゴリズムを割り当ててください。
Tuecke, et al. Standards Track [Page 22] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke、他 規格はX.509プロキシ証明書プロフィール2004年6月にRFC3820を追跡します[22ページ]。
4.1.6. Outputs
4.1.6. 出力
If path processing succeeds, the procedure terminates, returning a success indication together with final value of the working_public_key, the working_public_key_algorithm, the working_public_key_parameters, and the proxy_policy_list.
経路処理が成功するなら、手順は終わります、働く_公共の_キー、働く_公共の_主要な_アルゴリズム、働く_公共の_主要な_パラメタ、およびプロキシ_方針_リストの検査値と共に成功指示を返して。
4.2. Using the Path Validation Algorithm
4.2. 経路合法化アルゴリズムを使用します。
Each Proxy Certificate contains a ProxyCertInfo extension, which always contains a policy language OID, and may also contain a policy OCTET STRING. These policies serve to indicate the desire of each issuer in the proxy certificate chain, starting with the EEC, to delegate some subset of their rights to the issued proxy certificate. This chain of policies is returned by the algorithm to the application.
各Proxy CertificateはProxyCertInfo拡張子を含んでいて、また、方針OCTET STRINGを含むかもしれません。(拡張子はいつも方針言語OIDを含みます)。 これらの方針は、プロキシ証明書チェーンにおけるそれぞれの発行人の願望を示すのに役立ちます、発行されたプロキシ証明書へのそれらの権利の何らかの部分集合を代表として派遣するためにEECから始まって。 アルゴリズムで方針のこのチェーンをアプリケーションに返します。
The application MAY make authorization decisions based on the subject distinguished name of the proxy certificate or on one of the proxy certificates in it's issuing chain or on the EEC that serves as the root of the chain. If an application chooses to use the subject distinguished name of a proxy certificate in the issuing chain or the EEC it MUST use the returned policies to restrict the rights it grants to the proxy certificate. If the application does not know how to parse any policy in the policy chain it MUST not use, for the purposes of making authorization decisions, the subject distinguished name of any certificate in the chain prior to the certificate in which the unrecognized policy appears.
アプリケーションが、プロキシ証明書の対象の分類名に基づく承認決定をするかもしれないか、それのプロキシ証明書の1つでチェーンを支給しています、またはEECでは、それはチェーンの根として機能します。 アプリケーションが、発行チェーンかEECのプロキシ証明書の対象の分類名を使用するのを選ぶなら、それは、それがプロキシ証明書に与える権利を制限するのに返された方針を使用しなければなりません。 アプリケーションが方針チェーンでどんな方針も分析する方法を知らないなら、それは承認を作る目的に、決定(認識されていない方針が現れる証明書の前のチェーンにおける、どんな証明書の対象の分類名も)を使用してはいけません。
Application making authorization decisions based on the contents of the proxy certificate key usage or extended key usage extensions MUST examine the list of key usage, extended key usage and proxy policies resulting from proxy certificate path validation and determine the effective key usage functions of the proxy certificate as follows:
プロキシ証明書キー用法か拡張主要な用法拡大のコンテンツに基づく承認決定をするアプリケーションは、プロキシ証明書経路合法化から生じる主要な用法、拡張主要な用法、およびプロキシ方針のリストを調べて、以下のプロキシ証明書の有効な主要な用法機能を決定しなければなりません:
* If a certificate is a proxy certificate with a proxy policy of
id-ppl-independent or an end entity certificate, the effective key
usage functions of that certificate is as defined by the key usage
and extended key usage extensions in that certificate. The key
usage functionality of the issuer has no bearing on the effective
key usage functionality.
* 証明書がイド人々独立者か終わりの実体証明書のプロキシ方針があるプロキシ証明書であるなら、その証明書の有効な主要な用法機能がその証明書で主要な用法と拡張主要な用法拡大で定義されるようにあります。 発行人の主要な用法の機能性は有効な主要な用法の機能性に堪えることを持っていません。
* If a certificate is a proxy certificate with a policy other than
id-ppl-independent, the effective key usage and extended key usage
functionality of the proxy certificate is the intersection of the
functionality of those extensions in the proxy certificate and the
effective key usage functionality of the proxy issuer.
* 証明書がイド人々独立者以外の方針があるプロキシ証明書であるなら、プロキシ証明書の効果的な主要な用法と拡張主要な用法の機能性はプロキシ証明書のそれらの拡大の機能性とプロキシ発行人の有効な主要な用法の機能性の交差点です。
Tuecke, et al. Standards Track [Page 23] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke、他 規格はX.509プロキシ証明書プロフィール2004年6月にRFC3820を追跡します[23ページ]。
5. Commentary
5. 論評
This section provides non-normative commentary on Proxy Certificates.
このセクションはProxy Certificatesの非標準の論評を提供します。
5.1. Relationship to Attribute Certificates
5.1. 証明書を結果と考える関係
An Attribute Certificate [i3] can be used to grant to one identity, the holder, some attribute such as a role, clearance level, or alternative identity such as "charging identity" or "audit identity". This is accomplished by way of a trusted Attribute Authority (AA), which issues signed Attribute Certificates (AC), each of which binds an identity to a particular set of attributes. Authorization decisions can then be made by combining information from the authenticated End Entity Certificate providing the identity, with the signed Attribute Certificates providing binding of that identity to attributes.
アイデンティティを1つに与えるのに、Attribute Certificate[i3]を使用できます、所有者、役割などの何らかの属性、「アイデンティティを請求します」か「監査のアイデンティティ」などのクリアランスの平らであるか、または代替のアイデンティティ。 これは信じられたAttribute Authority(AA)を通して達成されます。問題はAttribute Certificates(西暦)にAttribute Authorityに署名しました。それはそれぞれ特定のセットの属性へのアイデンティティを縛ります。 次に、アイデンティティを提供する認証されたEnd Entity Certificateから情報を結合することによって、承認決定をすることができます、署名しているAttribute Certificatesがそのアイデンティティの結合を属性に提供していて。
There is clearly some overlap between the capabilities provided by Proxy Certificates and Attribute Certificates. However, the combination of the two approaches together provides a broader spectrum of solutions to authorization in X.509 based systems, than either solution alone. This section seeks to clarify some of the overlaps, differences, and synergies between Proxy Certificate and Attribute Certificates.
明確に、Proxy CertificatesとAttribute Certificatesによって提供された能力の間には、何らかのオーバラップがあります。 しかしながら、一緒に2つのアプローチの組み合わせはX.509のベースのシステムの承認にソリューションの、より広いスペクトルを提供します、単独などちらかのソリューションより。 このセクションはProxy CertificateとAttribute Certificatesの間のオーバラップ、違い、および相乗作用のいくつかをはっきりさせようとします。
5.1.1. Types of Attribute Authorities
5.1.1. 属性当局のタイプ
For the purposes of this discussion, Attribute Authorities, and the uses of the Attribute Certificates that they produce, can be broken down into two broad classes:
この議論の目的のために、Attribute Authorities、および彼らが生産するAttribute Certificatesの用途は2つの広いクラスへ砕けている場合があります:
1) End entity AA: An End Entity Certificate may be used to sign an
AC. This can be used, for example, to allow an end entity to
delegate some of its privileges to another entity.
1) 実体AAを終わらせてください: End Entity Certificateは、西暦に署名するのに使用されるかもしれません。 例えば、終わりの実体が特権のいくつかを別の実体へ代表として派遣するのを許容するのにこれを使用できます。
2) Third party AA: A separate entity, aside from the end entity
involved in an authenticated interaction, may sign ACs in order to
bind the authenticated identity with additional attributes, such
as role, group, etc. For example, when a client authenticates
with a server, the third party AA may provide an AC that binds the
client identity to a particular group, which the server then uses
for authorization purposes.
2) 第三者AA: 認証された相互作用にかかわる終わりの実体は別として、別々の実体は追加属性で認証されたアイデンティティを縛るためにACsに署名するかもしれません、役割、グループなどのように クライアントが例えば、aでサーバ、AAが次に、サーバが承認目的に使用する特定のグループへのクライアントのアイデンティティを縛る西暦を提供するかもしれない第三者を認証すると。
This second type of Attribute Authority, the third party AA, works equally well with an EEC or a PC. For example, unrestricted Proxy Certificates can be used to delegate the EEC's identity to various other parties. Then when one of those other parties uses the PC to authenticate with a service, that service will receive the EEC's
Attribute Authorityのこの2番目のタイプ(第三者AA)はEECかPCで等しくうまくいきます。 例えば、EECのアイデンティティを様々な相手へ代表として派遣するのに無制限なProxy Certificatesを使用できます。 そして、それらの相手のひとりがサービスで認証するPCを使用すると、そのサービスはEECのものを受けるでしょう。
Tuecke, et al. Standards Track [Page 24] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke、他 規格はX.509プロキシ証明書プロフィール2004年6月にRFC3820を追跡します[24ページ]。
identity via the PC, and can apply any ACs that bind that identity to attributes in order to determine authorization rights. Additionally PC with policies could be used to selectively deny the binding of ACs to a particular proxy. An AC could also be bound to a particular PC using the subject or issuer and serial number of the proxy certificate. There would appear to be great synergies between the use of Proxy Certificates and Attribute Certificates produced by third party Attribute Authorities.
PCを通したアイデンティティ、承認権利を決定するために属性へのそのアイデンティティを縛るどんなACsも適用できます。 さらに、選択的に特定のプロキシに対してACsの結合を否定するのに方針があるPCを使用できました。 また、プロキシ証明書の対象か発行人と通し番号を使用する特定のPCに西暦を縛ることができました。 すごい相乗作用は第三者Attribute Authoritiesによって生産されたProxy CertificatesとAttribute Certificatesの使用の間であるように見えるでしょう。
However, the uses of Attribute Certificates that are granted by the first type of Attribute Authority, the end entity AA, overlap considerably with the uses of Proxy Certificates as described in the previous sections. Such Attribute Certificates are generally used for delegation of rights from one end entity to others, which clearly overlaps with the stated purpose of Proxy Certificates, namely single sign-on and delegation.
しかしながら、Attribute Authorityの最初のタイプによって与えられるAttribute Certificatesの用途(終わりの実体AA)は前項で説明されるようにProxy Certificatesの用途にかなり重なります。 一般に、そのようなAttribute Certificatesは片端実体から他のものへの権利の委譲、どれが明確にすなわち、Proxy Certificates、シングルサインオンの述べられた目的に重なるか、そして、および委譲に使用されます。
5.1.2. Delegation Using Attribute Certificates
5.1.2. 属性証明書を使用する委譲
In the motivating example in Section 2, PCs are used to delegate Steve's identity to the various other jobs and entities that need to act on Steve's behalf. This allows those other entities to authenticate as if they were Steve, for example to the mass storage system.
セクション2の動機づけている例では、PCは、スティーブの代理に影響する必要がある他の様々な仕事と実体へスティーブのアイデンティティを代表として派遣するのに使用されます。 これはまるで彼らが例えば、大容量記憶システムへのスティーブであるかのように認証するそれらの他の実体を許容します。
A solution to this example could also be cast using Attribute Certificates that are signed by Steve's EEC, which grant to the other entities in this example the right to perform various operations on Steve's behalf. In this example, the reliable file transfer service and all the hosts involved in file transfers, the starter program, the agent, the simulation jobs, and the post-processing job would each have their own EECs. Steve's EEC would therefore issue ACs to bind each of those other EEC identities to attributes that grant the necessary privileges allow them to, for example, access the mass storage system.
また、この例への解決はこの例でスティーブの代理に様々な操作を実行する権利を他の実体に与えるスティーブのEECによって署名されるAttribute Certificatesを使用しているキャストであるかもしれません。 この例では、信頼できるファイル転送サービス、ファイル転送にかかわるすべてのホスト、スタータープログラム、エージェント、シミュレーション仕事、および後工程仕事はそれぞれそれら自身のEECsを持っているでしょう。 したがって、スティーブのEECは、例えば、アクセスできるそれが必要な特権に大容量記憶システムを与える属性へのそれぞれのそれらの他のEECのアイデンティティを縛るためにACsを発行するでしょう。
However, this AC based solution to delegation has some disadvantages as compared to the PC based solution:
しかしながら、PCと比べて、委譲へのベースのソリューションにはいくつかの損失があるこの西暦はソリューションを基礎づけました:
* All protocols, authentication code, and identity based
authorization services must be modified to understand ACs. With
the PC solution, protocols (e.g., TLS) likely need no
modification, authentication code needs minimal modification
(e.g., to perform PC aware path validation), and identity based
authorization services need minimal modification (e.g., possibly
to find the EEC name and to check for any proxy policies).
* ACsを理解するようにすべてのプロトコル、認証コード、およびアイデンティティに基づいている承認サービスを変更しなければなりません。 PCソリューションで、プロトコル(例えば、TLS)はおそらく変更を全く必要としません、そして、認証コードは最小量の変更(例えばPCの意識している経路合法化を実行する)を必要とします、そして、アイデンティティに基づいている承認サービスは最小量の変更(例えばことによるとEEC名を見つけて、どんなプロキシ方針がないかどうかチェックする)を必要とします。
Tuecke, et al. Standards Track [Page 25] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke、他 規格はX.509プロキシ証明書プロフィール2004年6月にRFC3820を追跡します[25ページ]。
* ACs need to be created by Steve's EEC, which bind attributes to
each of the other identities involved in the distributed
application (i.e., the agent, simulation jobs, and post-processing
job the file transfer service, the hosts transferring files).
This implies that Steve must know in advance which other
identities may be involved in this distributed application, in
order to generate the appropriate ACs which are signed by Steve's
ECC. On the other hand, the PC solution allows for much more
flexibility, since parties can further delegate a PC without a
priori knowledge by the originating EEC.
* ACsは、スティーブのEECによって作成される必要があります。(EECは分配されたアプリケーション(すなわち、エージェント、シミュレーション仕事、およびファイル転送が修理する後工程仕事、ファイルを移すホスト)にかかわるそれぞれの他のアイデンティティに属性を縛ります)。 これは、スティーブが、あらかじめどの他のアイデンティティがこの分配されたアプリケーションにかかわるかもしれないかを知らなければならないのを含意します、スティーブのECCで署名される適切なACsを生成するために。 他方では、PCソリューションはずっと多くの柔軟性を考慮します、パーティーが起因しているEECで先験的な知識なしでPCをさらに代表として派遣することができるので。
There are many unexplored tradeoffs and implications in this discussion of delegation. However, reasonable arguments can be made in favor of either an AC based solution to delegation or a PC based solution to delegation. The choice of which approach should be taken in a given instance may depend on factors such as the software that it needs to be integrated into, the type of delegation required, and other factors.
委譲のこの議論には多くの非探検された見返りと含意があります。 しかしながら、委譲への西暦に基づいているソリューションを支持して合理的な議論をすることができましたか、またはPCはソリューションを委譲に基礎づけました。 アプローチが与えられたインスタンスで取られるべきであるこの選択は統合しているそれが、必要があるソフトウェアや、必要である委譲のタイプや、他の要素などの要素次第であるかもしれません。
5.1.3. Propagation of Authorization Information
5.1.3. 承認情報の伝播
One possible use of Proxy Certificates is to carry authorization information associated with a particular identity.
Proxy Certificatesの1つの活用可能性は特定のアイデンティティに関連している承認情報を運ぶことです。
The merits of placing authorization information into End Entity Certificates (also called a Public Key Certificate or PKC) have been widely debated. For example, Section 1 of "An Internet Attribute Certificate Profile for Authorization" [i3] states:
End Entity Certificates(また、Public Key CertificateかPKCと呼ばれる)への置く承認情報の長所は広く討論されました。 例えば、「承認のためのインターネット属性証明書プロフィール」[i3]のセクション1は以下を述べます。
"Authorization information may be placed in a PKC extension or
placed in a separate attribute certificate (AC). The placement of
authorization information in PKCs is usually undesirable for two
reasons. First, authorization information often does not have the
same lifetime as the binding of the identity and the public key.
When authorization information is placed in a PKC extension, the
general result is the shortening of the PKC useful lifetime.
Second, the PKC issuer is not usually authoritative for the
authorization information. This results in additional steps for
the PKC issuer to obtain authorization information from the
authoritative source.
「承認情報は、PKCの拡大に置かれるか、または別々の属性証明書(西暦)に置かれるかもしれません。」 通常、PKCsの承認情報のプレースメントは2つの理由で望ましくありません。 まず最初に、承認情報には、アイデンティティと公開鍵の結合と同じ寿命がしばしばあるというわけではありません。 承認情報がPKCの拡大に置かれるとき、一般的な結果はPKCの役に立つ生涯の短縮です。 2番目に、承認情報には、通常、PKC発行人は正式ではありません。 PKC発行人が権威筋から承認情報を得るように、これは追加ステップに結果として生じます。
For these reasons, it is often better to separate authorization
information from the PKC. Yet, authorization information also
needs to be bound to an identity. An AC provides this binding; it
is simply a digitally signed (or certified) identity and set of
attributes."
これらの理由で、PKCと承認情報をしばしば切り離すほうがよいです。 しかし、また、承認情報は、アイデンティティに縛られる必要があります。 西暦はこの結合を提供します。 「それは単にデジタルに署名していて(公認される)のアイデンティティとセットの属性です。」
Tuecke, et al. Standards Track [Page 26] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke、他 規格はX.509プロキシ証明書プロフィール2004年6月にRFC3820を追跡します[26ページ]。
Placing authorization information in a PC mitigates the first undesirable property cited above. Since a PC has a lifetime that is mostly independent of (always shorter than) its signing EEC, a PC becomes a viable approach for carrying authorization information for the purpose of delegation.
承認情報をPCに置くと、上で引用された最初の望ましくない特性は緩和されます。 以来、PCにはそれがほとんど独立している寿命がある、(いつもより短い、)、署名EEC、PCは委譲の目的のための承認情報を運ぶための実行可能なアプローチになります。
The second undesirable property cited above is true. If a third party AA is authoritative, then using ACs issued by that third party AA is a natural approach to disseminating authorization information. However, this is true whether the identity being bound by these ACs comes from an EEC (PKC), or from a PC.
上で引用された2番目の望ましくない特性は本当です。 第三者AAが正式であるなら、その第三者AAによって発行されたACsを使用するのは、承認情報を広めることへの自然なアプローチです。 しかしながら、これらのACsによって縛られるアイデンティティがEEC(PKC)か、PCから来るか否かに関係なく、これは本当です。
There is one case, however, that the above text does not consider. When performing delegation, it is usually the EEC itself that is authoritative (not the EEC issuer, or any third party AA). That is, it is up to the EEC to decide what authorization rights it is willing to grant to another party. In this situation, including such authorization information into PCs that are generated by the EEC seems a reasonable approach to disseminating such information.
しかしながら、1つのケースがあって、それはテキストが考えない上記です。 委譲を実行するとき、通常、正式であるのは(EEC発行人でない、またはどんな第三者AAでない)、EEC自身です。 すなわち、どんな承認権利を別のパーティーに与えるかを構わないそれが、思っている決めるのは、EEC次第です。 この状況で、EECによって生成されるPCにそのような承認情報を含めるのはそのような情報を広めることへの合理的なアプローチに見えます。
5.1.4. Proxy Certificate as Attribute Certificate Holder
5.1.4. 属性証明書所有者としてのプロキシ証明書
In a system that employs both PCs and ACs, one can imagine the utility of allowing a PC to be the holder of an AC. This would allow for a particular delegated instance of an identity to be given an attribute, rather than all delegated instances of that identity being given the attribute.
PCとACsの両方を使うシステムでは、人はPCが西暦の所有者であることを許容するユーティリティを想像できます。 これは、属性が属性を与えながらそのアイデンティティのインスタンスをすべて代表として派遣するよりむしろアイデンティティの特定の代表として派遣されたインスタンスに与えられているのを許容するでしょう。
However, the issue of how to specify a PC as the holder of an AC remains open. An AC could be bound to a particular instance of a PC using the unique subject name of the PC, or it's issuer and serial number combination.
しかしながら、西暦の所有者としてどうPCを指定するかに関する問題は開いたままで残っています。 それは、PCのユニークな対象の名前を使用するPCの特定のインスタンスに西暦を縛ることができましたか、発行人と通し番号組み合わせです。
Unrestricted PCs issued by that PC would then inherit those ACs and independent PCs would not. PCs issued with a policy would depend on the policy as to whether or not they inherit the issuing PC's ACs (and potentially which ACs they inherit).
次に、そのPCによって発行された無制限なPCはそれらのACsを引き継ぐでしょう、そして、独立しているPCは引き継がないでしょう。 それらが発行PCのACs(そして、潜在的に彼らが引き継ぐどのACs)を引き継ぐかどうかに関して方針で発行されたPCは方針によるでしょう。
While an AC can be bound to one PC by the AA, how can the AA restrict that PC from passing it on to a subsequently delegated PC? One possible solution would be to define an extension to attribute certificates that allows the attribute authority to state whether an issued AC is to apply only to the particular entity to which it is bound, or if it may apply to PCs issued by that entity.
AAが西暦を1台のPCまで縛ることができる間、AAは、次に代表として派遣されたPCにそれを通過するので、どのようにそのPCを制限できますか? 1つの可能なソリューションは属性証明書への発行された西暦がそれが制限されている特定の実体だけに適用されることになっているかどうか、またはそれがその実体によって発行されたPCに適用されるかもしれないかどうかと述べる属性権威を許容する拡大を定義するだろうことです。
One issue that an AA in this circumstance would need to be aware of is that the PI of the PC that the AA bound the AC to, could issue another PC with the same name as the original PC to a different
意識しているこの状況におけるAAが、必要があるだろう1冊がそれである、AAが西暦を縛ったPCのPI、aに異なったオリジナルのPCと同じ名前で別のPCを発行できました。
Tuecke, et al. Standards Track [Page 27] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke、他 規格はX.509プロキシ証明書プロフィール2004年6月にRFC3820を追跡します[27ページ]。
entity, effectively stealing the AC. This implies that an AA issuing an AC to a PC need to not only trust the entity holding the PC, but the entity holding the PC's issuer as well.
事実上、西暦を横取りする実体。 これは、唯一でないことへのPCの必要性に西暦を発行するAAがPCを保持する実体、しかし、また、PCの発行人を保持する実体を信じるのを含意します。
5.2. Kerberos 5 Tickets
5.2. ケルベロス5チケット
The Kerberos Network Authentication Protocol (RFC 1510 [i6]) is a widely used authentication system based on conventional (shared secret key) cryptography. It provides support for single sign-on via creation of "Ticket Granting Tickets" or "TGT", and support for delegation of rights via "forwardable tickets".
ケルベロスNetwork Authenticationプロトコル(RFC1510[i6])は従来(秘密鍵を共有する)の暗号に基づく広く使用された認証システムです。 それは「前進可能チケット」を通して「チケットを与えるチケット」か"TGT"の作成、および権利の委譲のサポートでシングルサインオンのサポートを提供します。
Kerberos 5 tickets have informed many of the ideas surrounding X.509 Proxy Certificates. For example, the local creation of a short-lived PC can be used to provide single sign-on in an X.509 PKI based system, just as creation of short-lived TGT allows for single sign-on in a Kerberos based system. And just as a TGT can be forwarded (i.e., delegated) to another entity to allow for proxying in a Kerberos based system, so can a PC can be delegated to allow for proxying in an X.509 PKI based system.
ケルベロス5チケットは考えの周囲のX.509 Proxy Certificatesの多くに知らせました。 例えば、X.509 PKIのベースのシステムにシングルサインオンを供給するのに短命なPCの地方の作成を使用できます、ちょうど短命なTGTの作成がケルベロスによるシングルサインオンのためにベースのシステムを許容するように。 そして、ちょうどベースのケルベロスでシステムをproxyingすると考慮するために別の実体にTGTを送ることができるように(すなわち、代表として派遣します)、X.509 PKIのベースのシステムでproxyingすると考慮するのをPCを代表として派遣することができます。
A major difference between a Kerberos TGT and an X.509 PC is that while creation and delegation of a TGT requires the involvement of a third party (Key Distribution Center), a PC can be unilaterally created without the active involvement of a third party. That is, a user can directly create a PC from an EEC for single sign-on capability, without requiring communication with a third party. And an entity with a PC can delegate the PC to another entity (i.e., by creating a new PC, signed by the first) without requiring communication with a third party.
ケルベロスTGTとX.509 PCの主要な違いはTGTの作成と委譲が第三者(主要なDistributionセンター)のかかわり合いを必要としている間第三者のアクティブなかかわり合いなしでPCを一方的に作成できるということです。 すなわち、ユーザはシングルサインオン能力のためにEECからPCを直接作成できます、第三者とのコミュニケーションを必要としないで。 そして、第三者とのコミュニケーションを必要としないで、PCがある実体は別の実体(すなわち、1日までに署名される新しいPCを作成するのによる)へPCを代表として派遣することができます。
The method used by Kerberos implementations to protect a TGT can also be used to protect the private key of a PC. For example, some Unix implementations of Kerberos use standard Unix file system security to protect a user's TGT from compromise. Similarly, the Globus Toolkit's Grid Security Infrastructure implementation of Proxy Certificates protects a user's PC private key using this same approach.
また、PCの秘密鍵を保護するのにケルベロス実装によって使用される、TGTを保護するメソッドは使用できます。 例えば、ケルベロスのいくつかのUnix実装が、感染からユーザのTGTを保護するのに標準のUnixファイルシステムセキュリティを使用します。 同様に、グローバスToolkitのProxy CertificatesのGrid Security Infrastructure実装は、この同じアプローチを使用することでユーザのPC秘密鍵を保護します。
5.3. Examples of usage of Proxy Restrictions
5.3. Proxy Restrictionsの使用法に関する例
This section gives some examples of Proxy Certificate usage and some examples of how the Proxy policy can be used to restrict Proxy Certificates.
このセクションは、Proxy Certificatesを制限するためにProxy Certificate用法に関するいくつかの例とどうProxy方針を使用できるかに関するいくつかの例を出します。
Tuecke, et al. Standards Track [Page 28] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke、他 規格はX.509プロキシ証明書プロフィール2004年6月にRFC3820を追跡します[28ページ]。
5.3.1. Example use of proxies without Restrictions
5.3.1. Restrictionsのないプロキシの例の使用
Steve wishes to perform a third-party FTP transfer between two FTP servers. Steve would use an existing PC to authenticate to both servers and delegate a PC to both hosts. He would inform each host of the unique subject name of the PC given to the other host. When the servers establish the data channel connection to each other, they use these delegated credentials to perform authentication and verify they are talking to the correct entity by checking the result of the authentication matches the name as provided by Steve.
スティーブは2つのFTPサーバの間の第三者FTP転送を実行したがっています。 スティーブは、サーバと代表の両方に両方のホストへのPCを認証するのに既存のコンピュータを使用するでしょう。 彼はもう片方のホストに与えられたPCのユニークな対象の名前について各ホストに知らせるでしょう。 サーバがデータチャンネル接続を互いに確立すると、認証を実行するのにこれらの代表として派遣された資格証明書を使用する、検証、それらはスティーブによって提供されるように認証の結果をチェックするのによる正しい実体への話が名前に合っているということです。
5.3.2. Example use of proxies with Restrictions
5.3.2. Restrictionsとのプロキシの例の使用
Steve wishes to delegate to a process the right to perform a transfer of a file from host H1 to host H2 on his behalf. Steve would delegate a PC to the process and he would use Proxy Policy to restrict the delegated PC to two rights - the right to read file F1 on host H1 and the right to write file F2 on host H2.
スティーブはホストH1からホストH2まで彼の代理にファイルの転送を実行する権利をプロセスへ代表として派遣したがっています。 彼は代表として派遣されたPCを2つの権利に制限するのにProxy Policyを使用するでしょう--スティーブがPCをプロセスへ代表として派遣して、ホストH1でファイルF1を読む権利とホストH2の上のファイルF2に書く権利。
The process then uses this restricted PC to authenticate to servers H1 and H2. The process would also delegate a PC to both servers. Note that these delegated PCs would inherit the restrictions of their parents, though this is not relevant to this example. As in the example in the previous Section, each host would be provided with the unique name of the PC given to the other server.
そして、プロセスは、H1とH2をサーバに認証するのにこの制限されたPCを使用します。 また、プロセスは両方のサーバへPCを代表として派遣するでしょう。 これはこの例に関連していませんが、これらがPCを代表として派遣したというメモは彼らの両親の制限を引き継ぐでしょう。 前のセクションの例のように、もう片方のサーバに与えられたPCのユニークな名前を各ホストに提供するでしょう。
Now when the process issues the command to transfer the file F1 on H1 and to F2 on H2, these two servers perform an authorization check based on the restrictions in the PC that the process used to authenticate with them (in addition to any local policy they have). Namely H1 checks that the PC gives the user the right to read F1 and H2 checks that the PC gives the user the right to write F2. When setting up the data channel the servers would again verify the names resulting from the authentication match the names provided by Steve as in the example in the previous Section.
プロセスがH2でH1の上と、そして、F2にファイルF1を移すコマンドを発行するとき、今、これらの2つのサーバがプロセスが以前はよくそれら(それらが持っているどんなローカルの方針に加えた)で認証していたPCで制限に基づく許可検査を実行します。 すなわち、H1は、PCがF1を読む権利をユーザに与えるのをチェックします、そして、H2はPCがF2に書く権利をユーザに与えるのをチェックします。 サーバが再び確かめるデータ・チャンネルをセットアップするとき、認証から生じる名前は前のセクションの例のようにスティーブによって提供された名前に合っています。
The extra security provided by these restrictions is that now if the PC delegated to the process by Steve is stolen, its use is greatly limited.
これらの制限で提供された特別なセキュリティはスティーブによってプロセスへ代表として派遣されたPCが盗まれるなら、現在使用が大いに制限されるということです。
5.4. Delegation Tracing
5.4. 委譲のたどること
A relying party accepting a Proxy Certificate may have an interest in knowing which parties issued earlier Proxy Certificates in the certificate chain and to whom they delegated them. For example it may know that a particular service or resource is known to have been
どのパーティーが証明書チェーンで以前のProxy Certificatesを発行したか、そして、彼らが彼らをだれへ代表として派遣したかを知るのにProxy Certificateを受け入れる信用パーティーは関心を持っているかもしれません。 例えば、それは、そのa特定のサービスかリソースによる知られているのを知るかもしれません。
Tuecke, et al. Standards Track [Page 29] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke、他 規格はX.509プロキシ証明書プロフィール2004年6月にRFC3820を追跡します[29ページ]。
compromised and if any part of a Proxy Certificate's chain was issued to the compromised service a relying party may wish to disregard the chain.
感染されて、何かProxy Certificateのチェーンの部分が感染しているサービスに発行されたなら、信用パーティーはチェーンを無視したがっているかもしれません。
A delegation tracing mechanism was considered by the authors as additional information to be carried in the ProxyCertInfo extension. However at this time agreement has not been reached as to what this information should include so it was left out of this document, and will instead be considered in future revisions. The debate mainly centers on whether the tracing information should simply contain the identity of the issuer and receiver or it should also contain all the details of the delegated proxy and a signed statement from the receiver that the proxy was actually acceptable to it.
ProxyCertInfo拡張子で委譲追跡メカニズムが運ばれると追加情報としての作者によって考えられました。 どんなにこのときこの情報が含むべきであることに関して合意に達しないでも、したがって、それは、このドキュメントから残されて、代わりに今後の改正で考えられるでしょう。 討論は、追跡情報が単に発行人と受信機のアイデンティティを含むべきであるか、またはまた、それがプロキシが実際にそれに許容できたという代表として派遣されたプロキシと受信機からの署名している声明に関する一部始終を含むべきであるかに主に集中します。
5.4.1. Site Information in Delegation Tracing
5.4.1. 委譲のたどることにおけるサイト情報
In some cases, it may be desirable to know the hosts involved in a delegation transaction (for example, a relying party may wish to reject proxy certificates that were created on a specific host or domain). An extension could be modified to include the PA's and Acceptor's IP addresses; however, IP addresses are typically easy to spoof, and in some cases the two parties to a transaction may not agree on the IP addresses being used (e.g., if the Acceptor is on a host that uses NAT, the Acceptor and the PA may disagree about the Acceptor's IP address).
いくつかの場合、委譲トランザクションにかかわるホストを知るのは望ましいかもしれません(例えば、信用パーティーは特定のホストかドメインで作成されたプロキシ証明書を拒絶したがっているかもしれません)。 PAとAcceptorのIPアドレスを含むように拡大を変更できました。 しかしながら、IPアドレスは通常偽造しやすいです、そして、いくつかの場合、2回の取引の当事者は使用されるIPアドレスに同意しないかもしれません(例えば、NATを使用するホストの上にAcceptorがあるなら、AcceptorとPAはAcceptorのIPアドレスについて異なる意見をもつかもしれません)。
Another suggestion was, in those cases where domain information is needed, to require that the subject names of all End Entities involved (the Acceptor(s) and the End Entity that appears in a PC's certificate path) include domain information.
別の提案はそうでした、ドメイン情報がEnd Entitiesがかかわったすべて(Acceptor(s)とPCの証明書経路に現れるEnd Entity)の対象の名前がドメイン情報を含むのが必要であるのに必要であるそれらの場合で。
6. Security Considerations
6. セキュリティ問題
In this Section we discuss security considerations related to the use of Proxy Certificates.
このセクションでは、私たちはProxy Certificatesの使用に関連するセキュリティ問題について議論します。
6.1. Compromise of a Proxy Certificate
6.1. プロキシ証明書の感染
A Proxy Certificate is generally less secure than the EEC that issued it. This is due to the fact that the private key of a PC is generally not protected as rigorously as that of the EEC. For example, the private key of a PC is often protected using only file system security, in order to allow that PC to be used for single sign-on purposes. This makes the PC more susceptible to compromise.
一般に、Proxy Certificateはそれを発行したEECほど安全ではありません。 これは一般に、PCの秘密鍵がEECのものできびしく保護されないという事実のためです。 例えば、PCの秘密鍵はファイルシステムセキュリティだけを使用することでしばしば保護されます、そのPCがシングルサインオン目的に使用されるのを許容するために。 これで、PCは感染するのにおいて、より影響されやすくなります。
However, the risk of a compromised PC is only the misuse of a single user's privileges. Due to the PC path validation checks, a PC cannot be used to sign an EEC or PC for another user.
しかしながら、感染しているPCの唯一のリスクはシングルユーザーの特権の誤用です。 PC経路合法化チェックのため、別のユーザのためにEECかPCに署名するのにPCを使用できません。
Tuecke, et al. Standards Track [Page 30] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke、他 規格はX.509プロキシ証明書プロフィール2004年6月にRFC3820を追跡します[30ページ]。
Further, a compromised PC can only be misused for the lifetime of the PC, and within the bound of the restriction policy carried by the PC. Therefore, one common way to limit the misuse of a compromised PC is to limit its validity period to no longer than is needed, and/or to include a restriction policy in the PC that limits the use of the (compromised) PC.
さらに、PCの生涯、PCによって運ばれた制限方針のバウンドの中で感染しているPCを誤用できるだけです。 したがって、感染しているPCの誤用を制限する1つの一般的な方法が必要とされるほど有効期間をもう制限しないことであり、PCに制限方針を含むように、それは(妥協します)PCの使用を制限します。
In addition, if a PC is compromised, it does NOT compromise the EEC that created the PC. This property is of great utility in protecting the highly valuable, and hard to replace, public key of the EEC. In other words, the use of Proxy Certificates to provide single sign-on capabilities in an X.509 PKI environment can actually increase the security of the end entity certificates, because creation and use of the PCs for user authentication limits the exposure of the EEC private key to only the creation of the first level PC.
さらに、PCが感染されるなら、それはPCを作成したEECに感染しません。 この特性が取り替える非常に貴重で、および困難を保護することにおいて、すばらしいユーティリティのものである、EECの公開鍵。 言い換えれば、シングルサインオン能力をX.509 PKI環境に提供するProxy Certificatesの使用は実際に終わりの実体証明書のセキュリティを増強できます、PCのユーザー認証の作成と使用がEEC秘密鍵の暴露を最初の平らなPCの作成だけに制限するので。
6.2. Restricting Proxy Certificates
6.2. プロキシ証明書を制限します。
The pCPathLenConstraint field of the proxyCertInfo extension can be used by an EEC to limit subsequent delegation of the PC. A service may choose to only authorize a request if a valid PC can be delegated to it. An example of such as service is a job starter, which may choose to reject a job start request if a valid PC cannot be delegated to it. By limiting the pCPathLenConstraint, an EEC can ensure that a compromised PC of one job cannot be used to start additional jobs elsewhere.
EECは、PCのその後の委譲を制限するのにproxyCertInfo拡張子のpCPathLenConstraint分野を使用できます。 有効なPCをそれへ代表として派遣することができるなら、サービスは、要求を認可するだけであるのを選ぶかもしれません。 サービスとしてのそのようなものに関する例は仕事のスターターです。(有効なPCをそれへ代表として派遣することができないなら、そのスターターは仕事のスタート要求を拒絶するのを選ぶかもしれません)。 pCPathLenConstraintを制限することによって、EECは、ほかの場所で追加仕事を始めるのに1つの仕事の感染しているPCを使用できないのを確実にすることができます。
An EEC or PC can limit what a new PC can be used for by turning off bits in the Key Usage and Extended Key Usage extensions. Once a key usage or extended key usage has been removed, the path validation algorithm ensures that it cannot be added back in a subsequent PC. In other words, key usage can only be decreased in PC chains.
EECかPCがKey UsageとExtended Key Usage拡張子でビットをオフにすることによって新しいPCを使用できることを制限できます。 いったん主要な用法か拡張主要な用法を取り除くと、経路合法化アルゴリズムは、その後のPCでそれを加えることができないのを確実にします。 言い換えれば、主要な用法はPCチェーンで減少できるだけです。
The EEC could use the CRL Distribution Points extension and/or OCSP to take on the responsibility of revoking PCs that it had issued, if it felt that they were being misused.
EECはそれが支給したPCを取り消す責任を引き受けるのにCRL Distribution Points拡張子、そして/または、OCSPを使用できました、それらが誤用されていたと感じたなら。
6.3. Relying Party Trust of Proxy Certificates
6.3. パーティが信じるプロキシ証明書の信用
The relying party that is going to authorize some actions on the basis of a PC will be aware that it has been presented with a PC, and can determine the depth of the delegation and the time that the delegation took place. It may want to use this information in addition to the information from the signing EEC. Thus a highly secure resource might refuse to accept a PC at all, or maybe only a single level of delegation, etc.
PCに基づいていくつかの動作を認可する信用パーティーは代表団が行われたのが、PCを与えて、代表団と現代の深さを測定できるのを意識するでしょう。 それは調印EECからの情報に加えたこの情報を使用したがっているかもしれません。 したがって、非常に安全なリソースは、全くPC、または多分ただ一つのレベルだけの代表団などを受け入れるのを拒否するかもしれません。
Tuecke, et al. Standards Track [Page 31] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke、他 規格はX.509プロキシ証明書プロフィール2004年6月にRFC3820を追跡します[31ページ]。
The relying party should also be aware that since the policy restricting the rights of a PC is the intersection of the policy of all the PCs in it's certificate chain, this means any change in the certificate chain can effect the policy of the PC. Since there is no mechanism in place to enforce unique subject names of PCs, if an issuer were to issue two PCs with identical names and keys, but different rights, this could allow the two PCs to be substituted for each other in path validation and effect the rights of a PC down the chain. Ultimately, this means the relying party places trust in the entities that are acting as Proxy Issuers in the chain to behave properly.
また、信用パーティーもPCの権利を制限する方針がそれのすべてのPCの方針の交差点であるのでそれが証明書チェーンである、これが証明書チェーンにおけるどんな変化もPCの方針に作用できることを意味するのを意識しているべきです。 発行人が同じ名前としかし、キー、異なった権利がある2PCを支給するつもりであったならPCのユニークな対象の名前を実施するためにメカニズムが全く適所にないので、これで、2PCが経路合法化における互いに代入されて、PCの権利にチェーンの下側に作用するかもしれません。 結局、これはパーティー場所がProxy Issuersとしてチェーンで機能している実体で礼儀正しく振る舞うと信じる信用を意味します。
6.4. Protecting Against Denial of Service with Key Generation
6.4. キー生成と共にサービス妨害から守ります。
As discussed in Section 2.3, one of the motivations for Proxy Certificates is to allow for dynamic delegation between parties. This delegation potentially requires, by the party receiving the delegation, the generation of a new key pair which is a potentially computationally expensive operation. Care should be taken by such parties to prevent another entity from performing a denial of service attack by causing them to consume large amount of resource doing key generation.
セクション2.3で議論するように、Proxy Certificatesに関する動機の1つはパーティーの間でダイナミックな代表団を考慮することです。 この代表団は代表団を受けるパーティーで潜在的に潜在的に計算上高価な操作である新しい主要な組の世代を必要とします。 そのようなパーティーは、彼らが多量のリソースするキー生成を消費することを引き起こすことによって別の実体がサービス不能攻撃を実行するのを防ぐために注意するべきです。
A general guideline would always to perform authentication of the delegating party to prevent such attacks from being performed anonymously. Another guideline would be to maintain some state to detect and prevent such attacks.
一般的ガイドラインはいつもそうするでしょう。そのような攻撃が匿名で実行されるのを防ぐために代表として派遣するパーティーの認証を実行するために。 別のガイドラインはそのような攻撃を検出して、防ぐために何らかの状態を維持するだろうことです。
6.5. Use of Proxy Certificates with a Central Repository
6.5. 中央倉庫とのプロキシ証明書の使用
As discussed in Section 2.7, one potential use of Proxy Certificates is to ease certificate management for end users by storing the EEC private keys and certificates in a centrally managed repository. When a user needs a PKI credential, the user can login to the repository using name/password, one time password, etc. and the repository would then delegate a PC to the user with proxy rights, but continue to protect the EEC private key in the repository.
セクション2.7、1で議論するように、Proxy Certificatesの潜在的使用はエンドユーザのために中心で管理された倉庫にEEC秘密鍵と証明書を格納することによって証明書管理を緩和することです。 ユーザがPKI信任状を必要とすると、ユーザは名前/パスワードを使用することで倉庫にログインできますが、次に、使い捨てパスワード、など、および倉庫はプロキシ権利をもっているユーザへPCを代表として派遣するでしょうが、倉庫にEEC秘密鍵を保護し続けてください。
Care must be taken with this approach since compromise of the repository will potentially give the attacker access to the long-term private keys stored in the repository. It is strongly suggested that some form of hardware module be used to store the long-term private keys, which will serve to help prevent their direct threat though it may still allow a successful attacker to use the keys while the repository is compromised to sign arbitrary objects (including Proxy Certificates).
倉庫の妥協が潜在的に倉庫に格納された長期の秘密鍵への攻撃者アクセスを与えるので、このアプローチで注意しなければなりません。 何らかのフォームのハードウェアモジュールが倉庫が任意の物にサインするために妥協している間(Proxy Certificatesを含んでいて)うまくいっている攻撃者がそれでまだキーを使用できるかもしれませんが、彼らの直接的な脅威を防ぐのを助けるのに役立つ長期の秘密鍵を格納するのに使用されることが強く提案されます。
Tuecke, et al. Standards Track [Page 32] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke、他 規格はX.509プロキシ証明書プロフィール2004年6月にRFC3820を追跡します[32ページ]。
7. IANA Considerations
7. IANA問題
IANA has established a registry for policy languages. Registration under IETF space is by IETF standards action as described in [i8]. Private policy languages should be under organizational OIDs; policy language authors are encouraged to list such languages in the IANA registry, along with a pointer to a specification.
IANAは方針言語のために登録を確立しました。 IETFスペースの下における登録が[i8]で説明されるようにIETF規格動作であります。 組織的なOIDsの下に個人的な方針言語があるべきです。 方針言語作者がポインタをもってIANA登録にそのような言語を仕様に記載するよう奨励されます。
OID Description --- ----------- 1.3.6.1.5.5.7.21.1 id-ppl-inheritALL 1.3.6.1.5.5.7.21.2 id-ppl-independent
OID記述--- ----------- 1.3.6.1.5.5.7.21.1、イド人々inheritALL、1.3.6.1.5.5.7.21.2イド人々独立者
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[n1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[n1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[n2] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[n2] Housley、R.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
8.2. Informative References
8.2. 有益な参照
[i1] Butler, R., Engert, D., Foster, I., Kesselman, C., and S.
Tuecke, "A National-Scale Authentication Infrastructure",
IEEE Computer, vol. 33, pp. 60-66, 2000.
[i1] バトラー、R.、Engert、D.、フォスター、I.、ケッセルマン、C.、およびS.Tuecke、「国家のスケール認証インフラストラクチャ」、IEEEコンピュータ、vol.33、ページ 60-66, 2000.
[i2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[i2] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[i3] Farrell, S. and R. Housley, "An Internet Attribute
Certificate Profile for Authorization", RFC 3281, April 2002.
[i3]ファレルとS.とR.Housley、「認可のためのインターネット属性証明書プロフィール」、RFC3281、2002年4月。
[i4] Foster, I., Kesselman, C., Tsudik, G., and S. Tuecke, "A
Security Architecture for Computational Grids", presented at
Proceedings of the 5th ACM Conference on Computer and
Communications Security, 1998.
フォスター、I.、ケッセルマン、C.、Tsudik、G.、およびS.Tuecke、「コンピュータの格子のためのセキュリティー体系」がコンピュータの上に第5ACMコンファレンスのProceedingsに提示した[i4]とCommunications Security、1998。
[i5] Foster, I., Kesselman, C., and S. Tuecke, "The Anatomy of the
Grid: Enabling Scalable Virtual Organizations", International
Journal of Supercomputer Applications, 2001.
[i5] フォスター、I.、ケッセルマン、C.、およびS.Tuecke、「格子の検査:」 「スケーラブルなバーチャル・オーガニゼーションを可能にします」、スーパーコンピュータアプリケーション、2001年の国際ジャーナル。
[i6] Kohl, J. and C. Neuman, "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993.
[i6]コールとJ.とC.ヌーマン、「ケルベロスネットワーク認証サービス(V5)」、RFC1510 1993年9月。
Tuecke, et al. Standards Track [Page 33] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke、他 規格はX.509プロキシ証明書プロフィール2004年6月にRFC3820を追跡します[33ページ]。
[i7] Neuman, B. Clifford, "Proxy-Based Authorization and
Accounting for Distributed Systems", In Proceedings of the
13th International Conference on Distributed Computing
Systems, pages 283-291, May 1993.
[i7]ヌーマン、B.クリフォード、「分散システムのためのプロキシベースの認可と会計」(Distributed Computing Systemsの上の第13国際コンファレンスのIn Proceedings)は283-291を呼び出します、1993年5月。
[i8] Narten, T. and H. Alvestrand. "Guidelines for Writing an IANA
Considerations Section in RFC", RFC 2434, October 1998.
[i8] Narten、T.、およびH.Alvestrand。 「IANAに問題を書くためのガイドラインは中でRFCを区分する」RFC2434、1998年10月。
9. Acknowledgments
9. 承認
We are pleased to acknowledge significant contributions to this document by David Chadwick, Ian Foster, Jarek Gawor, Carl Kesselman, Sam Meder, Jim Schaad, and Frank Siebenlist.
私たちは、デヴィッドChadwick、イアン・フォスター、Jarek Gawor、カール・ケッセルマン、サムMeder、ジムSchaad、およびフランクSiebenlistによるこのドキュメントへの重要な貢献を承諾して、うれしく思います。
We are grateful to numerous colleagues for discussions on the topics covered in this paper, in particular (in alphabetical order, with apologies to anybody we've missed): Carlisle Adams, Joe Bester, Randy Butler, Keith Jackson, Steve Hanna, Russ Housley, Stephen Kent, Bill Johnston, Marty Humphrey, Sam Lang, Ellen McDermott, Clifford Neuman, Gene Tsudik.
私たちはこの紙でカバーされた話題についての議論に多数の同僚に感謝しています、特に(アルファベット順に、だれもを無断借用させてもらって、私たちは消えました): カーライルアダムス、ジョー・ベスター、ランディ・バトラー、キース・ジャクソン、スティーブ・ハンナ、ラスHousley、スティーブン・ケント・ビル・ジョンストン、マーティ・ハンフリー、サム・ラング、エレン・マクダーモット、クリフォード・ヌーマン(遺伝子Tsudik)。
We are also grateful to members of the Global Grid Forum (GGF) Grid Security Infrastructure working group (GSI-WG), and the Internet Engineering Task Force (IETF) Public-Key Infrastructure (X.509) working group (PKIX) for feedback on this document.
また、私たちもGlobal Grid Forum(GGF)格子Security Infrastructureワーキンググループのメンバー(GSI-WG)、およびこのドキュメントのフィードバックのためのインターネット・エンジニアリング・タスク・フォース(IETF)公開鍵暗号基盤(X.509)ワーキンググループ(PKIX)に感謝しています。
This work was supported in part by the Mathematical, Information, and Computational Sciences Division subprogram of the Office of Advanced Scientific Computing Research, U.S. Department of Energy, under Contract W-31-109-Eng-38 and DE-AC03-76SF0098; by the Defense Advanced Research Projects Agency under contract N66001-96-C-8523; by the National Science Foundation; and by the NASA Information Power Grid project.
この仕事はMathematical、情報、およびAdvanced Scientific Computing Research、米国エネルギー省のオフィスのComputational Sciences事業部副プログラムで一部後押しされていました、Contract W-31-109エング38とDE-AC03-76SF0098の下で。 契約N66001 96C8523に基づく国防高等研究計画庁で。 国立科学財団で。 そして、NASA情報で、Power Gridは突出します。
Tuecke, et al. Standards Track [Page 34] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke、他 規格はX.509プロキシ証明書プロフィール2004年6月にRFC3820を追跡します[34ページ]。
Appendix A. 1988 ASN.1 Module
付録A.1988ASN.1モジュール
PKIXproxy88 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
proxy-cert-extns(25) }
PKIXproxy88iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)プロキシ本命extns(25)
DEFINITIONS EXPLICIT TAGS ::=
定義、明白なタグ:、:=
BEGIN
始まってください。
-- EXPORTS ALL --
-- すべてを輸出します--
-- IMPORTS NONE --
-- なにも輸入しません--
-- PKIX specific OIDs
-- PKIXの特定のOIDs
id-pkix OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
イド-pkix OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)
-- private certificate extensions
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
-- 個人的な証明書拡大イド-pe OBJECT IDENTIFIER:、:= イド-pkix1
-- Locally defined OIDs
-- 局所的に定義されたOIDs
-- The proxy certificate extension
id-pe-proxyCertInfo OBJECT IDENTIFIER ::= { id-pe 14 }
-- プロキシ証明書拡張子イド-pe-proxyCertInfo OBJECT IDENTIFIER:、:= イド-pe14
-- Proxy certificate policy languages
id-ppl OBJECT IDENTIFIER ::= { id-pkix 21 }
-- プロキシ証明書方針言語イド人々OBJECT IDENTIFIER:、:= イド-pkix21
-- Proxy certificate policies languages defined in
id-ppl-anyLanguage OBJECT IDENTIFIER ::= { id-ppl 0 }
id-ppl-inheritAll OBJECT IDENTIFIER ::= { id-ppl 1 }
id-ppl-independent OBJECT IDENTIFIER ::= { id-ppl 2 }
-- プロキシ証明書方針言語が中で定義した、イド人々anyLanguage OBJECT IDENTIFIER、:、:= イド人々0、イド人々inheritAll OBJECT IDENTIFIER、:、:= イド人々1イド人々独立者OBJECT IDENTIFIER:、:= イド人々2
-- The ProxyCertInfo Extension
ProxyCertInfoExtension ::= SEQUENCE {
pCPathLenConstraint ProxyCertPathLengthConstraint
OPTIONAL,
proxyPolicy ProxyPolicy }
-- ProxyCertInfo拡大ProxyCertInfoExtension:、:= 系列pCPathLenConstraint ProxyCertPathLengthConstraint任意である、proxyPolicy ProxyPolicy
ProxyCertPathLengthConstraint ::= INTEGER
ProxyPolicy ::= SEQUENCE {
policyLanguage OBJECT IDENTIFIER,
policy OCTET STRING OPTIONAL }
ProxyCertPathLengthConstraint:、:= 整数ProxyPolicy:、:= 系列policyLanguage OBJECT IDENTIFIER、方針OCTET STRING OPTIONAL
END
終わり
Tuecke, et al. Standards Track [Page 35] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke、他 規格はX.509プロキシ証明書プロフィール2004年6月にRFC3820を追跡します[35ページ]。
Authors' Addresses
作者のアドレス
Steven Tuecke Distributed Systems Laboratory Mathematics and Computer Science Division Argonne National Laboratory Argonne, IL 60439
スティーブンTuecke分散システム研究所数学とコンピュータサイエンス事業部アルゴンヌ国立研究所アルゴンヌ、イリノイ 60439
Phone: 630-252-8711 EMail: tuecke@mcs.anl.gov
以下に電話をしてください。 630-252-8711 メールしてください: tuecke@mcs.anl.gov
Von Welch National Center for Supercomputing Applications University of Illinois
イリノイのフォンウェルチ国立スーパーコンピューター応用研究所大学
EMail: vwelch@ncsa.uiuc.edu
メール: vwelch@ncsa.uiuc.edu
Doug Engert Argonne National Laboratory
ダグEngertアルゴンヌ国立研究所
EMail: deengert@anl.gov
メール: deengert@anl.gov
Laura Pearlman University of Southern California, Information Sciences Institute
南カリフォルニアのローラパールマン大学、科学が設ける情報
EMail: laura@isi.edu
メール: laura@isi.edu
Mary Thompson Lawrence Berkeley National Laboratory
メアリ・トンプソンローレンス・バークレー国家の研究所
EMail: mrthompson@lbl.gov
メール: mrthompson@lbl.gov
Tuecke, et al. Standards Track [Page 36] RFC 3820 X.509 Proxy Certificate Profile June 2004
Tuecke、他 規格はX.509プロキシ証明書プロフィール2004年6月にRFC3820を追跡します[36ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Tuecke, et al. Standards Track [Page 37]
Tuecke、他 標準化過程[37ページ]
一覧
スポンサーリンク
