RFC1984 日本語訳

1984 IAB and IESG Statement on Cryptographic Technology and theInternet. IAB, IESG. August 1996. (Format: TXT=10738 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                                IAB
Request for Comments: 1984                                          IESG
Category: Informational                                      August 1996

ネットワークワーキンググループIABはコメントのために以下を要求します。 1984年のIESGカテゴリ: 情報の1996年8月

  IAB and IESG Statement on Cryptographic Technology and the Internet

暗号の技術とインターネットに関するIABとIESG声明

Status of This Memo

このメモの状態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright

著作権

   (C) Internet Society 1996.  Reproduction or translation of the
   complete document, but not of extracts, including this notice, is
   freely permitted.

(C) インターネット協会1996。 この通知を含む抽出ではなく、完全なドキュメントに関する再現か翻訳が自由に受入れられます。

July 24, 1996

1996年7月24日

   The Internet Architecture Board (IAB) and the Internet Engineering
   Steering Group (IESG), the bodies which oversee architecture and
   standards for the Internet, are concerned by the need for increased
   protection of international commercial transactions on the Internet,
   and by the need to offer all Internet users an adequate degree of
   privacy.

インターネット・アーキテクチャ委員会(IAB)とインターネットEngineering Steering Group(IESG)(インターネットのアーキテクチャと規格を監督するボディー)はインターネットにおける国際的な商業トランザクションの増強された保護の必要性、および適切な度合いのプライバシーをすべてのインターネットユーザに提供する必要性によって関係があらせます。

   Security mechanisms being developed in the Internet Engineering Task
   Force to meet these needs require and depend on the international use
   of adequate cryptographic technology.  Ready access to such
   technology is therefore a key factor in the future growth of the
   Internet as a motor for international commerce and communication.

これらの需要を満たすためにインターネット・エンジニアリング・タスク・フォースで開発されるセキュリティー対策は、適切な暗号の技術の国際的な使用に必要であり、よります。 したがって、そのような技術への持ち合わせのアクセスは国際通商とコミュニケーションのためのモーターとしてのインターネットの今後の成長で主要因です。

   The IAB and IESG are therefore disturbed to note that various
   governments have actual or proposed policies on access to
   cryptographic technology that either:

したがって、IABとIESGは様々な政府には暗号の技術へのアクセスに関する実際の、または、提案された方針がそんなにのどちらかあることに注意するために擾乱されます:

   (a) impose restrictions by implementing export controls; and/or

(a) 輸出がコントロールであると実装することによって、制限を課してください。 そして/または

   (b) restrict commercial and private users to weak and inadequate
       mechanisms such as short cryptographic keys; and/or

(b) 商業的、そして、個人的なユーザを短い暗号化キーなどの弱くて不十分なメカニズムに制限してください。 そして/または

   (c) mandate that private decryption keys should be in the hands of
       the government or of some other third party; and/or

(c) 個人的な復号化キーが政府かある他の第三者の手にあるはずであるのを強制してください。 そして/または

   (d) prohibit the use of cryptology entirely, or permit it only to
       specially authorized organizations.

(d) 暗号理論の使用を完全に禁止するか、または特に認可された組織だけにそれを可能にしてください。

IAB & IESG                   Informational                      [Page 1]

RFC 1984                Cryptographic Technology             August 1996

技術1996年8月の暗号のIAB&IESG情報[1ページ]のRFC1984

   We believe that such policies are against the interests of consumers
   and the business community, are largely irrelevant to issues of
   military security, and provide only a marginal or illusory benefit to
   law enforcement agencies, as discussed below.

私たちは、そのような方針が消費者の関心と業界に反対していて、軍事のセキュリティの問題と主に無関係であり、警察機関へのマージンの、または、非現実的な利益だけを提供すると信じています、以下で議論するように。

   The IAB and IESG would like to encourage policies that allow ready
   access to uniform strong cryptographic technology for all Internet
   users in all countries.

IABとIESGはすべての国のすべてのインターネットユーザのために一定の強い暗号の技術への持ち合わせのアクセスを許す方針を奨励したがっています。

The IAB and IESG claim:

IABとIESGクレーム:

   The Internet is becoming the predominant vehicle for electronic
   commerce and information exchange. It is essential that the support
   structure for these activities can be trusted.

インターネットは電子商取引と情報交換のための支配的な手段になっています。 これらの活動のためのサポート構造を信じることができるのは不可欠です。

   Encryption is not a secret technology monopolized by any one country,
   such that export controls can hope to contain its deployment. Any
   hobbyist can program a PC to do powerful encryption. Many algorithms
   are well documented, some with source code available in textbooks.

暗号化はどんな国によっても独占された、秘密の技術ではありません、輸出管理が、展開を含むことを望むことができるように。 どんな趣味に熱中する人も、強力な暗号化をするようにPCにプログラムできます。 多くのアルゴリズムがよく記録されて、中に利用可能なソースコードがある何かが教科書です。

   Export controls on encryption place companies in that country at a
   competitive disadvantage. Their competitors from countries without
   export restrictions can sell systems whose only design constraint is
   being secure, and easy to use.

その国の暗号化場所会社で競争力において不利な立場でコントロールをエクスポートしてください。 輸出制限のない国からの彼らの競争相手は唯一のデザイン規制は、安全であって、使用するのが、簡単な状態であるシステムを販売できます。

   Usage controls on encryption will also place companies in that
   country at a competitive disadvantage because these companies cannot
   securely and easily engage in electronic commerce.

また、これらの会社がしっかりと、容易に電子商取引に従事できないので、暗号化の用法コントロールはその国の会社を競争力において不利な立場にみなすでしょう。

   Escrow mechanisms inevitably weaken the security of the overall
   cryptographic system, by creating new points of vulnerability that
   can and will be attacked.

エスクローメカニズムは必然的に総合的な暗号のシステムのセキュリティを弱めます、攻撃できて、攻撃される新しいポイントの脆弱性を作成することによって。

   Export controls and usage controls are slowing the deployment of
   security at the same time as the Internet is exponentially increasing
   in size and attackers are increasing in sophistication. This puts
   users in a dangerous position as they are forced to rely on insecure
   electronic communication.

輸出管理と用法コントロールはインターネットと同時のセキュリティの展開がサイズで指数関数的に増強している遅くなることです、そして、攻撃者は洗練を増やしています。 彼らがやむを得ず不安定な電子コミュニケーションを当てにするとき、これは危険な位置にユーザを入れます。

TECHNICAL ANALYSIS

テクニカル分析

KEY SIZE

主要なサイズ

   It is not acceptable to restrict the use or export of cryptosystems
   based on their key size.  Systems that are breakable by one country
   will be breakable by others, possibly unfriendly ones.  Large
   corporations and even criminal enterprises have the resources to
   break many cryptosystems.  Furthermore, conversations often need to

それらの主要なサイズに基づく暗号系の使用か輸出を制限するのは許容できません。 1つの国が壊れやすいシステムは他のもの、ことによると無愛想なもので壊れやすくなるでしょう。 大企業と刑事上の企業でさえ、多くの暗号系を壊すリソースがあります。その上、会話は、しばしば必要があります。

IAB & IESG                   Informational                      [Page 2]

RFC 1984                Cryptographic Technology             August 1996

技術1996年8月の暗号のIAB&IESG情報[2ページ]のRFC1984

   be protected for years to come; as computers increase in speed, key
   sizes that were once out of reach of cryptanalysis will become
   insecure.

長年、保護されてください。 コンピュータが速度を増やすのに従って、かつて暗号文解読術の範囲から脱していた主要なサイズは不安定になるでしょう。

PUBLIC KEY INFRASTRUCTURE

公開鍵認証基盤

   Use of public key cryptography often requires the existence of a
   "certification authority".  That is, some third party must sign a
   string containing the user's identity and public key.  In turn, the
   third party's key is often signed by a higher-level certification
   authority.

公開鍵暗号の使用はしばしば「証明権威」の存在を必要とします。 第三者はユーザのアイデンティティと公開鍵を含むストリングに署名しなければなりません。 順番に、第三者のキーはしばしばよりハイレベルの証明権威によって署名されます。

   Such a structure is legitimate and necessary.  Indeed, many
   governments will and should run their own CAs, if only to protect
   citizens' transactions with their governments.  But certification
   authorities should not be confused with escrow centers.  Escrow
   centers are repositories for private keys, while certification
   authorities deal with public keys. Indeed, sound cryptographic
   practice dictates that users never reveal their private keys to
   anyone, even the certification authority.

そのような構造が、正統であって、必要です。 本当に、それらの政府と共に市民のトランザクションを保護するために唯一なら、多くの政府が実行して、それら自身のCAsを実行するべきです。 しかし、証明当局はエスクローセンターに混乱するべきではありません。 エスクローセンターは秘密鍵のための倉庫ですが、証明当局は公開鍵に対処します。 本当に、音の暗号の習慣はユーザがだれも、証明権威にさえ彼らの秘密鍵を決して明らかにしないと決めます。

KEYS SHOULD NOT BE REVEALABLE

キーはREVEALABLEであるべきではありません。

   The security of a modern cryptosystem rests entirely on the secrecy
   of the keys.  Accordingly, it is a major principle of system design
   that to the extent possible, secret keys should never leave their
   user's secure environment.  Key escrow implies that keys must be
   disclosed in some fashion, a flat-out contradiction of this
   principle.  Any such disclosure weakens the total security of the
   system.

現代の暗号系のセキュリティは完全なキーの秘密保持にかかっています。 それに従って、それは範囲の可能で、秘密のキーに彼らのユーザの安全な環境を決して残すべきでないシステム設計の主要な原則です。 キーエスクローは、何らかのファッション、aでキーを完全に明らかにしなければならないのを含意します。この原則の矛盾。 どんなそのような公開もシステムの総合セキュリティを弱めます。

DATA RECOVERY

データ回復

   Sometimes escrow systems are touted as being good for the customer
   because they allow data recovery in the case of lost keys. However,
   it should be up to the customer to decide whether they would prefer
   the more secure system in which lost keys mean lost data, or one in
   which keys are escrowed to be recovered when necessary.  Similarly,
   keys used only for conversations (as opposed to file storage) need
   never be escrowed.  And a system in which the secret key is stored by
   a government and not by the data owner is certainly not practical for
   data recovery.

時々、第三者預託システムは無くなっているキーの場合でデータ回復を許すので顧客にとって良いとして売り込まれます。 しかしながら、必要であるときに、彼らが、無くなっているキーがロストデータを意味するより安全なシステム、またはキーがescrowedされるものが回収されるのを好むかどうか決めるのは、顧客次第であるべきです。 同様に、会話(ファイル記憶装置と対照的に)にだけ使用されるキーを決してescrowedしてはいけません。 そして、確かに、データ回復には、秘密鍵がデータ所有者ではなく、政府によって保存されるシステムは実用的ではありません。

SIGNATURE KEYS

署名キー

   Keys used for signatures and authentication must never be escrowed.
   Any third party with access to such keys could impersonate the
   legitimate owner, creating new opportunities for fraud and deceit.

署名と認証に使用されるキーを決してescrowedしてはいけません。 詐欺と偽りの新しい機会を作成して、そのようなキーへのアクセスのどんな第三者も正統の所有者をまねることができました。

IAB & IESG                   Informational                      [Page 3]

RFC 1984                Cryptographic Technology             August 1996

技術1996年8月の暗号のIAB&IESG情報[3ページ]のRFC1984

   Indeed, a user who wished to repudiate a transaction could claim that
   his or her escrowed key was used, putting the onus on that party.  If
   a government escrowed the keys, a defendant could claim that the
   evidence had been forged by the government, thereby making
   prosecution much more difficult.  For electronic commerce, non-
   repudiation is one of the most important uses for cryptography; and
   non-repudiation depends on the assumption that only the user has
   access to the private key.

本当に、トランザクションを否認したがっていたユーザは、その人のescrowedキーが使用されたと主張できました、そのパーティーに重荷を置いて。 政府がキーをescrowedするなら、被告は、証拠が政府によって作り出されていたと主張できるでしょうに、その結果、起訴をはるかに難しくします。 電子商取引のために、非拒否は暗号への最も重要な用途の1つです。 そして、非拒否はユーザだけが秘密鍵に近づく手段を持っているという前提によります。

PROTECTION OF THE EXISTING INFRASTRUCTURE

既存のインフラストラクチャの保護

   In some cases, it is technically feasible to use cryptographic
   operations that do not involve secrecy.  While this may suffice in
   some cases, much of the existing technical and commercial
   infrastructure cannot be protected in this way.  For example,
   conventional passwords, credit card numbers, and the like must be
   protected by strong encryption, even though some day more
   sophisticated techniques may replace them.  Encryption can be added
   on quite easily; wholesale changes to diverse systems cannot.

いくつかの場合、秘密保持にかかわらない暗号の操作を使用するのは技術的に可能です。 いくつかの場合、これが十分であるかもしれない間、このように既存の技術的で商業のインフラストラクチャの多くを保護できません。 例えば、強い暗号化で従来のパスワード、クレジットカード番号、および同様のものを保護しなければなりません、より精巧なテクニックはいつか、それらに取って代わるかもしれませんが。 全く容易に暗号化を加えることができます。 さまざまのシステムへの大異動はそうすることができません。

CONFLICTING INTERNATIONAL POLICIES

闘争国際的な方針

   Conflicting restrictions on encryption often force an international
   company to use a weak encryption system, in order to satisfy legal
   requirements in two or more different countries.  Ironically, in such
   cases either nation might consider the other an adversary against
   whom commercial enterprises should use strong cryptography.  Clearly,
   key escrow is not a suitable compromise, since neither country would
   want to disclose keys to the other.

国際会社は暗号化の闘争制限によってしばしばやむを得ず弱い暗号化システムを使用します、2つ以上の異なった国で法的必要条件を満たすために。 皮肉にも、そのような場合どちらの国も、もう片方が営利事業が強い暗号を使用するべきである敵であると考えるかもしれません。 どちらの国ももう片方のキーを明らかにしたがっていないでしょう、したがって、明確に、キーエスクローは適当な感染ではありません。

MULTIPLE ENCRYPTION

複数の暗号化

   Even if escrowed encryption schemes are used, there is nothing to
   prevent someone from using another encryption scheme first.
   Certainly, any serious malefactors would do this; the outer
   encryption layer, which would use an escrowed scheme, would be used
   to divert suspicion.

escrowed暗号化体系が使用されていても、何もだれかが最初に別の暗号化体系を使用するのを防ぐものがありません。 確かに、どんな真剣な悪人もこれをするでしょう。 外側の暗号化層(escrowed体系を使用する)は、容疑を紛らすのに使用されるでしょう。

ESCROW OF PRIVATE KEYS WON'T NECESSARILY ALLOW DATA DECRYPTION

秘密鍵のエスクローは必ずデータ復号を許容するというわけではないでしょう。

   A major threat to users of cryptographic systems is the theft of
   long-term keys (perhaps by a hacker), either before or after a
   sensitive conversation.  To counter this threat, schemes with
   "perfect forward secrecy" are often employed.  If PFS is used, the
   attacker must be in control of the machine during the actual
   conversation.  But PFS is generally incompatible with schemes
   involving escrow of private keys.  (This is an oversimplification,
   but a full analysis would be too lengthy for this document.)

暗号のシステムのユーザへの大きな脅威は長期のキー(恐らくハッカーによる)の窃盗です、どちらか敏感な会話の前または後に。 この脅威に対抗するために、「完全な前進の秘密保持」がある体系はしばしば使われます。 PFSが使用されているなら、攻撃者はマシンのコントロール実際の会話の間、中であるに違いありません。 しかし、一般に、PFSは秘密鍵のエスクローにかかわる体系と非互換です。 (これは簡略化のしすぎですが、このドキュメントには、完全な分析は長過ぎるでしょう。)

IAB & IESG                   Informational                      [Page 4]

RFC 1984                Cryptographic Technology             August 1996

技術1996年8月の暗号のIAB&IESG情報[4ページ]のRFC1984

CONCLUSIONS

結論

   As more and more companies connect to the Internet, and as more and
   more commerce takes place there, security is becoming more and more
   critical.  Cryptography is the most powerful single tool that users
   can use to secure the Internet. Knowingly making that tool weaker
   threatens their ability to do so, and has no proven benefit.

ますます多くの会社がインターネットに接続するとき、ますます多くの商業がそこで行われるのに従って、セキュリティはますます重要になっています。 暗号はユーザがインターネットを保証するのに使用できる中で最も強力なただ一つのツールです。 故意に、そのツールをより弱くする場合、そうする彼らの能力が脅かされて、立証された利益は全く持たれていません。

Security Considerations

セキュリティ問題

   Security issues are discussed throughout this memo.

このメモ中で安全保障問題について議論します。

Authors' Addresses

作者のアドレス

   Brian E. Carpenter
   Chair of the IAB
   CERN
   European Laboratory for Particle Physics
   1211 Geneva 23
   Switzerland

IAB CERN欧州原子核共同研究機構1211ジュネーブ23スイスのブライアンE.大工議長

   Phone: +41 22 767-4967
   EMail: brian@dxcoms.cern.ch

以下に電話をしてください。 +41 22 767-4967 メールしてください: brian@dxcoms.cern.ch

   Fred Baker
   Chair of the IETF
   cisco Systems, Inc.
   519 Lado Drive
   Santa Barbara, CA 93111

Lado Driveサンタバーバラ、IETFコクチマスSystems Inc.519カリフォルニア 93111歳のフレッドベイカー議長

   Phone: +1-805-681-0115
   EMail: fred@cisco.com

以下に電話をしてください。 +1-805-681-0115 メールしてください: fred@cisco.com

   The Internet Society is described at http://www.isoc.org/

インターネット協会は http://www.isoc.org/ で説明されます。

   The Internet Architecture Board is described at
   http://www.iab.org/iab

インターネット・アーキテクチャ委員会は http://www.iab.org/iab で説明されます。

   The Internet Engineering Task Force and the Internet Engineering
   Steering Group are described at http://www.ietf.org

インターネット・エンジニアリング・タスク・フォースとインターネットEngineering Steering Groupは http://www.ietf.org で説明されます。

IAB & IESG                   Informational                      [Page 5]

IAB&IESG情報です。[5ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

EC-CUBEでMySQLデータベースのデータ取得で文字化けするときの対処法

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る