Network Working Group C. Ellison
Request for Comments: 2692 Intel
Category: Experimental September 1999
SPKI Requirements
Status of this 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.
著作権（C）インターネット協会（1999）。全著作権所有。
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簡易公開鍵基盤は、[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
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主催の公開鍵証明書の形式、関連する署名およびその他の形式、およびキー取得プロトコルのためのインターネット標準を開発することになります。鍵証明書のフォーマットと関連プロトコルは、理解し、実装、および使用する単純なものになっています。ワーキンググループの目的のために、結果のフォーマットとプロトコルは、簡易公開鍵基盤、または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文書、支払プロトコル、および公開鍵証明書を使用してアクセスする能力を必要とする任意の他のアプリケーションを含む、インターネットアプリケーションの広い範囲でセキュリティをサポートするためのメカニズムを提供することを意図していますそれら。単純な公開鍵インフラストラクチャは、信頼モデルの範囲をサポートすることを意図しています。
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.
用語の証明書は、バック・ローレンM. Kohnfelder [KOHN]のMITの学士論文にトレースします。 Kohnfelderは、今度は、その独創紙[DH]でディフィー及びヘルマンの提案に応えました。ディフィーとHellmanは、公開鍵暗号方式で、1は、もはやのコミュニ間の秘密鍵を送信する上で安全なチャネルを必要としていることを指摘していません。電話番号の代わりに公開鍵を持つ1 - その代わりに、彼らは示唆し、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チームが直接<名、キー>バインディングの問題に対処して、そのような証明書が信頼管理のための非常に限られた使用であることに気づきました。キーホルダーの名前はキーホルダーの一つの属性であるが、この文書のニーズのリストに見られるように、人の名前はほとんどのセキュリティ興味深いのではありません。証明書の利用者は、与えられたキーホルダーは、いくつかの特定の権限を付与されているかどうかを知る必要があります。
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.
私たちは、対応する秘密鍵を支配する者または他のエンティティを参照するために、公開鍵の長期キーホルダーを定義します。
The main purpose of an SPKI certificate is to authorize some action, give permission, grant a capability, etc. to or for a keyholder.
SPKI証明書の主な目的は、許可を与え、いくつかのアクションを承認するか、キーホルダーのための機能などを付与することです。
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.
キーホルダーは、最も直接的であるが便宜または何らかの間接（結合遅延）を使用することができる他の目的のために、公開鍵自体によって識別されます。それは後に間接キーに分解されるように、公開鍵または名前を経由しての無衝突ハッシュを介して行うことができます。
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証明書はキーホルダーを公開したくないかもしれない情報を運ぶ可能性があるため、私たちは、証明書が検証者にキーホルダーが直接配布されることを想定しています。キーホルダーは、LDAP、グローバルPGPキーサーバーやDNSデータベースなどのグローバルリポジトリを、使用したい場合は、それはキーホルダーまでとしませSPKI WGを指定するためのものです。
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証明書は、単一のキーではなく、キーリング、または単一のクレジットカードではなく、全体の財布のようになり、その後です。キーホルダーは行動する彼または彼女の許可を証明するために最小限の情報を解放することができるはずです。
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 name construct. [Note: SPKI and SDSI have merged.]
キーホルダーの一つの属性は、名前です。キーホルダーが呼ばれることを好むとキーホルダーが他のさまざまなキーホルダーに認識されている名前がある名前があります。 SPKI証明書は、そのような名前のキーをバインドすることができなければなりません。リベストとLampsonのSDSI作業がが可能SPKIはSDSI名の構文をサポートする必要がある場合は、ローカルの名前空間を定義し、使用するのが特に良い仕事をしています。 [注：SPKIとSDSIが合併しています。]
Validity and CRLs
妥当性とCRL
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証明書は、他と同様に、有効期間を運ぶことができるはずです。また、妥当性のオンライン洗練を持ってする必要があるかもしれません。これは、頻繁に以前の証明書の設計で証明書失効リスト（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は、CRLを使用している場合、それを使用する証明書が明示的にCRLを見つけるために検証を伝える必要があることを要件として取る、CRLは、明示的な有効期間とCRLの一連の日付が重複してはならない運ぶ必要があります。要件のセットの下では、証明書の検証の動作は、（クロック・スキューの問題は別として）決定論的です。
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年代にと前にレジに配布された不正な小切手か悪いクレジットカードの小さな紙の本のデジタルと同等です。 1つのチェック、ATMカードやクレジットカードのオンライン検証 - これらは、正文で小売の世界に置き換えられています。
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の寿命があるため、通信遅延およびクロックスキューのは不可能です。
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 embedded systems. The code to process them and the memory to store them should both be as small as possible.
SPKIのために想定される（このドキュメントの最後に与えられたリストの要求を満たすために必要とされる）の認可証明書が付与または問題の承認を委任する権限を任意のキーホルダーによって生成されなければなりません。証明書を生成するコードは、人々がガレージや寮の部屋の外に動作し、単独で作用頻繁に、多くの異なる開発者が記述する必要があります。これは、証明書の構造とエンコーディングの制約の数につながります。また、SPKI証明書は、スマートカードまたは小型組み込みシステムとして非常に制約のある環境で使用可能でなければなりません。コードは、それらの両方はできるだけ小さくすべきでそれらを格納するためのメモリを処理します。
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つは、例えば、証明書の入力時に空白を正規化かもしれませんが）があってはなりません。
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.
- 私の銀行は、電子小切手を現金化できる銀行で、電子小切手を書くために人々に権限を与えることを許可することを他の人に証明する、証明書が必要になります。
- 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の名前で行くと宣言I（この署名をするために関連した秘密鍵を使用することが可能である人物）。」キーの一意の識別は、自動である - キー自体またはキーの暗号ハッシュから。自己署名証明書 - 結合は、キー自体によって行われます。このモデルでは、キーは、いくつかの人の名前を介して間接的に、直接、他の証明書によって、属性、アクセス権と権限でないロードされ、この証明書は、鍵の所有者が対処するのが好きそれによってのみ、名前やニックネームを宣言します。
- [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 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.
- 私は系譜をやっている可能性があり、一緒にリンクすることが事実とは3x5カードに相当するもの収集します。これらのリンクのいくつかは、別の文献[例えば、索引付けおよび相互参照] 1つのコンテンツからなるであろう。他の人が事実を収集した研究者へのリンクであるかもしれません。権利によって、事実は研究者によって署名されなければなりません。唯一の事実上の署名や研究者へのリンクを表示する、この電子は3x5カードは、証明書になります。
- 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?
- ..Aデジタル有権者登録カード？
- 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
- ブロックバスタービデオレンタルカード
- ATM card
- キャッシュカード
- 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フリーカード
- DC Metro fare card
- DCメトロの運賃カード
- Phone calling card
- 電話コーリングカード
- Alumni Association card
- 同窓会カード
- REI Membership card
- REIの会員カード
- 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
- 薬物のためのデジタル署名された処方箋を書き込む権限
- 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.
- 私はシステム管理者よ、私はシステム管理者が得意なものが得意だと言う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...
- 私は、同じシステム管理者は、私は私の一日のために特定のシステムへのrootアクセスを許可はかない証明書、または週、またはをしたいということです...
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.
* *たとえば、証明書の「このホストのシステム管理者である」...監査のいくつかのフォームが、監査アイデンティティは、特定のアプリケーションのドメイン内にあるべきでしょう特定のアプリケーションは、おそらくので、監査IDを含めるようにしたいと思いますあなたが何かを台無しにあなたの複数の管理者のどの把握することができます。
- 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!].
- 私は大企業のための購買担当者です。私は$ 15,000までの購入を行う権限よ、お取引先に伝えた証明書を保有します。その営業担当者がバグ私はあまりないように私は、サプライヤーが私の名前を知っている必要はありません。 [ - 不潔な秘密鍵を共有する必要があるだろう！]私は、同じ仕事をして他人とシングル「Megacorp購買部証明書」を共有する必要がありますする必要はありません。
- "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.
- 「この証明書は、以下の目的のために有効期限が切れるまで、この署名キーは証明キーと同等とみなされるべきである...」あなたは、長期的なキーの露出を減らすことを望むとき[これは望ましいです。これを行う1つの方法は、スマートカードを使用することであるが、これらは一般的に遅いプロセッサを持つ、低帯域幅リンクを介して接続されています。あなたが唯一の短期的な鍵のペアを証明するために、「ログイン」時にスマートカードを使用する場合は、あなたは高い性能と長期キーの低い露出を得ます。
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.]
- 「[DNS名の所有者。私はこのRFC822のメールアドレスに送信されたメールの正当な受信機だこれは、それ自体が適切で認定されていた鍵で署名する必要があるかもしれません 『』証明書]。」 [これは私が誰かを特定の電子メールアドレスを所有している知っているが、私は彼らのキーを知らない場合にはあります。]
- Encryption keys for E-mail and file encryption
- Eメールやファイルの暗号化のための暗号化キー
- Authentication of people or other entities
- 人や他のエンティティの認証
- Digital signatures (unforgeability)
- デジタル署名（偽造）
- Timestamping / notary services
- タイムスタンプ/公証人のサービス
- 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.
- いくつかのアプリケーション（例えば、ホスト認証が）非常に軽い（または全くない）官僚を必要とします。中央管理者にさえ、通信は問題がある可能性があります。
- 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.
- キーは頻繁に使用するキーを取得する長い遅延を避けるために、ローカルにキャッシュする必要があります。参照現在のネームサーバ。鍵インフラストラクチャは、将来的には、ネームサーバと同じくらい頻繁に使用されるかもしれません。キャッシングとパフォーマンスの要件が類似しています。
- 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.
- キー取り消しや他の証明書の信頼性分布（例えば、右の中止（ceasing）は、新しい証明書を作成します）。 「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.
- 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.
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.
証明書は、「陽性」属性が「まだ結婚していない」または「他の地区の有権者として登録されていない」通信することができます。それは、いくつかの組織が与えられたキーホルダーのためにその事実を決定することが可能であることを前提としています。そのような負の事実を決定する方法は、証明書の定義の一部ではありません。
- 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、6（1976年11月）、644- 654上のIEEEトランザクション。
[KOHN] Loren Kohnfelder, "Towards a Practical Public-key Cryptosystem", Bachelor's thesis, MIT, May, 1978.
「実用的な公開鍵暗号に向けて」[KOHN]ローレン・コーンフェルダー、学士論文、MIT、月、1978。
Security Considerations
セキュリティの考慮事項
Security issues are discussed throughout this memo.
セキュリティの問題は、このメモ中で議論されています。
Author's Address
著者のアドレス
Carl M. Ellison Intel Corporation 2111 NE 25th Ave M/S JF3-212 Hillsboro OR 97124-5961 USA
カール・M.エリソンインテルコーポレーション2111 NE 25日アヴェM / S JF3-212ヒルズボロOR 97124から5961 USA
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ファックス：+ 1-503-264-6225 Eメール：carl.m.ellison@intel.com cme@alum.mit.eduウェブ：http://www.pobox.com/ 〜CME
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。