RFC2692 日本語訳
2692 SPKI Requirements. C. Ellison. September 1999. (Format: TXT=29569 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Ellison Request for Comments: 2692 Intel Category: Experimental September 1999
コメントを求めるワーキンググループC.エリソン要求をネットワークでつないでください: 2692年のインテルカテゴリ: 実験的な1999年9月
SPKI Requirements
SPKI要件
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
The IETF Simple Public Key Infrastructure [SPKI] Working Group is tasked with producing a certificate structure and operating procedure to meet the needs of the Internet community for trust management in as easy, simple and extensible a way as possible.
IETF Simple公開鍵暗号基盤[SPKI]作業部会は信頼管理のために簡単で、簡単でできるだけ広げることができる方法でインターネットコミュニティの需要を満たすために証明書構造と操作手順を作成するのに仕事を課されます。
The SPKI Working Group first established a list of things one might want to do with certificates (attached at the end of this document), and then summarized that list of desires into requirements. This document presents that summary of requirements.
SPKI作業部会は最初に、人が証明書(このドキュメントの端では、付く)を処理したがっているかもしれなくて、その時がまとめた記載する願望のことのリストを要件に確立しました。 このドキュメントは要件のその概要を提示します。
Table of Contents
目次
Charter of the SPKI working group................................2 Background.......................................................2 General Requirements.............................................3 Validity and CRLs................................................4 Implementation of Certificates...................................4 List of Certificate Uses.........................................5 Open Questions..................................................11 References......................................................12 Security Considerations.........................................12 Author's Address................................................13 Full Copyright Statement........................................14
SPKIワーキンググループの憲章…2バックグラウンド…2つの一般要件…3正当性とCRLs…証明書の4実装…証明書用途の4リスト…5 質問を開いてください…11の参照箇所…12 セキュリティ問題…12作者のアドレス…13 完全な著作権宣言文…14
Ellison Experimental [Page 1] RFC 2692 SPKI Requirements September 1999
[1ページ]RFC2692SPKI要件1999年9月に実験的なエリソン
Charter of the SPKI working group
SPKIワーキンググループの憲章
Many Internet protocols and applications which use the Internet employ public key technology for security purposes and require a public key infrastructure to manage public keys.
多くのインターネットプロトコルとインターネットを使用するアプリケーションは、セキュリティ目的に公開鍵技術を使って、公開鍵を管理するために公開鍵認証基盤を必要とします。
The task of the working group will be to develop Internet standards for an IETF sponsored public key certificate format, associated signature and other formats, and key acquisition protocols. The key certificate format and associated protocols are to be simple to understand, implement, and use. For purposes of the working group, the resulting formats and protocols are to be known as the Simple Public Key Infrastructure, or SPKI.
ワーキンググループに関するタスクはIETFのインターネット標準を開発するのが公開鍵証明書形式、関連署名、他の形式、および主要な獲得プロトコルを保証したということでしょう。 主要な証明書形式と関連プロトコルは理解して、実装して、使用するのが簡単であることです。 ワーキンググループの目的のために、結果として起こる形式とプロトコルはSimple公開鍵基盤、またはSPKIとして知られていることです。
The SPKI is intended to provide mechanisms to support security in a wide range of Internet applications, including IPSEC protocols, encrypted electronic mail and WWW documents, payment protocols, and any other application which will require the use of public key certificates and the ability to access them. It is intended that the Simple Public Key Infrastructure will support a range of trust models.
SPKIがさまざまなインターネットアプリケーションにおけるセキュリティをサポートするためにメカニズムを提供することを意図します、IPSECプロトコル、暗号化された電子メール、WWWドキュメント、支払いプロトコル、公開鍵証明書の使用を必要とするいかなる他のアプリケーション、およびそれらにアクセスする能力も含んでいて。 Simple公開鍵暗号基盤が、さまざまな信頼がモデルであるとサポートすることを意図します。
Background
バックグラウンド
The term certificate traces back to the MIT bachelor's thesis of Loren M. Kohnfelder [KOHN]. Kohnfelder, in turn, was responding to a suggestion by Diffie and Hellman in their seminal paper [DH]. Diffie and Hellman noted that with public key cryptography, one no longer needs a secure channel over which to transmit secret keys between communicants. Instead, they suggested, one can publish a modified telephone book -- one with public keys in place of telephone numbers. One could then look up his or her desired communication partner in the directory, find that person's public key and open a secure channel to that person. Kohnfelder took that suggestion and noted that an on-line service has the disadvantage of being a performance bottleneck. To replace it, he proposed creation of digitally signed directory entries which he called certificates. In the time since 1978, the term certificate has frequently been assumed to mean a binding between name and key.
定期預金証書はMITの独身のロレーンM.Kohnfelder[コーン]の論文を突きとめます。 Kohnfelderはそれらの精液の紙[DH]で順番にディフィーとヘルマンによる勧めに応じていました。 ディフィーとヘルマンは、公開鍵暗号で、人がもう、聖餐拝受者の間に秘密鍵を送る安全なチャンネルを必要としないことに注意しました。 彼らは、人が代わりに変更された電話帳を発行できるのを示しました--電話番号に代わった公開鍵がある1。 人は、その人に次に、ディレクトリでその人の必要なコミュニケーションパートナーを訪ねて、その人の公開鍵を見つけて、安全なチャンネルを公開できました。 Kohnfelderは、その提案を取って、パソコン通信には性能のネックである不都合があることに注意しました。 それを取り替えるために、彼は彼が証明書と呼んだデジタルに署名しているディレクトリエントリーの作成を提案しました。 1978年以来の時間、頻繁に定期預金証書が名前とキーの間の結合を意味すると思われています。
The SPKI team directly addressed the issue of <name,key> bindings and realized that such certificates are of extremely limited use for trust management. A keyholder's name is one attribute of the keyholder, but as can be seen in the list of needs in this document, a person's name is rarely of security interest. A user of a certificate needs to know whether a given keyholder has been granted some specific authorization.
SPKIチームは、直接<名、主要な>結合の問題を扱って、そのような証明書が信頼管理について非常に限られて役に立つとわかりました。 keyholderの名前はkeyholderの1つの属性ですが、必要性のリストで本書では見ることができるように、めったに人の名前は動産担保権のものではありません。 証明書のユーザは、何らかの特定の承認が与えられたkeyholderに与えられたかどうかを知る必要があります。
Ellison Experimental [Page 2] RFC 2692 SPKI Requirements September 1999
[2ページ]RFC2692SPKI要件1999年9月に実験的なエリソン
General Requirements
一般要件
We define the term KEYHOLDER of a public key to refer to the person or other entity that controls the corresponding private key.
私たちは、対応する秘密鍵を制御する人か他の実体について言及するためにKEYHOLDERという公開鍵の用語を定義します。
The main purpose of an SPKI certificate is to authorize some action, give permission, grant a capability, etc. to or for a keyholder.
SPKI証明書の主な目的は、keyholderかkeyholderのために何らかの動作を認可して、許可して、能力を与えるなどことです。
The keyholder is most directly identified by the public key itself, although for convenience or other purposes some indirection (delayed binding) may be employed. That indirection can be via a collision- free hash of the public key or via a name, later to be resolved into a key.
keyholderは公開鍵自体によって最も直接特定されます、何らかの間接指定(付くのを遅らせる)が便宜か他の目的に使われるかもしれませんが。 その間接指定は、後でキーに変えられるのに公開鍵の衝突の自由なハッシュか名前を使用できます。
The definition of attributes or authorizations in a certificate is up to the author of code which uses the certificate. The creation of new authorizations should not require interaction with any other person or organization but rather be under the total control of the author of the code using the certificate.
証明書の属性か承認の定義は証明書を使用するコードの作者次第です。 新しい承認の作成は、いかなる他の人か組織と共にも相互作用を必要としませんが、むしろ証明書を使用することでコードの作者の総コントロールの下にあるべきです。
Because SPKI certificates might carry information that the keyholder might not want to publish, we assume that certificates will be distributed directly by the keyholder to the verifier. If the keyholder wishes to use a global repository, such as LDAP, the global PGP key server or the DNS database, that is up to the keyholder and not for the SPKI WG to specify.
SPKI証明書がkeyholderが発行したがっていないかもしれないという情報を載せるかもしれないので、私たちは、証明書が直接keyholderによって検証に配布されると思います。 keyholderがLDAP、グローバルなPGP主要なサーバまたはDNSデータベースなどのグローバルな倉庫を使用したいと思うなら、それは、指定するためにはSPKI WGではなく、keyholder次第です。
Because SPKI certificates will carry information that, taken together over all certificates, might constitute a dossier and therefore a privacy violation, each SPKI certificate should carry the minimum information necessary to get a job done. The SPKI certificate is then to be like a single key rather than a key ring or a single credit card rather than a whole wallet. The keyholder should be able to release a minimum of information in order to prove his or her permission to act.
SPKI証明書が情報を載せるので、すべての証明書の上に一緒に取られたそれは、関係書類を構成して、その結果プライバシー違反を構成するかもしれなくて、それぞれのSPKI証明書は仕事を完了させるのに必要な最小の情報を載せるはずです。 SPKI証明書はそして、キーホルダーよりむしろ単一のキーか全体の財布よりむしろ単一のクレジットカードに似ることです。 keyholderは、行動するその人の許可を立証するために最小情報を発表するはずであることができます。
It is necessary for at least some certificates to be anonymous.
少なくともいくつかの証明書が匿名であることが必要です。
Because one use of SPKI certificates is in secret balloting and similar applications, an SPKI certificate must be able to assign an attribute to a blinded signature key.
SPKI証明書の使用がある秘密の投票と同様のアプリケーション、SPKIが証明する目をくらまされた署名キーに属性を割り当てることができなければならないので。
One attribute of a keyholder is a name. There are names the keyholder prefers to be called and there are names by which the keyholder is known to various other keyholders. An SPKI certificate must be able to bind a key to such names. The SDSI work of Rivest and Lampson has done an especially good job of defining and using local name spaces, therefore if possible SPKI should support the SDSI
keyholderの1つの属性が名前です。 keyholderが呼ばれるのを好む名前があります、そして、keyholderが他の様々なkeyholdersにおいて知られている名前があります。 SPKI証明書はそのような名前のキーを縛ることができなければなりません。 RivestとランプソンのSDSI仕事は地方名空間を定義して、使用する特に良い仕事をしました、したがって、可能なSPKIはSDSIをサポートするはずです。
Ellison Experimental [Page 3] RFC 2692 SPKI Requirements September 1999
[3ページ]RFC2692SPKI要件1999年9月に実験的なエリソン
name construct. [Note: SPKI and SDSI have merged.]
構造物を命名してください。 [注意: SPKIとSDSIは合併しました。]
Validity and CRLs
正当性とCRLs
An SPKI certificate, like any other, should be able to carry a validity period: dates within which it is valid. It may also be necessary to have on-line refinement of validity. This is frequently achieved via a Certificate Revocation List (CRL) in previous certificate designs.
いかなる他の、なようにも、SPKI証明書は有効期間を運ぶはずであることができます: それが有効である日付。 また、正当性のオンライン気品を持つのも必要であるかもしれません。 これは前の証明書デザインにおけるCertificate Revocation List(CRL)を通して頻繁に達成されます。
A minimal CRL contains a list of revoked certificates, identified uniquely, a sequence number and a signature. Its method of transmission is not specified. If it encounters some certificate that it lists, then it annihilates that certificate. If it encounters a previous CRL, as indicated by sequence number, then it annihilates that previous CRL. Such a CRL leads to non-deterministic program behavior. Therefore, we take as a requirement that if SPKI uses CRLs, then the certificate that uses it must explicitly tell the verifier where to find the CRL, the CRL must carry explicit validity dates and the dates of a sequence of CRLs must not overlap. Under this set of requirements, behavior of certificate validation is deterministic (aside from the question of clock skew).
最小量のCRLは唯一特定された取り消された証明書のリスト、一連番号、および署名を含んでいます。 トランスミッションのメソッドは指定されません。 それがリストアップする何らかの証明書に遭遇するなら、それはその証明書を全滅させます。 一連番号によって示されるように前のCRLに遭遇するなら、それはその前のCRLを全滅させます。 そのようなCRLは非決定論的なプログラムの振舞いに通じます。 したがって、SPKIがCRLsを使用するならそれを使用する証明書が、どこでCRLを見つけるかを明らかに検証に言わなければならないという要件、CRLが明白な使用期限を運ばなければならなくて、CRLsの系列の日付が重なってはいけないとき、私たちは取ります。 このセットの要件の下では、証明書合法化の振舞いは決定論的です(時計斜行の問題は別として)。
A CRL is a negative statement. It is the digital equivalent of the little paper books of bad checks or bad credit cards that were distributed to cashiers in the 1970's and before. These have been replaced in the retail world by positive statements -- on-line validation of a single check, ATM card or credit card.
CRLは否定的声明です。 それは1970年代と以前出納係に広げられた悪いチェックか悪いクレジットカードの小さい紙の本のデジタル同等物です。 実証的陳述は小売でこれらを世界的に取り替えました--ただ一つのチェック、銀行のキャッシュカードまたはクレジットカードのオンライン合法化。
SPKI should support both positive and negative on-line validations.
SPKIは、両方が積極的で否定的なオンライン合法化であるとサポートするはずです。
Any CRL or revalidation instrument must have its own lifetime. A lifetime of 0 is not possible because of communication delays and clock skews, although one can consider an instrument whose lifetime is "one use" and which is delivered only as part of a challenge/response protocol.
どんなCRLや再合法化器具にも、それ自身の寿命がなければなりません。 0の寿命はコミュニケーション遅れと時計斜行のために可能ではありません、人は寿命が「1つの使用」であり、挑戦/応答プロトコルの一部だけとして提供される器具を考えることができますが。
Implementation of Certificates
証明書の実装
The authorization certificates that are envisioned for SPKI (and needed to meet the demands of the list given at the end of this document) should be generated by any keyholder empowered to grant or delegate the authorization in question. The code to generate certificates should be written by many different developers, frequently persons acting alone, operating out of garages or dorm rooms. This leads to a number of constraints on the structure and encoding of certificates. In addition, SPKI certificates should be usable in very constrained environments, such as smart cards or small
SPKI(そして、このドキュメントの端で与えられたリストの需要にこたえるのが必要である)のために思い描かれる承認証明書は問題の承認を与えるか、または代表として派遣するのに権限を与えられたどんなkeyholderによっても作られるはずです。 証明書を作るコードは多くの異なった開発者、頻繁の車庫から作動して、単独に行動している人々または寮の部屋によって書かれるべきです。これは証明書の構造とコード化の多くの規制に通じます。 さらに、SPKI証明書は、スマートカードなどの非常に強制的な環境で使用可能であるか、または小さいはずです。
Ellison Experimental [Page 4] RFC 2692 SPKI Requirements September 1999
[4ページ]RFC2692SPKI要件1999年9月に実験的なエリソン
embedded systems. The code to process them and the memory to store them should both be as small as possible.
組込み型システムそれらを保存するためにそれらとメモリを処理するコードはともにできるだけ小さいはずです。
An SPKI certificate should be as simple as possible. There should be a bare minimum of fields necessary to get the job done and there should be an absolute minimum of optional fields. In particular, the structure should be specific enough that the creator of a certificate is constrained by the structure definition, not by complaints (or error messages) from the reader of a certificate.
SPKI証明書はできるだけ簡単であるべきです。 仕事を完了させるのに必要な分野の最低限があるべきです、そして、任意の分野の絶対最小値があるべきです。 特に、構造は証明書の読者から証明書のクリエイターが苦情(または、エラーメッセージ)で抑制されるのではなく、構造定義で抑制されるほど特定であるべきです。
An SPKI certificate should be described in as simple a method as possible, relating directly to the kind of structures a C or PASCAL programmer would normally write.
SPKI証明書はできるだけ簡単なメソッドで説明されるべきです、と通常、CかPASCALプログラマを直接構造の種類に関係づけるのが書くでしょう。
No library code should be required for the packing or parsing of SPKI certificates. In particular, ASN.1 is not to be used.
SPKI証明書のパッキングか構文解析のためにライブラリコードを全く必要とするべきではありません。 ASN.1は特に、使用されていることになっていません。
A certificate should be signed exactly as it is transmitted. There should be no reformatting called for in the process of checking a certificate's signature (although one might canonicalize white space during certificate input, for example, if the format is text).
ちょうどそれが伝えられるように証明書は署名されるべきです。 証明書の署名をチェックすることの途中に求められた再フォーマットがあるべきではありません(例えば、1つは形式がテキストであるなら証明書入力の間余白をcanonicalizeするかもしれませんが)。
For efficiency, if possible, an SPKI certificate should be encoded in an LR(0) grammar. That is, neither packing nor parsing of the structure should require a scan of the data. Data should be read into the kind of structure a programmer would want to use without touching the incoming bytes more than once.
できれば、効率において、SPKI証明書はLR(0)文法でコード化されるべきです。すなわち、パッキングも構造の構文解析もデータのスキャンを必要とするべきではありません。 データはプログラマが一度より入って来るバイト多い触れるのなしで使用したがっている構造の種類を読み取ることであるべきです。
For efficiency, if possible, an SPKI certificate should be packed and parsed without any recursion.
効率において、できれば、SPKI証明書は、少しも再帰なしで梱包されて、分析されるべきです。
List of Certificate Uses
証明書用途のリスト
The list below is a brainstorming list, accumulated on the SPKI mailing list, of uses of such certificates.
以下のリストはSPKIメーリングリストに蓄積されたそのような証明書の用途のブレーンストーミングリストです。
- I need a certificate to give me permission to write electronic
checks.
- 私は、電子小切手を書く許可を私に与えるために証明書を必要とします。
- My bank would need a certificate, proving to others that it is
a bank capable of cashing electronic checks and permitted to
give permission to people to write electronic checks.
- 銀行はそれが銀行であると他のものに立証して、電子小切手を現金にすることができる電子小切手を書くために人々に許可することが許可された証明書を必要とするでしょう。
Ellison Experimental [Page 5] RFC 2692 SPKI Requirements September 1999
[5ページ]RFC2692SPKI要件1999年9月に実験的なエリソン
- My bank would issue a certificate signing the key of a master
bank certifier -- perhaps NACHA -- so that I could follow a
certificate chain from a key I know (my bank's) to the key of
any other bank in the US and, similarly, to any other bank in
the world.
- 銀行は私が知っているキー(銀行のもの)からいかなる他の銀行のキーまでも私が証明書チェーンの後をつけることができるようにマスター銀行証明すること(恐らくNACHA)のキーに署名する証明書を米国と同様な世界のいかなる他の銀行にも発行するでしょう。
- I might generate a certificate (a "reputation voucher") for a
friend to introduce him to another friend -- in which
certificate I could testify to my friend's political opinion
(e.g., libertarian cypherpunk) or physical characteristics or
anything else of interest.
- 友人が別の友人に彼を紹介するように、私は証明書(「評判バウチャー」)を作るかもしれません--私はどの証明書で私の友人の政治上の意見(例えば、自由論者サイファーパンク)か物理的な特性に証言してもよいか、そして、他の何か興味があるもの。
- I might have a certificate giving my security clearance, signed
by a governmental issuing authority.
- 私は証明書に政府の発行機関によって署名された機密取扱者の人物調査を与えさせるかもしれません。
- I want a certificate for some software I have downloaded and am
considering running on my computer -- to make sure it hasn't
changed and that some reputable company or person stands behind
it.
- 私は、私がダウンロードした何らかのソフトウェアのための証明書が欲しく、私のコンピュータで動くと考えています--変化していなくて、名声の高い会社か人がそれの後ろに立つのを確実にするために。
- I need certificates to bind names to public keys:
- 私は公開鍵に名前を縛るために証明書を必要とします:
- [traditional certificate] binding a key to a name, implying
"all the attributes of the real person having this name are
transferred to this key by this certificate". This requires
unique identification of a person (which is difficult in
non-digital space, as it is) and someone trustworthy binding
that unique name to the key in question. In this model, a
key starts out naked and acquires attributes, permissions
and authority from the person bound to it.
- [伝統的な証明書] 「この証明書はこの名前を持っている実在の人物のすべての属性をこのキーに移します」と含意して、名前のキーを縛ります。 これは人(それのように非デジタルのスペースで難しい)とそのユニークな名前を問題のキーに縛るだれか信頼できる人のユニークな識別を必要とします。 このモデルでは、キーは、それに縛られた人から、裸の状態で始めて、属性、許容、および権威を取得します。
- [direct certificate] binding a name to a key, implying "I
(the person who is able to use the associated private key to
make this signature) declare that I go by the name of
XXXXXXX." The unique identification of the key is automatic
-- from the key itself or a cryptographic hash of the key.
The binding is done by the key itself -- in a self-signed
certificate. In this model, a key is loaded with
attributes, permissions and authority directly by other
certificates, not indirectly through some person's name, and
this certificate declares only a name or nickname by which
the key's owner likes to be addressed.
- [ダイレクト証明書] 「私(この署名をするのに関連秘密鍵を使用できる人)は、XXXXXXXという名前で行くと宣言します」と含意して、キーに名前を縛ります。 キーのユニークな識別はキー自体かキーの暗号のハッシュから自動です。 キー自体で、自己署名入りの証書で結合します。 キーの所有者が好きである名前かあだ名だけが扱われるとこのモデルでは、直接間接的なだれかの名前ではなく、他の証明書による属性、許容、および権威にキーを積んで、この証明書は、宣言します。
- [personal binding] binding a key to a nickname. This kind
of certificate is signed by me, singing someone else's key
and binding it to a nickname by which I know that person.
It is for my use only -- never given out -- and is a signed
certificate to prevent tampering with my own private
- [個人的な結合] あだ名のキーを縛ります。 この種類の証明書は私によって署名されます、私がその人を知っているあだ名に他の誰かのキーを歌って、それを縛って。 それは私の使用だけのためのものです--決して尽きないで、個人的に私自身のをいじるのを防ぐ署名入りの証書です。
Ellison Experimental [Page 6] RFC 2692 SPKI Requirements September 1999
[6ページ]RFC2692SPKI要件1999年9月に実験的なエリソン
directory of keys. It says nothing about how I certified
the binding to my own satisfaction between the key and my
friend.
キーのディレクトリ。 私がどうキーと私の友人の間の私自身の満足に結合を公認したかに関してそれは沈黙します。
- I might be doing genealogy and be collecting what amounts to
3x5 cards with facts to be linked together. Some of these
links would be from one content to another reference [e.g.,
indexing and cross-referencing]. Others might be links to the
researcher who collected the fact. By rights, the fact should
be signed by that researcher. Viewing only the signature on
the fact and the link to the researcher, this electronic 3x5
card becomes a certificate.
- 私は、系図をしていて、結びつけられるために事実がある3×5枚のカードに達することを集めているかもしれません。 1つの内容から別の参照[例えば、索引をつけて、十字で参照をつける]までこれらのいくつかのリンクがあるでしょう。 他のものは集まった研究者へのリンクが事実であるならそうするでしょうに。 公正に、事実はその研究者によって署名されるべきです。 研究者への事実とリンクの上に署名だけを見て、この電子3×5カードは証明書になります。
- I want to sign a contract to buy a house. What kind of
certificate do I need?
- 家を買う契約に署名したいと思います。 私はどういう証明書を必要としますか?
- I have found someone on the net and she sounds really nice.
Things are leading up to cybersex. How do I make sure she's
not really some 80-year-old man in a nursing home?
- 私はネットでだれかを見つけました、そして、彼女は本当に聞こえが良いです。 いろいろなことはサイバーセックスに導いています。 私は、彼女が本当に私設療養院の80歳の男性でないことをどのように確実にしますか?
- I have met someone on the net and would like a picture of her
and her height, weight and other measurements from a
trustworthy source.
- 私は、ネットでだれかに会って、信頼できるソースから彼女と彼女の高さ、重さ、および他の測定値の画像が欲しいと思います。
- Can I have a digital marriage license?
- デジタル婚姻許可書を頂けますか?
- Can I have a digital divorce decree?
- デジタル離婚判決をして頂けますか?
- ..a digital Voter Registration Card?
- ..デジタルVoter Registration Card?
- There are a number of cards one carries in a typical wallet
which could become certificates attached to a public key:
- 1つが公開鍵に添付された証明書になることができた典型的な財布で運ぶ多くのカードがあります:
- health insurance card
- 健康保険証
- prescription drug card
- 処方薬カード
- driver's license (for permission to drive)
- 運転免許証(運転する許可のための)
- driver's license (for permission to buy alcohol)
- 運転免許証(アルコールを買う許可のための)
- supermarket discount card
- スーパーマーケット割り引きカード
- supermarket check-cashing card [I know -- anachronism]
- スーパーマーケット小切手の現金化カード[私は知っています--時代錯誤]
- Blockbuster Video rental card
- 超大作のVideoのレンタルのカード
- ATM card
- 銀行のキャッシュカード
Ellison Experimental [Page 7] RFC 2692 SPKI Requirements September 1999
[7ページ]RFC2692SPKI要件1999年9月に実験的なエリソン
- Credit card
- クレジットカード
- membership card in the ACLU, NRA, Republican party, Operation
Rescue, NARAL, ACM, IEEE, ICAR....
- ACLUにおける会員証、NRA、共和党のパーティー、オペレーションレスキュー、NARAL、ACM、IEEE、ICAR…
- Red Cross blood donor card
- 赤十字献血者カード
- Starbuck's Coffee buy-10-get-1-free card
- スターバックの買物10が1なしになっているCoffeeカード
- DC Metro fare card
- DC Metro料金カード
- Phone calling card
- テレホンカードに電話をしてください。
- Alumni Association card
- 同窓生Associationカード
- REI Membership card
- REI Membershipカード
- Car insurance card
- 車の被保険者証
- claim check for a suitcase
- スーツケースのためのクレームチェック
- claim check for a pawned radio
- 質入れされたラジオのためのクレームチェック
- authorization for followup visits to a doctor, after surgery
- 外科の後の医師への追跡訪問のための承認
- Better Business Bureau [BBB] style reputation certificates
[testimonies from satisfied customers]
- 商事改善協会[BBB]スタイル評判証明書[満足した客からの証言]
- BBB-style certificate that no complaints exist against a
business or doctor or dentist, etc.
- 証明書をBBB流行に合わせてください。苦情が全く企業、医師または歯医者に対して存在していない、など
- LDS Temple Recommend
- 寺が推薦するLDS
- Stock certificate
- 株券
- Stock option
- ストックオプション
- Car title
- 車のタイトル
- deed to land
- 決着させる行為
- proof of ownership of electronic equipment with an ID number
- ID番号がある電子装置の所有権の証拠
- time card certificate [activating a digital time clock]
- タイムカード証明書[デジタルタイムレコーダーを動かします]
- proof of degree earned [PhD, LLD, MD, ...]
- 得られた度合いの証拠[博士号、LLD、MD]
- permission to write digitally signed prescriptions for drugs
- ドラッグへのデジタルに署名している処方箋を書く許可
Ellison Experimental [Page 8] RFC 2692 SPKI Requirements September 1999
[8ページ]RFC2692SPKI要件1999年9月に実験的なエリソン
- permission to spend up to $X of a company's money
- 会社のお金の$Xまで費やす許可
- permission to issue nuclear launch codes
- 核着手コードを発行する許可
- I'm a sysadmin, I want to carry a certificate, signed by SAGE,
that says I'm good at the things sysadmins are good at.
- 私がsysadminである、私はsysadminsが上手であるものが上手であると書かれているSAGEによって署名された証明書には運びたいと思います。
- I'm that same sysadmin, I want an ephemeral certificate that
grants me root access to certain systems for the day, or the
week, or...
- その同じsysadminである、私はルートアクセスを私に与えるはかない証明書が欲しいと1日、1週間、または…のあるシステムと思います。
Certain applications *will* want some form of auditing, but the
audit identity should be in the domain of the particular
application... For instance an "is a system administrator of
this host" certificate would probably want to include an audit
identity, so you can figure out which of your multiple admins
screwed something up.
あるアプリケーション*意志*は何らかのフォームの監査を必要としますが、監査のアイデンティティが特定用途のドメインにあるべきです… 例えば、「このホストにはシステム管理者がい」証明書はたぶん監査のアイデンティティを含みたがっているでしょう、したがって、あなたがあなたの複数のアドミンのどれが何かをねじで締めたかを理解できます。
- I'm an amateur radio operator. I want a signed certificate
that says I'm allowed to engage in amateur radio, issued by the
DOC. [I currently have a paper version of one]. This would be
useful in enforcing access policies to the amateur spectrum;
and in tracking abuse of that same spectrum. Heck! extend
this concept to all licensed spectrum users.
- 私はアマチュア無線家です。 私は、私がDOCによって発行されたアマチュア無線に従事できると書かれている署名入りの証書には欲しいと思います。 [私には、現在、1の紙のバージョンがあります。] これはアマチュアスペクトルにアクセス方針を実施する際に役に立つでしょう。 そして、中ではその同じスペクトルの乱用を追跡すること。 チェッ、すべての認可されたスペクトルユーザにこの概念について敷衍してください。
- I'm the a purchasing agent for a large corporation. I want to
posses a certificate that tells our suppliers that I'm
authorized to make purchases up to $15,000. I don't want the
suppliers to know my name, lest their sales people bug me too
much. I don't want to have to share a single "Megacorp
Purchasing Department Certificate" with others doing the same
job [the private key would need to be shared--yuck!].
- 私は大企業のa購買担当者です。 私は、私が購買を最大1万5000ドルにするのに権限を与えられると私たちの供給者に言う証明書が欲しいと武装隊と思います。 彼らの販売員があまりに私を悩ますといけなくて、私は、供給者に私の名前を知って欲しいと思いません。 私は、単一の「Megacorp購買部証明書」を同じ仕事をする他のものと共有しなければならなくて欲しいと思いません[秘密鍵は、共有される必要があるでしょう--yuck]。
- "This signed-key should be considered equivalent to the
certifying-key until this certificate expires for the following
purposes ..."
[This is desirable when you wish to reduce the exposure of
long-term keys. One way to do this is to use smart cards,
but those typically have slow processors and are connected
through low-bandwidth links; however, if you only use the
smart card at "login" time to certify a short-term key pair,
you get high performance and low exposure of the long term
key.
- 「この証明書が以下のために目的を吐き出すまで、この署名しているキーは公認しているキーに同等であると考えられるべきです」… あなたが長期のキーの展示を抑えたがっているとき、これは望ましいです。[それらは、遅いプロセッサを通常持って、低バンド幅リンクを通して接続されます; これをするOne方法はスマートカードを使用することですが、短期的な主要な組を公認する「ログイン」時にスマートカードを使用するだけであるなら、しかしながら、あなたは主要であるという長い期間の高性能と低い暴露を得ます。
Ellison Experimental [Page 9] RFC 2692 SPKI Requirements September 1999
[9ページ]RFC2692SPKI要件1999年9月に実験的なエリソン
I'll note here that this flies in the face of attempts to
prevent delegation of certain rights. Maybe we need a
"delegation-allowed" bit -- but there's nothing to stop
someone who wishes to delegate against the rules from also
loaning out their private key.].
私は、ここでこれが、ある権利の委譲を防ぐ試みに反することに注意するつもりです。 ]
- "I am the current legitimate owner of a particular chunk of
Internet address space."
[I'd like to see IPSEC eventually become usable, at least
for privacy, without need for prior arrangement between
sites, but I think there's a need for a "I own this
address"/"I own this address range" certificate in order for
IPSEC to coexist with existing ip-address-based firewalls.]
- 「私はインターネット・アドレススペースの特定の塊の現在の正統の所有者です。」 [IPSECが結局使用可能になるのを見たいと思います、少なくともプライバシーのために、サイトの間の先の配置の必要性なしで、しかし、私はIPSECが既存のipアドレスベースのファイアウォールと共存するように「私はこのアドレスを所有している」という/の「私はこのアドレスの範囲を所有している」という証明書整然としている必要があると思います。]
- "I am the current legitimate owner of a this DNS name or
subtree."
- 「私は、このDNSの正統の所有者が命名する電流か下位木です。」
- "I am the legitimate receiver of mail sent to this rfc822 email
address. [this might need to be signed by a key which itself
had been certified by the appropriate "DNS name owner"
certificate]."
[This is in case I know someone owns a particular e-mail
address but I don't know their key.]
- 「私はこのrfc822Eメールアドレスに送られたメールの正統の受信機です。」 「[これは、適切な「DNS名前所有者」証明書によってそれ自体で公認されたキーによって署名される必要があるかもしれません]。」 [これは私が、だれかが特定のEメールアドレスを所有していますが、私がそれらのキーを知らないのを知っているといけないからです。]
- Encryption keys for E-mail and file encryption
- メールのための暗号化キーとファイル暗号化
- Authentication of people or other entities
- 人々か他の実体の認証
- Digital signatures (unforgeability)
- デジタル署名(「非-可鍛性」)
- Timestamping / notary services
- Timestamping/公証人サービス
- Host authentication
- ホスト認証
- Service authentication
- サービス認証
Other requirements:
他の要件:
- Trust model must be a web (people want to choose whom they
trust). People must be able to choose whom they trust or
consider reliable roots (maybe with varying reliabilities).
- 信頼モデルはウェブであるに違いありません(人々は、自分達がだれを信じるかを選びたがっています)。 人々は、彼らがだれを信じるかを選ばなければならないか、または信頼できるルーツを考えることができなければなりません(多分異なった信頼性で)。
- Some applications (e.g., notary services) require highly
trusted keys; generation complexity is not an issue here.
- いくつかのアプリケーション(例えば、公証人サービス)が高く信じられたキーを必要とします。 世代の複雑さはここの問題ではありません。
- Some applications (e.g., host authentication) require
extremely light (or no) bureaucracy. Even communication
with the central administrator may be a problem.
- いくつかのアプリケーション(例えば、ホスト認証)が非常に軽い(または、いいえ)官僚制度を必要とします。 主要な管理者とのコミュニケーションさえ問題であるかもしれません。
Ellison Experimental [Page 10] RFC 2692 SPKI Requirements September 1999
[10ページ]RFC2692SPKI要件1999年9月に実験的なエリソン
- Especially in lower-end applications (e.g. host
authentication) the people generating the keys (e.g.,
administrators) will change, and you will no longer want
them to be able to certify. On the other hand, you will
usually also not want all keys they have generated to
expire. This may imply a "certification right expiration"
certificate requirement, probably to be implemented together
with notary services.
- 特に(例えば、管理者)が変えるキーを生成する人々、およびあなたが、もう彼らに公認できて欲しくないローエンドアプリケーション(例えば、ホスト認証)で。 他方では、また、通常、あなたは、それらが生成したすべてのキーが期限が切れて欲しくないでしょう。 これは、たぶん公証人サービスと共に実装されるために「証明権利満了」証明書要件を含意するかもしれません。
- Keys will need to be cached locally to avoid long delays
fetching frequently used keys. Cf. current name servers.
The key infrastructure may in future get used almost as
often as the name server. The caching and performance
requirements are similar.
- キーは、頻繁に使用されたキーをとって来る長時間の遅延を避けるために局所的にキャッシュされる必要があるでしょう。 Cf現在のネームサーバ。 主要なインフラストラクチャはこれから、ネームサーバとほとんど同じくらい頻繁に使用されるかもしれません。キャッシュと性能要件は同様です。
- Reliable distribution of key revocations and other
certificates (e.g., the ceasing of the right to make new
certificates). May involve goals like "will have spread
everywhere in 24 hours" or something like that. This
interacts with caching.
- 主要な取消しと他の証明書(例えば、新しい証明書を作る権利のやむ)の信頼できる分配。 「いたる所では、24時間で、広まってしまうだろう」か、そのような何かのような目標にかかわるかもしれません。 これはキャッシュと対話します。
Open Questions
未決問題
Given such certificates, there remain some questions, most to do with proofs of the opposite of what a certificate is designed to do. These do not have answers provided by certificate definition or issuing alone.
そのような証明書を考えて、いくつかの問題(証明書がするように設計されている何の正反対の証拠を処理するか大部分)が残っています。 これらで、証明書定義で提供された答えか発行が単独になりません。
- Someone digitally signs a threatening e-mail message with my
private key and sends it to president@whitehouse.gov. How do I
prove that I didn't compose and send the message? What kind of
certificate characteristic might help me in this?
- だれかが、険悪なメールメッセージと私の秘密鍵をデジタルに契約して、それを president@whitehouse.gov に送ります。 私はメッセージを構成して、どのように送らなかったと立証しますか? どういう証明書の特性がこれで私を助けるかもしれませんか?
This is an issue of (non-)repudiation and therefore a matter of
private key protection. Although this is of interest to the
user of certificates, certificate format, contents or issuing
machinery can not ensure the protection of a user's private key
or prove whether or not a private key has been stolen or
misused.
これが問題である、(非、)、拒否としたがって、秘密鍵保護の問題。 証明書のユーザにとって、これは興味深いのですが、証明書形式、コンテンツまたは機械を支給するのが、ユーザの秘密鍵の保護を確実にすることができませんし、秘密鍵が盗まれたか、または誤用されたかどうか立証できません。
- Can certificates help do a title scan for purchase of a house?
- 証明書は、家の購入のためのタイトルスキャンをするのを助けることができますか?
Certificates might be employed to carry information in a
tamper-proof way, but building the database necessary to record
all house titles and all liens is a project not related to
certificate structure.
証明書は干渉防止方法で情報を運ぶのに使われるかもしれませんが、すべての家のタイトルとすべての先取特権を記録するのに必要なデータベースを築き上げるのは、証明書構造に関連しないプロジェクトです。
Ellison Experimental [Page 11] RFC 2692 SPKI Requirements September 1999
[11ページ]RFC2692SPKI要件1999年9月に実験的なエリソン
- Can a certificate be issued to guarantee that I am not already
married, so that I can then get a digital marriage license?
- 次に、私がデジタル婚姻許可書を得ることができて、私が既に結婚していないのを保証するために証明書を発行できますか?
The absence of attributes can be determined only if all
relevant records are digitized and all parties have inescapable
IDs. The former is not likely to happen in our lifetimes and
the latter receives political resistance.
すべての関連記録がデジタル化されて、すべてのパーティーに不可避的なIDがある場合にだけ、属性の欠如は決定できます。 前者は私たちの生涯に起こりそうにはありません、そして、後者は政治上の抵抗を受けます。
A certificate can communicate the 'positive' attribute "not
already married" or "not registered as a voter in any other
district". That assumes that some organization is capable of
determining that fact for a given keyholder. The method of
determining such a negative fact is not part of the certificate
definition.
証明書は「既に、結婚しない」か、または「有権者としていかなる他の地区ではも登録されなかった」'積極的な'属性を伝えることができます。 それは、何らかの組織が与えられたkeyholderのためにその事実を決定できると仮定します。 そのような否定的事実を決定する方法は証明書定義の一部ではありません。
- The assumption in most certificates is that the proper user will
protect his private key very well, to prevent anyone else from
accessing his funds. However, in some cases the certificate
itself might have monetary value [permission to prescribe drugs,
permission to buy alcohol, ...]. What is to prevent the holder of
such a certificate from loaning out his private key?
- ほとんどの証明書における仮定は適切なユーザが他の誰も彼の基金にアクセスするのを防ぐために彼の秘密鍵を非常によく保護するということです。 しかしながら、いくつかの場合、証明書自体には金銭価値があるかもしれない、[ドラッグを処方する許可、買物アルコールへの許可、…] 何が貸出しするのからのそのような証明書の所有者のために彼の秘密鍵を防ぐことになっていますか?
This is a potential flaw in any system providing authorization
and an interesting topic for study. What prevents a doctor or
dentist from selling prescriptions for controlled substances to
drug abusers?
これは認可とおもしろい話題を研究に提供するどんなシステムの潜在的欠点です。 何によって、医師か歯医者が規制物質への処方箋を薬物乱用者に販売できませんか?
References
参照
[DH] Diffie and Hellman, "New Directions in Cryptography", IEEE
Transactions on Information Theory IT-22, 6 (Nov. 1976), 644-
654.
[DH] ディフィーとヘルマン、「暗号に関する新傾向」、情報理論IT-22のIEEE取引、6(1976年11月)、644- 654。
[KOHN] Loren Kohnfelder, "Towards a Practical Public-key
Cryptosystem", Bachelor's thesis, MIT, May, 1978.
[コーン]ロレーンKohnfelder、「実用的な公開カギ暗号系」、Bachelorの論文、MIT、1978年5月。
Security Considerations
セキュリティ問題
Security issues are discussed throughout this memo.
このメモ中で安全保障問題について議論します。
Ellison Experimental [Page 12] RFC 2692 SPKI Requirements September 1999
[12ページ]RFC2692SPKI要件1999年9月に実験的なエリソン
Author's Address
作者のアドレス
Carl M. Ellison Intel Corporation 2111 NE 25th Ave M/S JF3-212 Hillsboro OR 97124-5961 USA
カールM.エリソンインテル社2111の第25Ne Ave M/S JF3-212ヒルズバロか97124-5961米国
Phone: +1-503-264-2900
Fax: +1-503-264-6225
EMail: carl.m.ellison@intel.com
cme@alum.mit.edu
Web: http://www.pobox.com/~cme
以下に電話をしてください。 +1-503-264-2900 Fax: +1-503-264-6225 メールしてください: carl.m.ellison@intel.com cme@alum.mit.eduウェブ: http://www.pobox.com/~cme
Ellison Experimental [Page 13] RFC 2692 SPKI Requirements September 1999
[13ページ]RFC2692SPKI要件1999年9月に実験的なエリソン
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Ellison Experimental [Page 14]
エリソンExperimentalです。[14ページ]
一覧
スポンサーリンク
