[要約] 要約：RFC 2316は、IABセキュリティアーキテクチャワークショップの報告書であり、インターネットのセキュリティに関する重要な問題と提案が含まれています。 目的：このRFCの目的は、インターネットのセキュリティアーキテクチャに関する情報を提供し、セキュリティの向上に貢献することです。
Network Working Group S. Bellovin
Request for Comments: 2316 AT&T Labs Research
Category: Informational April 1998
Report of the IAB Security Architecture Workshop
IABセキュリティアーキテクチャワークショップのレポート
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
On 3-5 March 1997, the IAB held a security architecture workshop at Bell Labs in Murray Hill, NJ. We identified the core security components of the architecture, and specified several documents that need to be written. Most importantly, we agreed that security was not optional, and that it needed to be designed in from the beginning.
1997年3月3〜5日に、IABはニュージャージー州マレーヒルのベル研究所でセキュリティアーキテクチャワークショップを開催しました。アーキテクチャのコアセキュリティコンポーネントを特定し、作成する必要があるいくつかのドキュメントを指定しました。最も重要なこととして、セキュリティはオプションではなく、最初から設計する必要があることに同意しました。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119で説明されているように解釈されます。
On 3-5 March 1997, the IAB held a security architecture workshop at Bell Labs in Murray Hill, NJ. The ultimate goal was to design a security architecture for the Internet. More concretely, we wished to understand what security tools and protocols exist or are being developed, where each is useful, and where we are missing adequate security tools. Furthermore, we wanted to provide useful guidance to protocol designers. That is, if we wish to eliminate the phrase "security issues are not discussed in this memo" from future RFCs, we must provide guidance on acceptable analyses.
1997年3月3〜5日に、IABはニュージャージー州マレーヒルのベル研究所でセキュリティアーキテクチャワークショップを開催しました。最終的な目標は、インターネットのセキュリティアーキテクチャを設計することでした。より具体的には、どのセキュリティツールとプロトコルが存在するか、または開発中であるか、それらがどこで役立つか、適切なセキュリティツールが不足している場所を理解したいと考えました。さらに、プロトコル設計者に役立つガイダンスを提供したいと考えました。つまり、将来のRFCから「このメモでセキュリティの問題は議論されていません」というフレーズを排除したい場合、許容可能な分析に関するガイダンスを提供する必要があります。
There were twenty-four attendees (their names are listed in Appendix A). Perhaps not surprisingly for such a group, the overwhelming majority used some form of cryptography when connecting back to their home site from the meeting room. But the situation on the rest of the Internet is not nearly as good; few people use encryption, even when they should.
出席者は24名でした（名前は付録Aに記載されています）。おそらくそのようなグループにとっては当然のことですが、圧倒的多数が、会議室からホームサイトに接続するときに何らかの形式の暗号を使用しました。しかし、インターネットの残りの部分の状況はそれほど良くはありません。暗号化を使用する場合でも、使用する人はほとんどいません。
The problem is that the rate of attacks is increasing. Apart from the usual few elite hackers -- the ones who find the new holes -- there are many canned exploit scripts around. ("Click here to attack this system.") Furthermore, the attackers have gotten smarter; rather than going after random university machines, more and more are targeting the Internet infrastructure, such as routers, high-level name servers, and the like.
問題は、攻撃の割合が増加していることです。通常の少数のエリートハッカー（新しい穴を見つけるハッカー）を除いて、多くの缶詰のエクスプロイトスクリプトがあります。 （「このシステムを攻撃するには、ここをクリックしてください。」）さらに、攻撃者は賢くなりました。ランダムな大学のマシンを追いかけるのではなく、ルーターや高レベルのネームサーバーなどのインターネットインフラストラクチャをターゲットにするものが増えています。
The problem is compounded by organizational laziness. Users and system administrators want "magic security" -- they want whatever they do to be secure, regardless of whether or not it is, or even can be.
問題は組織の怠惰によってさらに悪化します。ユーザーとシステム管理者は、「魔法のセキュリティ」を求めています。つまり、セキュリティがそうであるかどうかに関係なく、セキュリティで保護されていることを望んでいます。
We concluded that in general, end-to-end security is better. Thus, one should use something like PGP or S/MIME for email, rather than relying on an IPsec layer. In general, relying on the security of the infrastructure is a bad idea; it, too, is under attack. Even firewall-protected intranets can be subverted. At best, the infrastructure should provide availability; it is the responsibility of individual protocols not to make unreasonable demands on the infrastructure during an attack.
一般に、エンドツーエンドのセキュリティの方が優れていると結論付けました。したがって、IPsecレイヤーに依存するのではなく、PGPやS / MIMEなどを電子メールに使用する必要があります。一般に、インフラストラクチャのセキュリティに依存することは悪い考えです。それも攻撃を受けています。ファイアウォールで保護されたイントラネットでさえ、破壊される可能性があります。せいぜい、インフラストラクチャは可用性を提供する必要があります。攻撃中にインフラストラクチャに不当な要求をしないことは、個々のプロトコルの責任です。
Our security problem is compounded by the IETF's inherent structure (or, in some cases, the lack thereof). By intent, we are a volunteer organization. Who should do the security work? The other protocol designers? Often, they have neither the time nor the interest nor the training to do it. Security area members? What if they are not interested in some subject area, or lack the time themselves? We cannot order them to serve.
私たちのセキュリティ問題は、IETFの固有の構造（または、場合によってはその欠如）によってさらに悪化します。意図的に、私たちはボランティア組織です。誰がセキュリティ作業を行うべきですか？他のプロトコル設計者は？多くの場合、彼らには時間も興味もそれを行うためのトレーニングもありません。セキュリティエリアのメンバーですか？彼らが特定の分野に興味がない、または自分自身に時間がない場合はどうなりますか？奉仕するように注文することはできません。
To the extent that the IETF does have management, it is embodied in the working group charters. These are in essence contracts between the IESG and a working group, spelling out what is to be done and on what schedule. Can the IESG unilaterally impose new requirements on existing working groups? What if security cannot be added on without substantial changes to the fundamental structure of a protocol that has been reworked over several years? Finally, there is a perception problem: that IPsec will somehow solve the security problem. It won't; indeed, it can't. IPsec provides excellent protection of packets in transit. But it's hard to deploy on individual hosts, does not protect objects that may be retransmitted (i.e., email messages), does not address authorization issues, cannot block against excess resource consumption, etc.
IETFが管理している範囲で、ワーキンググループの憲章に具体化されています。これらは、本質的には、IESGとワーキンググループの間の契約であり、何をすべきか、どのようなスケジュールで行うかを明記しています。 IESGは一方的に既存のワーキンググループに新しい要件を課すことができますか？数年にわたって作り直されたプロトコルの基本的な構造に実質的な変更なしにセキュリティを追加できない場合はどうなりますか？最後に、知覚の問題があります。IPsecがセキュリティの問題を何とか解決するということです。それはしません。確かに、それはできません。 IPsecは、転送中のパケットの優れた保護を提供します。ただし、個々のホストにデプロイするのは難しく、再送信される可能性のあるオブジェクト（つまり、電子メールメッセージ）を保護せず、認証の問題に対処せず、過剰なリソース消費をブロックできません。
Collectively, we decided on several documents that need to be written:
まとめて、作成する必要があるいくつかのドキュメントを決定しました。
Taxonomy of Attacks In order to defend a protocol against attacks, one must, of course, know the kinds of attacks that are possible. While the specifics differ from protocol to protocol, a number of general categories can be constructed.
攻撃の分類法プロトコルを攻撃から守るためには、もちろん、可能な攻撃の種類を知っている必要があります。詳細はプロトコルごとに異なりますが、多くの一般的なカテゴリを構成できます。
Implementation Hints and Pitfalls Even if a protocol is sound, a host running it can be vulnerable if the protocol is implemented improperly. A variety of common errors can and do subvert the best designs.
実装のヒントと落とし穴プロトコルが適切である場合でも、プロトコルが正しく実装されていないと、そのプロトコルを実行しているホストが脆弱になる可能性があります。さまざまな一般的なエラーにより、最良の設計が損なわれる可能性があります。
Firewall Issues Firewalls are both a common defense and a much-reviled wart on the Internet. Regardless, they are unlikely to go away any time soon. They have both strengths and weaknesses that must be considered when deploying them. Furthermore, some protocols have characteristics that are unnecessarily firewall-hostile; such practices should be avoided.
ファイアウォールの問題ファイアウォールは、一般的な防御策であり、インターネット上の非常に邪悪ないぼです。とにかく、彼らはすぐになくなることはほとんどありません。それらには、展開時に考慮しなければならない長所と短所の両方があります。さらに、一部のプロトコルには、不必要にファイアウォールに敵対する特性があります。そのような慣行は避けるべきです。
Workshop Report This document.
ワークショップレポートこのドキュメント。
The actual text in the working group charter is likely to be something fairly simple, like
ワーキンググループ憲章の実際のテキストは、次のようなかなり単純なものになる可能性があります。
Protocols developed by this working group will be analyzed for potential sources of security breach. Identified threats will be removed from the protocol if possible, and documented and guarded against in other cases.
このワーキンググループによって開発されたプロトコルは、セキュリティ侵害の潜在的な原因について分析されます。特定された脅威は、可能であればプロトコルから削除され、文書化され、他の場合には保護されます。
The actual charter text represents a policy enjoined and enforced by the IESG, and may change from time to time and from charter to charter. However, it essentially references and asks for text in documents conforming to the following, which may be very appropriate to include in the RFC.
実際のチャーターテキストは、IESGによって強制および施行されるポリシーを表しており、チャーターからチャーターへと随時変更される可能性があります。ただし、基本的には、以下に準拠するドキュメント内のテキストを参照および要求します。これは、RFCに含めるのに非常に適切な場合があります。
A "threat" is, by definition, a vulnerability available to a motivated and capable adversary. CERT advisories are quite predictable given a knowledge of the target of the threat; they therefore represent an existence proof, but not a threat analysis. The point is to determine what attacks are possible ("capabilities" of a potential attacker) and formulate a defense against the attacks, or convincingly argue that the attack is not realistic in some environment and restrict use of the protocol to that environment.
「脅威」は、定義により、やる気があり有能な敵が利用できる脆弱性です。 CERTアドバイザリは、脅威の対象に関する知識があれば、かなり予測可能です。したがって、それらは存在の証拠を表しますが、脅威分析ではありません。重要なのは、可能な攻撃（潜在的な攻撃者の「機能」）を特定し、攻撃に対する防御策を策定することです。または、環境によっては攻撃が現実的ではなく、プロトコルの使用をその環境に限定することを説得します。
Recommended guidelines:
推奨ガイドライン：
All RFCs - MUST meaningfully address security in the protocol or procedure it specifies. It MUST consider that it is giving its data to "the enemy" and asking it to be delivered to its friends and used in the manner it intended. Consideration MUST be given to the ramifications of the inherent danger of the situation.
すべてのRFC-それが指定するプロトコルまたは手順のセキュリティに意味のある対処をしなければなりません。それはそのデータを「敵」に提供していることを考慮しなければならず、それを友人に配信し、意図した方法で使用するように要求します。状況の固有の危険性の影響を考慮する必要があります。
- MUST do "due diligence" to list the threats to which the protocol is vulnerable. Use of legal term does not imply legal liability, but rather the level of responsibility expected to be applied to the analysis. This discussion might occur throughout the document or in the Security Considerations section; if it occurs throughout, it MUST be summarized and referenced in the Security Considerations section.
- プロトコルが脆弱である脅威をリストするために「デューデリジェンス」を行わなければなりません。法的用語の使用は法的責任を意味するのではなく、分析に適用されることが予想される責任のレベルを意味します。この説明は、ドキュメント全体またはセキュリティの考慮事項セクションで発生する可能性があります。全体的に発生する場合は、「セキュリティの考慮事項」セクションで要約および参照する必要があります。
- MUST discuss which of those threats are * Ameliorated by protocol mechanisms (example: SYN attack is ameliorated by clever code that drops sessions randomly when under SYN attack)
- それらの脅威のどれが議論されなければならないか*プロトコルメカニズムによって改善されます（例：SYN攻撃は、SYN攻撃を受けているときにセッションをランダムにドロップする巧妙なコードによって改善されます）
* Ameliorated by reliance on external mechanisms (example: TCP data confidentiality provided by IPSEC ESP)
* 外部メカニズムへの依存によって改善（例：IPSEC ESPによって提供されるTCPデータの機密性）
* Irrelevant ("In most cases, MIBs are not themselves security risks; If SNMP Security is operating as intended, the use of a MIB to change the configuration of a system is a tool, not a threat. For a threat analysis of SNMP Security, see RFC ZZZZ.")
* 無関係（「ほとんどの場合、MIB自体はセキュリティリスクではありません。SNMPセキュリティが意図したとおりに動作している場合、システムの構成を変更するためのMIBの使用は、脅威ではなくツールです。SNMPセキュリティの脅威分析では、 RFC ZZZZを参照してください。」）
* Not addressed by the protocol; results in applicability statement. ("This protocol should not be used in an environment subject to this attack")
* プロトコルでは扱われません。結果は適用性のステートメントになります。 （「このプロトコルは、この攻撃の影響を受ける環境では使用しないでください」）
A variety of security mechanisms exist today. Not all are well-designed; not all are suitable for all purposes. The members of the workshop designated a number of protocols as "core". Such protocols should be used preferentially, if one of them has properties that match the needs of your protocol. The following were designated as core:
今日、さまざまなセキュリティメカニズムが存在しています。すべてがうまく設計されているわけではありません。すべてがすべての目的に適しているわけではありません。ワークショップのメンバーは、いくつかのプロトコルを「コア」として指定しました。これらのプロトコルの1つがプロトコルのニーズに一致するプロパティを持っている場合、それらのプロトコルを優先的に使用する必要があります。以下はコアとして指定されました。
IPsec [RFC 1825] is the basic host-to-host security mechanism. It is appropriate for use any time address-based protection would have been used, including with such programs as rsh and rlogin. If and when platforms support user-based keying, this scope may be expanded.
IPsec [RFC 1825]は、基本的なホスト間のセキュリティメカニズムです。これは、rshやrloginなどのプログラムを含め、アドレスベースの保護が使用されていた場合に使用するのに適しています。プラットフォームがユーザーベースのキーイングをサポートしている場合は、このスコープを拡張できます。
One particular technique used by IPsec, HMAC [RFC 2104], is more generally useful. If cryptographic authentication but not secrecy is needed, and IPsec is not applicable, HMAC should be used.
IPsecで使用される特定の手法であるHMAC [RFC 2104]は、より一般的に有用です。暗号化認証は必要であるが秘密性は必要なく、IPsecが適用できない場合は、HMACを使用する必要があります。
ISAKMP/Oakley [ISAKMP drafts] is the basic key negotiation protocol for IPsec. As such, it should be deployed when IPsec is used. With the appropriate "domain of interpretation" document, it should be used to negotiate pairwise keys for other protocols.
ISAKMP / Oakley [ISAKMPドラフト]は、IPsecの基本的なキーネゴシエーションプロトコルです。そのため、IPsecを使用する場合に展開する必要があります。適切な「解釈のドメイン」ドキュメントを使用して、他のプロトコルのペアワイズキーのネゴシエーションに使用する必要があります。
DNSsec [RFC 2065] is not only crucial for protecting the DNS -- cache contamination is the easiest way to launch active attacks -- it's also needed in many situations when IPsec is used.
DNSsec [RFC 2065]はDNSを保護するために重要であるだけではありません-キャッシュ汚染はアクティブな攻撃を開始する最も簡単な方法です-IPsecが使用される多くの状況でも必要です。
Security/Multipart [RFC 1847] is the preferred way to add secured sections to MIME-encapsulated email.
セキュリティ/マルチパート[RFC 1847]は、MIMEカプセル化電子メールに保護されたセクションを追加するための推奨される方法です。
Signed keys in the DNS. There is, as noted, widespread agreement that DNS records themselves must be protected. There was less agreement that the key records should be signed themselves, making them in effect certificates. Still, this is one promising avenue for Internet certificates.
DNSの署名済みキー。前述のように、DNSレコード自体を保護する必要があるという広範な合意があります。主要なレコードが自分自身で署名され、実質的に証明書になる必要があるという合意はあまりありませんでした。それでも、これはインターネット証明書の有望な手段の1つです。
X.509v3 is the other obvious choice for a certificate infrastructure. Again, though, there was no strong consensus on this point.
X.509v3は、証明書インフラストラクチャのもう1つの明白な選択肢です。繰り返しますが、この点については強いコンセンサスはありませんでした。
TLS [TLS draft] was seen by some as the preferred choice for transport-layer security, though there was no consensus on this point. TLS is less intrusive to the operating system than IPsec; additionally, it is easier to provide fine-grained protection this way.
TLS [TLSドラフト]は、トランスポート層セキュリティの好ましい選択であると見られていましたが、この点についてコンセンサスはありませんでした。 TLSは、IPsecよりオペレーティングシステムへの侵入が少なくなります。さらに、この方法で細かい保護を提供する方が簡単です。
Some protocols were designated as "useful but not core". These were insufficiently general, too new, or were substantially duplicative of core protocols. These include AFT/SOCKS, RADIUS, firewalls, GSS-API, PGP, Kerberos, PGP-MIME, PKIX-3, the various forms of per-hop authentication (OSPF, RSVP, RIPv2), *POP, OTP, S/MIME, SSH, PFKey, IPsec API, SASL, and CRAM/CHAP. Obviously, entries on this list may move in either direction.
一部のプロトコルは「有用ではあるがコアではない」と指定されました。これらは一般的ではなかった、新しすぎた、またはコアプロトコルと実質的に重複していた。これらには、AFT / SOCKS、RADIUS、ファイアウォール、GSS-API、PGP、Kerberos、PGP-MIME、PKIX-3、さまざまな形式のホップごとの認証（OSPF、RSVP、RIPv2）、* POP、OTP、S / MIMEが含まれます、SSH、PFKey、IPsec API、SASL、CRAM / CHAP。明らかに、このリストのエントリはどちらの方向にも移動する可能性があります。
A few protocols were considered "not useful". Primarily, these are ones that have failed to catch on, even though they've been available for some time. These include PEM [RFC 1421, 1422, 1423, 1424] and MOSS [RFC 1848]. (The phrase "not useful" does not imply that they are incorrect, or are lacking in important information. However, they do not describe protocols that we are currently encouraging the use of.)
いくつかのプロトコルは「役に立たない」と見なされました。主に、これらはしばらくの間利用可能であったとしても、キャッチすることができなかったものです。これらには、PEM [RFC 1421、1422、1423、1424]およびMOSS [RFC 1848]が含まれます。 （「役に立たない」という表現は、それらが正しくない、または重要な情報が不足していることを意味するものではありません。ただし、現在使用を推奨しているプロトコルについては説明していません。）
One security mechanism was deemed to be unacceptable: plaintext passwords. That is, no protocol that relies on passwords sent over unencrypted channels is acceptable.
セキュリティメカニズムの1つは受け入れられないと見なされました：プレーンテキストのパスワード。つまり、暗号化されていないチャネルを介して送信されるパスワードに依存するプロトコルは受け入れられません。
Participants in the workshop identified three significant missing pieces: object security, secure email, and route security.
ワークショップの参加者は、オブジェクトのセキュリティ、安全な電子メール、ルートのセキュリティという3つの重要な欠落部分を特定しました。
Object security refers to protection for individual data objects, independent of transport. We have one such already -- Secure DNS -- but we need a me general scheme. MIME is a candidate object framework, in part because it is the core of the two most widely used and deployed applications: the web and email. However, securing email has been problematic and the web is not that far in front.
オブジェクトセキュリティとは、トランスポートとは関係なく、個々のデータオブジェクトを保護することです。私たちはすでにそのようなものを持っています-セキュアDNS-しかし、私には一般的なスキームが必要です。 MIMEは、オブジェクトフレームワークの候補です。これは、最も広く使用され展開されている2つのアプリケーション（Webと電子メール）の中核であることもあります。ただし、電子メールのセキュリティ保護には問題があり、Webはそれほど前ではありません。
Secure email is a critical need and has been for some time. Two attempts to standardize secure email protocols (PEM and MOSS) have failed to be accepted by the community, while a third protocol (PGP) has become a de facto standard around the world. A fourth protocol, an industry standard (S/MIME), has been gaining popularity. Both of these latter of entered the Internet standards process.
安全な電子メールは重要なニーズであり、しばらくの間存在しています。安全な電子メールプロトコル（PEMおよびMOSS）を標準化する2つの試みはコミュニティに受け入れられず、3番目のプロトコル（PGP）は世界中で事実上の標準になりました。 4番目のプロトコルは業界標準（S / MIME）で、人気が高まっています。後者はどちらもインターネット標準化プロセスに入りました。
Route security has recently become a critical need. The sophistication of the attackers is on the rise and the availability of attacking toolkits has increased the number of sophisticated attacks. This task is especially complex because the requirement for maximum performance conflicts with the goal of adding security, which usurps resources that would otherwise enhance the performance of the router.
ルートのセキュリティは最近重要なニーズになっています。攻撃者の巧妙化が進んでおり、攻撃ツールキットの可用性により、高度な攻撃の数が増加しています。最大のパフォーマンスの要件は、セキュリティを追加するという目標と矛盾するため、このタスクは特に複雑です。これは、ルーターのパフォーマンスを向上させるリソースを奪うことになります。
Security is not and cannot be a cookie cutter process. There is no magic pixie dust that can be sprinkled over a protocol to make it secure. Each protocol must be analyzed individually to determine what vulnerabilities exist, what risks they may lead to, what palliative measures can be taken, and what the residual risks are.
セキュリティは、クッキーカッタープロセスではありません。それを安全にするためにプロトコルに振りかけることができる魔法のピクシーダストはありません。各プロトコルを個別に分析して、存在する脆弱性、それらがもたらす可能性のあるリスク、実行可能な緩和策、および残存リスクを特定する必要があります。
This RFC is largely based on the minutes compiled by Thomas Narten, whose work in turn was partly based on notes by Erik Huizer, John Richardson, and Bob Blakley.
このRFCは、主にThomas Nartenによって編集された議事録に基づいており、その作業の一部はErik Huizer、John Richardson、およびBob Blakleyによるメモに基づいていました。
[RFC 1825] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995.
[RFC 1825] Atkinson、R。、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 1825、1995年8月。
[RFC 2104] Krawcyzk, H., Bellare, M., and R. Canett, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC 2104] Krawcyzk、H.、Bellare、M。、およびR. Canett、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[ISAKMP drafts] Works in Progress.
[ISAKMPドラフト]作業中。
[RFC 2065] Eastlake, D., and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997.
[RFC 2065] Eastlake、D。、およびC. Kaufman、「ドメインネームシステムセキュリティ拡張機能」、RFC 2065、1997年1月。
[RFC 1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[RFC 1847] Galvin、J.、Murphy、S.、Crocker、S。、およびN. Freed、「MIMEのセキュリティマルチパート：Multipart / SignedおよびMultipart / Encrypted」、RFC 1847、1995年10月。
[TLS draft] Dierks, T., and C. Allen, "The TLS Protocol Version 1.0", Work in Progress.
[TLSドラフト] Dierks、T。、およびC.アレン、「TLSプロトコルバージョン1.0」、作業中。
[RFC 1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993.
[RFC 1421] Linn、J.、「インターネット電子メールのプライバシー強化：パートI：メッセージの暗号化と認証手順」、RFC 1421、1993年2月。
[RFC 1422] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management", RFC 1422, February 1993.
[RFC 1422]ケントS.、「インターネット電子メールのプライバシー強化：パートII：証明書ベースのキー管理」、RFC 1422、1993年2月。
[RFC 1423] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, February 1993.
[RFC 1423]バレンソン、D。、「インターネット電子メールのプライバシー強化：パートIII：アルゴリズム、モード、および識別子」、RFC 1423、1993年2月。
[RFC 1424] Kaliski, B. "Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services", RFC 1424, February 1993.
[RFC 1424] Kaliski、B。「インターネット電子メールのプライバシー強化：パートIV：主要な認証および関連サービス」、RFC 1424、1993年2月。
[RFC 1848] Crocker, S., Freed, N., Galvin, J. and S. Murphy, "MIME Object Security Services", RFC 1848, October 1995.
[RFC 1848] Crocker、S.、Freed、N.、Galvin、J.、S。Murphy、「MIME Object Security Services」、RFC 1848、1995年10月。
Ran Atkinson rja@inet.org Fred Baker fred@cisco.com Steve Bellovin bellovin@acm.org Bob Blakley blakley@vnet.ibm.com Matt Blaze mab@research.att.com Brian Carpenter brian@hursley.ibm.com Jim Ellis jte@cert.org James Galvin galvin@commerce.net Tim Howes howes@netscape.com Erik Huizer Erik.Huizer@sec.nl Charlie Kaufman charlie_kaufman@iris.com Steve Kent kent@bbn.com Paul Krumviede paul@mci.net Marcus Leech mleech@nortel.ca Perry Metzger perry@piermont.com Keith Moore moore@cs.utk.edu Robert Moskowitz rgm@htt-consult.com John Myers jgm@CMU.EDU Thomas Narten narten@raleigh.ibm.com Radia Perlman radia.perlman@sun.com John Richardson jwr@ibeam.jf.intel.com Allyn Romanow allyn@mci.net Jeff Schiller jis@mit.edu Ted T'So tytso@mit.edu
Ran Atkinson rja@inet.org Fred Baker fred@cisco.com Steve Bellovin bellovin@acm.org Bob Blakley blakley@vnet.ibm.com Matt Blaze mab@research.att.com Brian Carpenter brian@hursley.ibm.com Jim Ellis jte@cert.org James Galvin galvin@commerce.net Tim Howes howes@netscape.com Erik Huizer Erik.Huizer@sec.nl Charlie Kaufman charlie_kaufman@iris.com Steve Kent kent@bbn.com Paul Krumviede paul@mci.net Marcus Leech mleech@nortel.ca Perry Metzger perry@piermont.com Keith Moore moore@cs.utk.edu Robert Moskowitz rgm@htt-consult.com John Myers jgm@CMU.EDU Thomas Narten narten@raleigh.ibm.com Radia Perlman radia .perlman @ sun.com John Richardson jwr@ibeam.jf.intel.com Allyn Romanow allyn@mci.net Jeff Schiller jis@mit.edu Ted T'So tytso@mit.edu
Steven M. Bellovin AT&T Labs Research 180 Park Avenue Florham Park, NJ 07932 USA
Steven M. Bellovin AT＆T Labs Research 180 Park Avenue Florham Park、NJ 07932 USA
Phone: (973) 360-8656 EMail: bellovin@acm.org
電話：（973）360-8656メール：bellovin@acm.org
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。