Network Working Group                                         C. Ellison
Request for Comments: 2692                                         Intel
Category: Experimental                                    September 1999
        

SPKI Requirements

SPKI要件

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.

このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (1999). All Rights Reserved.

Copyright（c）The Internet Society（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・コーンフェルダー[kohn]のMIT学士の論文にまでさかのぼります。Kohnfelderは、彼らの独創的な論文[DH]で、DiffieとHellmanの提案に応じていました。DiffieとHellmanは、公開キーの暗号化では、コミュニケーション間で秘密の鍵を送信するための安全なチャネルはもはや必要ではないと指摘しました。代わりに、彼らは、電話番号の代わりに公開鍵を備えた修正された電話帳を公開できることを示唆しました。その後、ディレクトリで自分の希望するコミュニケーションパートナーを調べて、その人の公開鍵を見つけて、その人に安全なチャネルを開くことができます。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チームは、<name、key> bindingsの問題に直接対処し、そのような証明書は信頼管理に非常に限られていることを認識しました。キーホルダーの名前はキーホルダーの1つの属性ですが、このドキュメントのニーズのリストに見られるように、人の名前はめったにセキュリティの利益ではありません。証明書のユーザーは、特定のキーホルダーに特定の承認が認められているかどうかを知る必要があります。

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証明書は、キーホルダーが公開したくない可能性のある情報を搭載する可能性があるため、証明書はキーホルダーによってVerifierに直接配布されると想定しています。キーホルダーが、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証明書の1つの使用は秘密の投票と同様のアプリケーションであるため、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.]

キーホルダーの属性の1つは名前です。キーホルダーが呼び出すことを好む名前があり、キーホルダーが他のさまざまなキーホルダーに知られている名前があります。SPKI証明書は、そのような名前にキーをバインドできる必要があります。Rivestと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がCRLSを使用する場合、それを使用する証明書は、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年代以前にレジ係に配布されたのは、悪い小切手または不良クレジットカードの小さな紙の本に相当するデジタルです。これらは、小売業界では、単一のチェック、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またはRevalidation機器は、独自の寿命が必要です。コミュニケーションの遅延と時計のゆがみのために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 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).

証明書は送信されたときに正確に署名する必要があります。証明書の署名をチェックするプロセスでは、フォーマットがテキストの場合、証明書入力中に白地を正規化する場合があります）。

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.

- 私の銀行は、マスター銀行証明書の鍵（おそらくナチャ）に署名する証明書を発行します。そうすれば、私が知っているキー（私の銀行）から米国の他の銀行の鍵まで、そして同様に証明書チェーンをたどることができます。、世界の他の銀行に。

- 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.

- 友人が彼を別の友人に紹介するための証明書（「評判のバウチャー」）を生成するかもしれません。この証明書では、友人の政治的意見（リバタリアンのcypherpunkなど）や物理的な特性など、興味のあるものを証言できます。

- 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.

- [直接証明書]名前をキーにバインドし、「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のカードに相当するものを収集しているかもしれません。これらのリンクの一部は、あるコンテンツから別のリファレンスへの[インデックス作成と相互参照]です。他の人は、事実を収集した研究者へのリンクである可能性があります。権利により、事実はその研究者によって署名されるべきです。事実と研究者へのリンクの署名のみを表示すると、この電子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?

- ..デジタル投票者登録カード？

- There are a number of cards one carries in a typical wallet which could become certificates attached to a public key:

- 公開鍵に添付されている証明書になる可能性のある典型的なウォレットに携帯するカードがいくつかあります。

- 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、共和党、オペレーションレスキュー、ナラル、ACM、IEEE、ICAR。

- Red Cross blood donor card

- 赤十字の献血カード

- Starbuck's Coffee buy-10-get-1-free card

- StarbuckのコーヒーBuy-10-Get-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]

- Better Business Bureau [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, ...]

- 獲得した学位証明[PhD、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.

- 私はsysadminです。セージが署名した証明書を持ちたいと思っています。

- 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です。日、または週、または...

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は特定のアプリケーションのドメインにある必要があります...たとえば、「このホストのシステム管理者」証明書はおそらく監査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.

- 私はアマチュアラジオオペレーターです。ドキュメントが発行したアマチュアラジオに従事することを許可されているという署名済みの証明書が欲しいです。[現在、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ドルまでの購入を許可されていることを伝える証明書を所有したいと思います。サプライヤーに私の名前を知りたくありません。単一の「メガコープ購入部門証明書」を同じ仕事をしている他の人と共有する必要はありません。

- "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.]

- 「私はこのRFC822メールアドレスに送信されたメールの正当な受信者です。[これは、誰かが特定の電子メールアドレスを所有していることを知っている場合ですが、私は彼らの鍵を知りません。]

- Encryption keys for E-mail and file encryption

- 電子メールおよびファイル暗号化用の暗号化キー

- 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).

- 信頼モデルはWebでなければなりません（人々は自分が信頼する人を選択したいです）。人々は、信頼できる人を選択したり、信頼できるルーツを検討したりすることができなければなりません（信頼性がさまざまである可能性があります）。

- 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.

- キーは、頻繁に使用されるキーを取得する長い遅延を回避するために、ローカルでキャッシュする必要があります。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?

- 誰かが私の秘密鍵で脅迫的な電子メールメッセージにデジタル的に署名し、それを社長@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.

属性の欠如は、すべての関連レコードがデジタル化され、すべての関係者が避けられない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.

証明書は、「まだ結婚していない」または「他の地区の有権者として登録されていない」「ポジティブ」属性を伝えることができます。それは、一部の組織が特定のキーホルダーのその事実を決定できると仮定しています。このような否定的な事実を決定する方法は、証明書の定義の一部ではありません。

- 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] Diffie and Hellman、「暗号化の新しい方向」、IEEE情報に関する取引IT-22、6（1976年11月）、644- 654。

[KOHN] Loren Kohnfelder, "Towards a Practical Public-key Cryptosystem", Bachelor's thesis, MIT, May, 1978.

[Kohn] Loren Kohnfelder、「実用的な公共キー暗号システムに向けて」、学士論文、MIT、1978年5月。

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

Carl M. Ellison Intel Corporation 2111 NE 25th Ave M/S JF3-212ヒルズボロまたは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
        

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (1999). All Rights Reserved.

Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。