RFC2633 日本語訳
2633 S/MIME Version 3 Message Specification. B. Ramsdell, Ed.. June 1999. (Format: TXT=67870 bytes) (Obsoleted by RFC3851) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Ramsdell, Editor Request for Comments: 2633 Worldtalk Category: Standards Track June 1999
ワーキンググループB.Ramsdell、コメントを求めるエディタ要求をネットワークでつないでください: 2633年のWorldtalkカテゴリ: 標準化過程1999年6月
S/MIME Version 3 Message Specification
S/MIMEバージョン3メッセージ仕様
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
1. Introduction
1. 序論
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a consistent way to send and receive secure MIME data. Based on the popular Internet MIME standard, S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity and non-repudiation of origin (using digital signatures) and privacy and data security (using encryption).
S/MIME(安全な/マルチパーパスインターネットメールエクステンション)は安全なMIMEデータを送って、受け取る一貫した方法を提供します。 ポピュラーなインターネットMIME規格に基づいて、S/MIMEは電子メッセージ通信アプリケーションのための以下の暗号のセキュリティー・サービスを提供します: 発生源(デジタル署名を使用する)、プライバシー、およびデータ機密保護(暗号化を使用する)の認証、メッセージの保全、および非拒否。
S/MIME can be used by traditional mail user agents (MUAs) to add cryptographic security services to mail that is sent, and to interpret cryptographic security services in mail that is received. However, S/MIME is not restricted to mail; it can be used with any transport mechanism that transports MIME data, such as HTTP. As such, S/MIME takes advantage of the object-based features of MIME and allows secure messages to be exchanged in mixed-transport systems.
伝統的なメールユーザエージェント(MUAs)は、暗号のセキュリティー・サービスを送られるメールに追加して、受け取られていているメールで暗号のセキュリティー・サービスを解釈するのにS/MIMEを使用できます。 しかしながら、S/MIMEはメールに制限されません。 HTTPなどのMIMEデータを輸送するどんな移送機構と共にもそれを使用できます。 そういうものとして、S/MIMEは、MIMEのオブジェクトベースの特徴を利用して、複雑な輸送システムで交換されるべき安全なメッセージを許容します。
Further, S/MIME can be used in automated message transfer agents that use cryptographic security services that do not require any human intervention, such as the signing of software-generated documents and the encryption of FAX messages sent over the Internet.
さらに、少しの人間の介入も必要としない暗号のセキュリティー・サービスを使用する自動メッセージ証券代行でS/MIMEを使用できます、ソフトウェアで発生しているドキュメントの署名やインターネットの上に送られたFAXメッセージの暗号化のように。
1.1 Specification Overview
1.1 仕様概要
This document describes a protocol for adding cryptographic signature and encryption services to MIME data. The MIME standard [MIME-SPEC] provides a general structure for the content type of Internet messages and allows extensions for new content type applications.
このドキュメントは、暗号の署名と暗号化サービスをMIMEデータに追加するためにプロトコルについて説明します。 MIME規格[MIME-SPEC]は、インターネットメッセージのcontent typeに一般構造体を提供して、新しいcontent typeアプリケーションのために拡大を許します。
Ramsdell Standards Track [Page 1] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[1ページ]。
This memo defines how to create a MIME body part that has been cryptographically enhanced according to CMS [CMS], which is derived from PKCS #7 [PKCS-7]. This memo also defines the application/pkcs7- mime MIME type that can be used to transport those body parts.
このメモはPKCS#7[PKCS-7]から得られるCMS[CMS]に応じて暗号で高められたMIME身体の部分を作成する方法を定義します。 また、このメモはそれらの身体の部分を輸送するのに使用できるアプリケーション/pkcs7パントマイムMIMEの種類を定義します。
This memo also discusses how to use the multipart/signed MIME type defined in [MIME-SECURE] to transport S/MIME signed messages. This memo also defines the application/pkcs7-signature MIME type, which is also used to transport S/MIME signed messages.
また、このメモはメッセージであると署名されるS/MIMEを輸送するために[MIME-SECURE]で定義された複合の、または、署名しているMIMEの種類を使用する方法について議論します。 また、このメモはpkcs7アプリケーション/署名MIMEの種類を定義します。(また、それは、メッセージであると署名されるS/MIMEを輸送するのに使用されます)。
In order to create S/MIME messages, an S/MIME agent has to follow specifications in this memo, as well as the specifications listed in the Cryptographic Message Syntax [CMS].
S/MIMEメッセージを作成するために、S/MIMEエージェントはこのメモによる仕様に従わなければなりません、Cryptographic Message Syntax[CMS]にリストアップされた仕様と同様に。
Throughout this memo, there are requirements and recommendations made for how receiving agents handle incoming messages. There are separate requirements and recommendations for how sending agents create outgoing messages. In general, the best strategy is to "be liberal in what you receive and conservative in what you send". Most of the requirements are placed on the handling of incoming messages while the recommendations are mostly on the creation of outgoing messages.
このメモ中に、要件がありました、そして、推薦は受信エージェントがどう入力メッセージを扱うかになりました。 送付エージェントがどう送信されるメッセージを作成するか別々の要件と推薦があります。 「一般に、最も良い戦略はあなたが受けるもので寛容であって、あなたが送るもので保守的である」ことです。 推薦がほとんど送信されるメッセージの作成にある間、要件の大部分は入力メッセージの取り扱いに置かれます。
The separation for requirements on receiving agents and sending agents also derives from the likelihood that there will be S/MIME systems that involve software other than traditional Internet mail clients. S/MIME can be used with any system that transports MIME data. An automated process that sends an encrypted message might not be able to receive an encrypted message at all, for example. Thus, the requirements and recommendations for the two types of agents are listed separately when appropriate.
また、エージェントを受けて、エージェントを送ることに関する要件のための分離はある見込みから伝統的なインターネット・メールクライアント以外のソフトウェアにかかわるS/MIMEシステムを引き出します。 MIMEデータを輸送するどんなシステムと共にもS/MIMEを使用できます。 暗号化メッセージを送る自動化されたプロセスは全く、そして、例えば暗号化メッセージを受け取ることができないかもしれません。 適切であるときに、したがって、2つのタイプのエージェントのための要件と推薦は別々にリストアップされます。
1.2 Terminology
1.2 用語
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 [MUSTSHOULD].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[MUSTSHOULD]で説明されるように本書では解釈されることであるべきですか?
1.3 Definitions
1.3 定義
For the purposes of this memo, the following definitions apply.
このメモの目的のために、以下の定義は申し込まれます。
ASN.1: Abstract Syntax Notation One, as defined in CCITT X.208.
ASN.1: CCITT X.208で定義されるような抽象的なSyntax Notation One。
BER: Basic Encoding Rules for ASN.1, as defined in CCITT X.209.
BER: ASN.1のためのCCITT X.209で定義されるような基本的なEncoding Rules。
Certificate: A type that binds an entity's distinguished name to a public key with a digital signature.
以下を証明してください。 デジタル署名で実体の分類名を公開鍵に縛るタイプ。
Ramsdell Standards Track [Page 2] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[2ページ]。
DER: Distinguished Encoding Rules for ASN.1, as defined in CCITT X.509.
DER: ASN.1のためのCCITT X.509で定義されるような顕著なEncoding Rules。
7-bit data: Text data with lines less than 998 characters long, where none of the characters have the 8th bit set, and there are no NULL characters. <CR> and <LF> occur only as part of a <CR><LF> end of line delimiter.
7ビットのデータ: 系列998キャラクタが長いテキストデータ、キャラクタのだれにも8番目のビットがないところにセットしてください。そうすれば、NULLキャラクタが全くありません。 <CR>と<LF>は単に<CR><LF>行末デリミタの一部として現れます。
8-bit data: Text data with lines less than 998 characters, and where none of the characters are NULL characters. <CR> and <LF> occur only as part of a <CR><LF> end of line delimiter.
8ビットのデータ: 系列が998のキャラクタとキャラクタのだれもどこのNULLキャラクタでないかより少ないテキストデータ。 <CR>と<LF>は単に<CR><LF>行末デリミタの一部として現れます。
Binary data: Arbitrary data.
バイナリ・データ: 任意のデータ。
Transfer Encoding: A reversible transformation made on data so 8-bit or binary data may be sent via a channel that only transmits 7-bit data.
コード化を移してください: 7ビットのデータを送るだけであるチャンネルであまりに8ビットであるデータでされた可逆的な変換かバイナリ・データを送るかもしれません。
Receiving agent: software that interprets and processes S/MIME CMS objects, MIME body parts that contain CMS objects, or both.
エージェントを受けます: S/MIME CMSオブジェクトを解釈して、処理するソフトウェア、CMSオブジェクトを含むMIME身体の部分、または両方。
Sending agent: software that creates S/MIME CMS objects, MIME body parts that contain CMS objects, or both.
エージェントを送ります: S/MIME CMSオブジェクトを作成するソフトウェア、CMSオブジェクトを含むMIME身体の部分、または両方。
S/MIME agent: user software that is a receiving agent, a sending agent, or both.
S/MIMEエージェント: 受信エージェント、送付エージェント、または両方であるユーザソフトウェア。
1.4 Compatibility with Prior Practice of S/MIME
1.4 S/MIMEの先の習慣との互換性
S/MIME version 3 agents should attempt to have the greatest interoperability possible with S/MIME version 2 agents. S/MIME version 2 is described in RFC 2311 through RFC 2315, inclusive. RFC 2311 also has historical information about the development of S/MIME.
S/MIMEバージョン3エージェントは、最もすばらしい相互運用性をS/MIMEバージョン2エージェントで可能にするのを試みるべきです。 S/MIMEバージョン2は、RFC2315を通してRFC2311で説明されていて、包括的です。 また、RFC2311には、S/MIMEの開発に関する歴史に関する知識があります。
2. CMS Options
2. cmはゆだねます。
CMS allows for a wide variety of options in content and algorithm support. This section puts forth a number of support requirements and recommendations in order to achieve a base level of interoperability among all S/MIME implementations. [CMS] provides additional details regarding the use of the cryptographic algorithms.
CMSは内容とアルゴリズムサポートにおけるさまざまなオプションを考慮します。 このセクションは、すべてのS/MIME実装の中で基準面の相互運用性を達成するために多くのサポート要件と推薦を差し出します。 [CMS]は暗号アルゴリズムの使用に関する追加詳細を明らかにします。
2.1 DigestAlgorithmIdentifier
2.1 DigestAlgorithmIdentifier
Sending and receiving agents MUST support SHA-1 [SHA1]. Receiving agents SHOULD support MD5 [MD5] for the purpose of providing backward compatibility with MD5-digested S/MIME v2 SignedData objects.
送受信エージェントはSHA-1[SHA1]をサポートしなければなりません。 MD5によって読みこなされたS/MIME v2 SignedDataオブジェクトを後方の互換性に提供する目的のために、エージェントSHOULDサポートMD5[MD5]を受けます。
Ramsdell Standards Track [Page 3] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[3ページ]。
2.2 SignatureAlgorithmIdentifier
2.2 SignatureAlgorithmIdentifier
Sending and receiving agents MUST support id-dsa defined in [DSS]. The algorithm parameters MUST be absent (not encoded as NULL).
送受信エージェントは[DSS]で定義されたイド-dsaをサポートしなければなりません。 アルゴリズムパラメタは欠けているに違いありません(NULLとして、コード化されません)。
Receiving agents SHOULD support rsaEncryption, defined in [PKCS-1].
[PKCS-1]で定義されたエージェントSHOULDサポートrsaEncryptionを受けます。
Sending agents SHOULD support rsaEncryption. Outgoing messages are signed with a user's private key. The size of the private key is determined during key generation.
送付エージェントSHOULDはrsaEncryptionをサポートします。 送信されるメッセージはユーザの秘密鍵を契約されます。 秘密鍵のサイズはキー生成の間、決定しています。
Note that S/MIME v2 clients are only capable of verifying digital signatures using the rsaEncryption algorithm.
S/MIME v2クライアントがrsaEncryptionアルゴリズムを使用することでデジタル署名について確かめることができるだけであることに注意してください。
2.3 KeyEncryptionAlgorithmIdentifier
2.3 KeyEncryptionAlgorithmIdentifier
Sending and receiving agents MUST support Diffie-Hellman defined in [DH].
送受信エージェントは[DH]で定義されていた状態でディフィー-ヘルマンをサポートしなければなりません。
Receiving agents SHOULD support rsaEncryption. Incoming encrypted messages contain symmetric keys which are to be decrypted with a user's private key. The size of the private key is determined during key generation.
エージェントSHOULDサポートrsaEncryptionを受けます。 入って来る暗号化メッセージはユーザの秘密鍵で解読されることになっている対称鍵を含んでいます。 秘密鍵のサイズはキー生成の間、決定しています。
Sending agents SHOULD support rsaEncryption.
送付エージェントSHOULDはrsaEncryptionをサポートします。
Note that S/MIME v2 clients are only capable of decrypting content encryption keys using the rsaEncryption algorithm.
S/MIME v2クライアントがrsaEncryptionアルゴリズムを使用することで満足している暗号化キーを解読することができるだけであることに注意してください。
2.4 General Syntax
2.4の一般構文
CMS defines multiple content types. Of these, only the Data, SignedData, and EnvelopedData content types are currently used for S/MIME.
CMSは複数のcontent typeを定義します。 これらでは、Data、SignedData、およびEnvelopedData content typeだけが現在、S/MIMEに使用されます。
2.4.1 Data Content Type
2.4.1 データcontent type
Sending agents MUST use the id-data content type identifier to indicate the message content which has had security services applied to it. For example, when applying a digital signature to MIME data, the CMS signedData encapContentInfo eContentType MUST include the id-data object identifier and the MIME content MUST be stored in the SignedData encapContentInfo eContent OCTET STRING (unless the sending agent is using multipart/signed, in which case the eContent is absent, per section 3.4.3 of this document). As another example, when applying encryption to MIME data, the CMS EnvelopedData
送付エージェントは、セキュリティー・サービスをそれに適用したメッセージ内容を示すのにイドデータcontent type識別子を使用しなければなりません。 MIMEデータにデジタル署名を適用するとき、例えば、CMS signedData encapContentInfo eContentTypeはイドデータ・オブジェクト識別子を含まなければなりません、そして、SignedData encapContentInfo eContent OCTET STRINGにMIME内容を保存しなければなりません(その場合、送付エージェントが複合か署名された状態で使用していない場合、eContentは欠けています、この.3通のセクション3.4ドキュメント単位で)。 別の例、MIMEデータ、CMS EnvelopedDataに暗号化を適用します。
Ramsdell Standards Track [Page 4] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[4ページ]。
encryptedContentInfo ContentType MUST include the id-data object identifier and the encrypted MIME content MUST be stored in the envelopedData encryptedContentInfo encryptedContent OCTET STRING.
encryptedContentInfo ContentTypeはイドデータ・オブジェクト識別子を含まなければなりません、そして、envelopedData encryptedContentInfo encryptedContent OCTET STRINGに暗号化されたMIME内容を保存しなければなりません。
2.4.2 SignedData Content Type
2.4.2 SignedData content type
Sending agents MUST use the signedData content type to apply a digital signature to a message or, in a degenerate case where there is no signature information, to convey certificates.
送付エージェントがデジタル署名をメッセージに適用するのにsignedData content typeを使用しなければならない、堕落した場合では、さもなければ、そこのどこが、証明書を伝えるためには署名情報でないか。
2.4.3 EnvelopedData Content Type
2.4.3 EnvelopedData content type
This content type is used to apply privacy protection to a message. A sender needs to have access to a public key for each intended message recipient to use this service. This content type does not provide authentication.
このcontent typeは、プライバシー保護をメッセージに適用するのに使用されます。 送付者は、それぞれの意図しているメッセージ受取人がこのサービスを利用するように公開鍵に近づく手段を持つ必要があります。 このcontent typeは認証を提供しません。
2.5 Attribute SignerInfo Type
2.5 属性SignerInfoはタイプします。
The SignerInfo type allows the inclusion of unsigned and signed attributes to be included along with a signature.
SignerInfoタイプは署名と共に未署名の、そして、署名している属性の包含を含めさせます。
Receiving agents MUST be able to handle zero or one instance of each of the signed attributes listed here. Sending agents SHOULD generate one instance of each of the following signed attributes in each S/MIME message:
エージェントを受けると、ここに記載されたそれぞれの署名している属性のゼロか1つのインスタンスを扱うことができなければなりません。 送付エージェントSHOULDはそれぞれのS/MIMEメッセージの属性であると署名されるそれぞれの以下の1つのインスタンスを生成します:
- signingTime (section 2.5.1 in this document) - sMIMECapabilities (section 2.5.2 in this document) - sMIMEEncryptionKeyPreference (section 2.5.3 in this document)
- signingTime(このドキュメントのセクション2.5.1)--sMIMECapabilities(このドキュメントのセクション2.5.2)--sMIMEEncryptionKeyPreference(このドキュメントのセクション2.5.3)
Further, receiving agents SHOULD be able to handle zero or one instance in the signed attributes of the signingCertificate attribute (section 5 in [ESS]).
エージェントSHOULDを受けて、さらに、signingCertificate属性([ESS]のセクション5)の署名している属性におけるゼロか1つのインスタンスを扱うことができてください。
Sending agents SHOULD generate one instance of the signingCertificate signed attribute in each S/MIME message.
送付エージェントSHOULDはそれぞれのS/MIMEメッセージの属性であると署名されるsigningCertificateの1つのインスタンスを生成します。
Additional attributes and values for these attributes may be defined in the future. Receiving agents SHOULD handle attributes or values that it does not recognize in a graceful manner.
これらの属性のための追加属性と値は将来、定義されるかもしれません。 受信エージェントSHOULDはそれが優しい物腰で認識しない属性か値を扱います。
Sending agents that include signed attributes that are not listed here SHOULD display those attributes to the user, so that the user is aware of all of the data being signed.
ここに記載されていない署名している属性を含んでいるエージェントを送って、SHOULDはそれらの属性をユーザに表示します、ユーザが署名されるデータのすべてを意識しているように。
Ramsdell Standards Track [Page 5] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[5ページ]。
2.5.1 Signing-Time Attribute
2.5.1 署名時間属性
The signing-time attribute is used to convey the time that a message was signed. Until there are trusted timestamping services, the time of signing will most likely be created by a message originator and therefore is only as trustworthy as the originator.
署名時間属性は、メッセージが署名された時間を伝えるのに使用されます。 timestampingサービスが信じられるまで、署名の時間は、たぶんメッセージ創始者によって作成されて、したがって、単に創始者と同じくらい信頼できます。
Sending agents MUST encode signing time through the year 2049 as UTCTime; signing times in 2050 or later MUST be encoded as GeneralizedTime. When the UTCTime CHOICE is used, S/MIME agents MUST interpret the year field (YY) as follows:
送付エージェントはUTCTimeとして署名時間から2049年をコード化しなければなりません。 GeneralizedTimeとして2050か後で回に署名するのをコード化しなければなりません。 UTCTime CHOICEが使用されているとき、S/MIMEエージェントは以下の1年の分野(YY)を解釈しなければなりません:
if YY is greater than or equal to 50, the year is interpreted as 19YY; if YY is less than 50, the year is interpreted as 20YY.
YYが50歳以上であるなら、1年は19YYとして解釈されます。 YYが50歳未満であるなら、1年は20YYとして解釈されます。
2.5.2 SMIMECapabilities Attribute
2.5.2 SMIMECapabilities属性
The SMIMECapabilities attribute includes signature algorithms (such as "sha1WithRSAEncryption"), symmetric algorithms (such as "DES- EDE3-CBC"), and key encipherment algorithms (such as "rsaEncryption"). It also includes a non-algorithm capability which is the preference for signedData. The SMIMECapabilities were designed to be flexible and extensible so that, in the future, a means of identifying other capabilities and preferences such as certificates can be added in a way that will not cause current clients to break.
SMIMECapabilities属性は署名アルゴリズム("sha1WithRSAEncryption"などの)、左右対称のアルゴリズム(「デスEDE3-CBC」などの)、および主要な暗号文アルゴリズム("rsaEncryption"などの)を含んでいます。 また、それはsignedDataのための好みである非アルゴリズム能力を含んでいます。 将来現在のクライアントが中断していない方法で証明書などの他の能力と好みを特定する手段を加えることができて、SMIMECapabilitiesは、フレキシブルであって、広げることができるように設計されました。
If present, the SMIMECapabilities attribute MUST be a SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines SignedAttributes as a SET OF Attribute. The SignedAttributes in a signerInfo MUST NOT include multiple instances of the SMIMECapabilities attribute. CMS defines the ASN.1 syntax for Attribute to include attrValues SET OF AttributeValue. A SMIMECapabilities attribute MUST only include a single instance of AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue present in the attrValues SET OF AttributeValue.
存在しているなら、SMIMECapabilities属性はSignedAttributeであるに違いありません。 それはUnsignedAttributeであるはずがありません。 CMSはSignedAttributesをSET OF Attributeと定義します。 signerInfoのSignedAttributesはSMIMECapabilities属性の複数のインスタンスを含んではいけません。 AttributeがattrValues SET OF AttributeValueを含むように、CMSはASN.1構文を定義します。 SMIMECapabilities属性はAttributeValueのただ一つのインスタンスを含むだけでよいです。 attrValues SET OF AttributeValueの現在のAttributeValueのゼロか複数のインスタンスがあるはずがありません。
The semantics of the SMIMECapabilites attribute specify a partial list as to what the client announcing the SMIMECapabilites can support. A client does not have to list every capability it supports, and probably should not list all its capabilities so that the capabilities list doesn't get too long. In an SMIMECapabilities attribute, the OIDs are listed in order of their preference, but SHOULD be logically separated along the lines of their categories (signature algorithms, symmetric algorithms, key encipherment algorithms, etc.)
SMIMECapabilitesを発表するクライアントが何にサポートすることができるかとSMIMECapabilites属性の意味論は部分的なリストを指定します。 クライアントがそれがサポートするあらゆる能力を記載する必要はなくて、たぶんすべての能力を記載するべきであるというわけではないので、能力リストは長くなり過ぎません。 SMIMECapabilities属性では、OIDsは彼らの好みの順に記載されていますが、それらのカテゴリの系列に沿って切り離されて、SHOULDは論理的に記載されています。(署名アルゴリズム、左右対称のアルゴリズム、主要な暗号文アルゴリズムなど)
Ramsdell Standards Track [Page 6] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[6ページ]。
The structure of the SMIMECapabilities attribute is to facilitate simple table lookups and binary comparisons in order to determine matches. For instance, the DER-encoding for the SMIMECapability for DES EDE3 CBC MUST be identically encoded regardless of the implementation.
SMIMECapabilities属性の構造はマッチを決定するために簡単な索表と2進の比較を容易にすることです。 例えば、実装にかかわらずコード化されて、DES EDE3 CBC MUSTのためのSMIMECapabilityのためのDER-コード化は同様にそうです。
In the case of symmetric algorithms, the associated parameters for the OID MUST specify all of the parameters necessary to differentiate between two instances of the same algorithm. For instance, the number of rounds and block size for RC5 must be specified in addition to the key length.
左右対称のアルゴリズムの場合では、OID MUSTのための関連パラメタは同じアルゴリズムの2つのインスタンスを区別するのに必要なパラメタのすべてを指定します。 例えば、キー長に加えてRC5のためのラウンドとブロック・サイズの数を指定しなければなりません。
There is a list of OIDs (OIDs Used with S/MIME) that is centrally maintained and is separate from this memo. The list of OIDs is maintained by the Internet Mail Consortium at <http://www.imc.org/ietf-smime/oids.html>. Note that all OIDs associated with the MUST and SHOULD implement algorithms are included in section A of this document.
中心で維持された、このメモから別々のOIDs(S/MIMEがあるOIDs Used)のリストがあります。 OIDsのリストは<http://www.imc.org/ietf-smime/oids.html>でインターネットメールConsortiumによって維持されます。 そして、すべてのOIDsが交際した注意、このドキュメントのセクションAにSHOULD道具アルゴリズムを含まなければなりません。
The OIDs that correspond to algorithms SHOULD use the same OID as the actual algorithm, except in the case where the algorithm usage is ambiguous from the OID. For instance, in an earlier draft, rsaEncryption was ambiguous because it could refer to either a signature algorithm or a key encipherment algorithm. In the event that an OID is ambiguous, it needs to be arbitrated by the maintainer of the registered SMIMECapabilities list as to which type of algorithm will use the OID, and a new OID MUST be allocated under the smimeCapabilities OID to satisfy the other use of the OID.
アルゴリズムSHOULDに対応するOIDsは実際のアルゴリズムと同じOIDを使用します、ケースを除いて中アルゴリズム用法がOIDからあいまいである。 例えば、以前の草稿では、署名アルゴリズムか主要な暗号文アルゴリズムのどちらかを示すかもしれないので、rsaEncryptionはあいまいでした。 OIDがあいまいである場合、それは、OIDのもう片方の使用を満たすためにsmimeCapabilities OIDの下にどのタイプのアルゴリズムがOID、および新しいOID MUSTを使用するために望んでいるかに割り当てるように登録されたSMIMECapabilitiesリストの維持装置によって仲裁される必要があります。
The registered SMIMECapabilities list specifies the parameters for OIDs that need them, most notably key lengths in the case of variable-length symmetric ciphers. In the event that there are no differentiating parameters for a particular OID, the parameters MUST be omitted, and MUST NOT be encoded as NULL.
登録されたSMIMECapabilitiesリストは彼ら(著しく可変長の左右対称の暗号の場合におけるほとんどのキー長)を必要とするOIDsのためのパラメタを指定します。 差別化パラメタが全く特定のOIDのためにない場合、パラメタは、省略しなければならなくて、NULLとしてコード化されてはいけません。
Additional values for the SMIMECapabilities attribute may be defined in the future. Receiving agents MUST handle a SMIMECapabilities object that has values that it does not recognize in a graceful manner.
SMIMECapabilities属性のための加算値は将来、定義されるかもしれません。 エージェントを受けると、それが優しい物腰で認識しない値を持っているSMIMECapabilitiesオブジェクトは扱われなければなりません。
2.5.3 Encryption Key Preference Attribute
2.5.3 暗号化の主要な好みの属性
The encryption key preference attribute allows the signer to unambiguously describe which of the signer's certificates has the signer's preferred encryption key. This attribute is designed to enhance behavior for interoperating with those clients which use separate keys for encryption and signing. This attribute is used to
署名者の証明書について署名者の都合のよい暗号化キーを持っている署名者が主要な好みの属性で明白に説明できる暗号化。 この属性は、それの使用が暗号化のためのキーを切り離すそれらのクライアントと共に共同利用するための振舞いを機能アップするように設計されていて、署名しています。 この属性は使用されています。
Ramsdell Standards Track [Page 7] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[7ページ]。
convey to anyone viewing the attribute which of the listed certificates should be used for encrypting a session key for future encrypted messages.
将来の暗号化メッセージに、主要なセッションを暗号化するのに記載された証明書について使用されるべきである属性を見ている人はだれにも伝えてください。
If present, the SMIMEEncryptionKeyPreference attribute MUST be a SignedAttribute; it MUST NOT be an UnsignedAttribute. CMS defines SignedAttributes as a SET OF Attribute. The SignedAttributes in a signerInfo MUST NOT include multiple instances of the SMIMEEncryptionKeyPreference attribute. CMS defines the ASN.1 syntax for Attribute to include attrValues SET OF AttributeValue. A SMIMEEncryptionKeyPreference attribute MUST only include a single instance of AttributeValue. There MUST NOT be zero or multiple instances of AttributeValue present in the attrValues SET OF AttributeValue.
存在しているなら、SMIMEEncryptionKeyPreference属性はSignedAttributeであるに違いありません。 それはUnsignedAttributeであるはずがありません。 CMSはSignedAttributesをSET OF Attributeと定義します。 signerInfoのSignedAttributesはSMIMEEncryptionKeyPreference属性の複数のインスタンスを含んではいけません。 AttributeがattrValues SET OF AttributeValueを含むように、CMSはASN.1構文を定義します。 SMIMEEncryptionKeyPreference属性はAttributeValueのただ一つのインスタンスを含むだけでよいです。 attrValues SET OF AttributeValueの現在のAttributeValueのゼロか複数のインスタンスがあるはずがありません。
The sending agent SHOULD include the referenced certificate in the set of certificates included in the signed message if this attribute is used. The certificate may be omitted if it has been previously made available to the receiving agent. Sending agents SHOULD use this attribute if the commonly used or preferred encryption certificate is not the same as the certificate used to sign the message.
送付エージェントSHOULDは、この属性が使用されているなら署名しているメッセージに証明書のセットにおける参照をつけられた証明書を含んでいるのを含んでいます。 以前にそれを受信エージェントにとって利用可能にしたなら、証明書を省略するかもしれません。 一般的に使用されたか都合のよい暗号化証明書が証明書が以前はよくメッセージに署名していたのと同じでないなら、送付エージェントSHOULDはこの属性を使用します。
Receiving agents SHOULD store the preference data if the signature on the message is valid and the signing time is greater than the currently stored value. (As with the SMIMECapabilities, the clock skew should be checked and the data not used if the skew is too great.) Receiving agents SHOULD respect the sender's encryption key preference attribute if possible. This however represents only a preference and the receiving agent may use any certificate in replying to the sender that is valid.
メッセージにおける署名が有効であり、署名時間が現在保存された値より大きいなら、受信エージェントSHOULDは好みのデータを保存します。 (SMIMECapabilitiesに、時計斜行が問い合わせられるべきであり、斜行であるなら使用されないデータがすばらし過ぎるときに。) できれば、受信エージェントSHOULDは送付者の暗号化の主要な好みの属性を尊敬します。 しかしながら、これは優先だけを表します、そして、受信エージェントは有効な送付者に答える際にどんな証明書も使用するかもしれません。
2.5.3.1 Selection of Recipient Key Management Certificate
2.5.3.1 受取人Key Management証明書の選択
In order to determine the key management certificate to be used when sending a future CMS envelopedData message for a particular recipient, the following steps SHOULD be followed:
以下は、特定の受取人のために将来のCMS envelopedDataメッセージを送るとき、かぎ管理証明書が使用されることを決定するためにSHOULDを踏みます。続かれてください:
- If an SMIMEEncryptionKeyPreference attribute is found in a
signedData object received from the desired recipient, this
identifies the X.509 certificate that should be used as the X.509
key management certificate for the recipient.
- SMIMEEncryptionKeyPreference属性が必要な受取人から受け取られたsignedDataオブジェクトで見つけられるなら、これは受取人にX.509かぎ管理証明書として使用されるべきであるX.509証明書を特定します。
- If an SMIMEEncryptionKeyPreference attribute is not found in a signedData object received from the desired recipient, the set of X.509 certificates should be searched for a X.509 certificate with the same subject name as the signing X.509 certificate which can be used for key management.
- SMIMEEncryptionKeyPreference属性が必要な受取人から受け取られたsignedDataオブジェクトで見つけられないなら、X.509証明書のセットはかぎ管理に使用できる署名X.509証明書と同じ対象の名前でX.509証明書を捜されるべきです。
Ramsdell Standards Track [Page 8] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[8ページ]。
- Or use some other method of determining the user's key management key. If a X.509 key management certificate is not found, then encryption cannot be done with the signer of the message. If multiple X.509 key management certificates are found, the S/MIME agent can make an arbitrary choice between them.
- または、ユーザのかぎ管理キーを決定するある他のメソッドを使用してください。 X.509かぎ管理証明書を見つけないなら、メッセージの署名者で暗号化ができません。 複数のX.509かぎ管理証明書が見つけられるなら、S/MIMEエージェントはそれらの気紛れな選択をすることができます。
2.6 SignerIdentifier SignerInfo Type
2.6 SignerIdentifier SignerInfoはタイプします。
S/MIME v3 requires the use of SignerInfo version 1, that is the issuerAndSerialNumber CHOICE MUST be used for SignerIdentifier.
S/MIME v3はSignerInfoバージョン1の使用を必要とします、すなわち、SignerIdentifierにissuerAndSerialNumber CHOICEを使用しなければなりません。
2.7 ContentEncryptionAlgorithmIdentifier
2.7 ContentEncryptionAlgorithmIdentifier
Sending and receiving agents MUST support encryption and decryption with DES EDE3 CBC, hereinafter called "tripleDES" [3DES] [DES]. Receiving agents SHOULD support encryption and decryption using the RC2 [RC2] or a compatible algorithm at a key size of 40 bits, hereinafter called "RC2/40".
「tripleDES」[3DES][DES]は、以下に、送受信エージェントがDES EDE3 CBCと共に暗号化と復号化をサポートしなければならないと呼びました。 受信エージェントSHOULDは、40ビットと、以下に呼ばれた「RC2/40インチ」の主要なサイズで暗号化と復号化使用がRC2[RC2]かコンパチブルアルゴリズムであるとサポートします。
2.7.1 Deciding Which Encryption Method To Use
2.7.1 どの暗号化メソッドを使用したらよいかを決めること。
When a sending agent creates an encrypted message, it has to decide which type of encryption to use. The decision process involves using information garnered from the capabilities lists included in messages received from the recipient, as well as out-of-band information such as private agreements, user preferences, legal restrictions, and so on.
送付エージェントが暗号化メッセージを作成するとき、それは、どのタイプの暗号化を使用するかを決めなければなりません。 プロセスが、能力リストから集められる情報を使用することを伴うという決定は受取人から受け取られたメッセージと、バンドの外に個人的な協定、ユーザー選択、法的規制などなどの情報を含んでいました。
Section 2.5 defines a method by which a sending agent can optionally announce, among other things, its decrypting capabilities in its order of preference. The following method for processing and remembering the encryption capabilities attribute in incoming signed messages SHOULD be used.
セクション2.5はよく使われる順で送付エージェントが能力を特に解読すると任意に発表できるメソッドを定義します。 メッセージSHOULDであると署名される入来における暗号化能力属性が使用されたのを処理して、覚えているための以下のメソッド。
- If the receiving agent has not yet created a list of capabilities
for the sender's public key, then, after verifying the signature
on the incoming message and checking the timestamp, the receiving
agent SHOULD create a new list containing at least the signing
time and the symmetric capabilities.
- 受信エージェントが送付者の公開鍵のためにまだ能力のリストを作成していないなら、入力メッセージで署名について確かめて、タイムスタンプをチェックした後に、受信エージェントSHOULDは少なくとも署名時間と左右対称の能力を含む新しいリストを作成します。
- If such a list already exists, the receiving agent SHOULD verify
that the signing time in the incoming message is greater than
the signing time stored in the list and that the signature is
valid. If so, the receiving agent SHOULD update both the signing
time and capabilities in the list. Values of the signing time that
lie far in the future (that is, a greater discrepancy than any
reasonable clock skew), or a capabilities list in messages whose
signature could not be verified, MUST NOT be accepted.
- そのようなリストが既に存在しているなら、受信エージェントSHOULDは入力メッセージの署名時間がリストに保存された署名時間より長く、署名が有効であることを確かめます。 そうだとすれば、受信エージェントSHOULDは署名時間とリストの能力の両方をアップデートします。 遠くに未来(すなわち、どんな合理的な時計斜行よりも重大な食い違い)に、ある署名現代の値、またはメッセージの署名について確かめることができなかった能力リストを受け入れてはいけません。
Ramsdell Standards Track [Page 9] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[9ページ]。
The list of capabilities SHOULD be stored for future use in creating messages.
能力SHOULDについて記載してください。メッセージを作成することにおける未来の使用には、保存されてください。
Before sending a message, the sending agent MUST decide whether it is willing to use weak encryption for the particular data in the message. If the sending agent decides that weak encryption is unacceptable for this data, then the sending agent MUST NOT use a weak algorithm such as RC2/40. The decision to use or not use weak encryption overrides any other decision in this section about which encryption algorithm to use.
メッセージを送る前に、送付エージェントは、それが、メッセージの特定のデータに弱い暗号化を使用しても構わないと思っているかどうか決めなければなりません。 送付エージェントが、このデータに、弱い暗号化が容認できないと決めるなら、送付エージェントはRC2/40などの弱いアルゴリズムを使用してはいけません。 弱い暗号化が使用するためにどの暗号化アルゴリズムに関してこのセクションでのいかなる他の決定もくつがえす使用ではなく、使用する決定。
Sections 2.7.2.1 through 2.7.2.4 describe the decisions a sending agent SHOULD use in deciding which type of encryption should be applied to a message. These rules are ordered, so the sending agent SHOULD make its decision in the order given.
セクション2.7 .2 .1〜2.7に、.4が暗号化のどのタイプについて決めるかながら送付エージェントSHOULDが使用する決定について説明する.2はメッセージに適用されるべきです。 これらの規則が注文されるので、送付エージェントSHOULDはオーダーにおける決定を与えさせます。
2.7.1.1 Rule 1: Known Capabilities
2.7.1.1 規則1: 知られている能力
If the sending agent has received a set of capabilities from the recipient for the message the agent is about to encrypt, then the sending agent SHOULD use that information by selecting the first capability in the list (that is, the capability most preferred by the intended recipient) for which the sending agent knows how to encrypt. The sending agent SHOULD use one of the capabilities in the list if the agent reasonably expects the recipient to be able to decrypt the message.
送付エージェントがエージェントが暗号化しようとしているメッセージのために受取人から1セットの能力を受けたなら、そして、SHOULDが暗号化するのに送付エージェントがその方法を知っているリスト(すなわち、意図している受取人によって最も好まれた能力)における最初の能力を選択することによってその情報を使用する送付エージェントです。 エージェントが、受取人がメッセージを解読することができると合理的に予想するなら、送付エージェントSHOULDはリストで能力の1つを使用します。
2.7.1.2 Rule 2: Unknown Capabilities, Known Use of Encryption
2.7.1.2 規則2: 未知の能力、暗号化の知られている使用
If:
- the sending agent has no knowledge of the encryption capabilities
of the recipient,
- and the sending agent has received at least one message from the
recipient,
- and the last encrypted message received from the recipient had a
trusted signature on it,
: - 送付エージェントには、受取人の暗号化能力に関する知識が全くありません、そして、(そして、送付エージェントは受取人から少なくとも1つのメッセージを受け取りました)受取人から受け取られた最後に暗号化されたメッセージはそれに信じられた署名を持っていました。
then the outgoing message SHOULD use the same encryption algorithm as was used on the last signed and encrypted message received from the recipient.
そして、SHOULDが同じ暗号化アルゴリズムを使用する送信されるメッセージは受取人から受け取られた最後に署名していて暗号化されたメッセージで使用されました。
Ramsdell Standards Track [Page 10] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[10ページ]。
2.7.1.3 Rule 3: Unknown Capabilities, Unknown Version of S/MIME
2.7.1.3 規則3: 未知の能力、S/MIMEの未知のバージョン
If:
:
- the sending agent has no knowledge of the encryption capabilities
of the recipient,
- and the sending agent has no knowledge of the version of S/MIME
of the recipient,
- 送付エージェントには、受取人の暗号化能力に関する知識が全くありません、そして、送付エージェントには、受取人のS/MIMEのバージョンに関する知識が全くありません。
then the sending agent SHOULD use tripleDES because it is a stronger algorithm and is required by S/MIME v3. If the sending agent chooses not to use tripleDES in this step, it SHOULD use RC2/40.
そして、それが、より強いアルゴリズムであり、S/MIME v3によって必要とされるので、送付エージェントSHOULDはtripleDESを使用します。 送付エージェントが、中でtripleDESを使用しないのを選ぶなら、これは踏まれて、それはSHOULD使用です。RC2/40。
2.7.2 Choosing Weak Encryption
2.7.2 弱い暗号化を選ぶこと。
Like all algorithms that use 40 bit keys, RC2/40 is considered by many to be weak encryption. A sending agent that is controlled by a human SHOULD allow a human sender to determine the risks of sending data using RC2/40 or a similarly weak encryption algorithm before sending the data, and possibly allow the human to use a stronger encryption method such as tripleDES.
40ビットのキーを使用するすべてのアルゴリズムのように、RC2/40は多くによって弱い暗号化であると考えられます。 SHOULDがデータを送る前にRC2/40を使用することでデータを送る危険か同様に弱い暗号化アルゴリズムを決定して、ことによると人間がtripleDESなどの、より強い暗号化メソッドを使用するのを許容するのを人間の送付者を許容する人間によって監督される送付エージェント。
2.7.3 Multiple Recipients
2.7.3 複数の受取人
If a sending agent is composing an encrypted message to a group of recipients where the encryption capabilities of some of the recipients do not overlap, the sending agent is forced to send more than one message. It should be noted that if the sending agent chooses to send a message encrypted with a strong algorithm, and then send the same message encrypted with a weak algorithm, someone watching the communications channel may be able to learn the contents of the strongly-encrypted message simply by decrypting the weakly- encrypted message.
送付エージェントが何人かの受取人の暗号化能力が重ならない受取人のグループに暗号化メッセージを構成しているなら、送付エージェントはやむを得ず1つ以上のメッセージを送ります。 送付エージェントが強いアルゴリズムで暗号化されたメッセージを送って、次に、弱いアルゴリズムで暗号化された同じメッセージを送るのを選ぶなら、コミュニケーションチャンネルを監視しているだれかが単に弱さに暗号化メッセージを解読することによって強く暗号化されたメッセージのコンテンツを学ぶことができるかもしれないことに注意されるべきです。
3. Creating S/MIME Messages
3. S/MIMEメッセージを作成します。
This section describes the S/MIME message formats and how they are created. S/MIME messages are a combination of MIME bodies and CMS objects. Several MIME types as well as several CMS objects are used. The data to be secured is always a canonical MIME entity. The MIME entity and other data, such as certificates and algorithm identifiers, are given to CMS processing facilities which produces a CMS object. The CMS object is then finally wrapped in MIME. The Enhanced Security Services for S/MIME [ESS] document provides examples of how nested, secured S/MIME messages are formatted. ESS provides an example of how a triple-wrapped S/MIME message is formatted using multipart/signed and application/pkcs7-mime for the signatures.
このセクションはS/MIMEメッセージ・フォーマットとそれらがどう作成されるかを説明します。 S/MIMEメッセージはMIME本体とCMSオブジェクトの組み合わせです。 数個のCMSオブジェクトと同様にいくつかのMIMEの種類が使用されています。 いつも保証されるデータは正準なMIME実体です。 証明書やアルゴリズム識別子などのMIME実体と他のデータをCMS処理施設に与えます(CMSオブジェクトを作り出します)。 そして、CMSオブジェクトはMIMEで最終的に包装されます。 [ESS]が記録するS/MIMEのためのEnhanced Security Servicesは入れ子にされて、機密保護しているS/MIMEメッセージがどうフォーマットされるかに関する例を提供します。 ESSは3倍包装されたS/MIMEメッセージが署名に署名される複合/とpkcs7アプリケーション/パントマイムを使用することでどうフォーマットされるかに関する例を提供します。
Ramsdell Standards Track [Page 11] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[11ページ]。
S/MIME provides one format for enveloped-only data, several formats for signed-only data, and several formats for signed and enveloped data. Several formats are required to accommodate several environments, in particular for signed messages. The criteria for choosing among these formats are also described.
S/MIMEはおおわれて唯一のデータのための1つの形式、署名されて唯一のデータのためのいくつかの形式、および署名していておおわれたデータのためのいくつかの形式を提供します。 いくつかの形式が、いくつかの環境を収容するのに特に署名しているメッセージに必要です。 また、これらの形式の中で選ぶ評価基準は説明されます。
The reader of this section is expected to understand MIME as described in [MIME-SPEC] and [MIME-SECURE].
このセクションの読者が[MIME-SPEC]と[MIME-SECURE]で説明されるようにMIMEを理解していると予想されます。
3.1 Preparing the MIME Entity for Signing or Enveloping
3.1 署名のためにMIME実体を準備するか、おおうこと
S/MIME is used to secure MIME entities. A MIME entity may be a sub- part, sub-parts of a message, or the whole message with all its sub- parts. A MIME entity that is the whole message includes only the MIME headers and MIME body, and does not include the RFC-822 headers. Note that S/MIME can also be used to secure MIME entities used in applications other than Internet mail.
S/MIMEは、MIMEが実体であると機密保護するのに使用されます。 MIME実体は、サブ部分、メッセージのサブ部分、またはすべてのサブの部品がある全体のメッセージであるかもしれません。 全体のメッセージであるMIME実体は、MIMEヘッダーとMIME本体だけを含んでいて、RFC-822ヘッダーは含んでいません。 また、MIMEがインターネット・メール以外のアプリケーションで使用される実体であると機密保護するのにS/MIMEを使用できることに注意してください。
The MIME entity that is secured and described in this section can be thought of as the "inside" MIME entity. That is, it is the "innermost" object in what is possibly a larger MIME message. Processing "outside" MIME entities into CMS objects is described in Section 3.2, 3.4 and elsewhere.
“inside"MIME実体としてこのセクションで保証されて、説明されるMIME実体は考えることができます。 すなわち、それはことによるとより大きいMIMEメッセージであることで「最も奥深い」オブジェクトです。 CMSオブジェクトへのMIME実体を処理するのはセクション3.2、3.4とほかの場所に「外に」に説明されます。
The procedure for preparing a MIME entity is given in [MIME-SPEC]. The same procedure is used here with some additional restrictions when signing. Description of the procedures from [MIME-SPEC] are repeated here, but the reader should refer to that document for the exact procedure. This section also describes additional requirements.
MIME実体が[MIME-SPEC]で与えられている準備のための手順。 署名するとき、同じ手順はいくつかの追加制限と共にここで用いられます。 [MIME-SPEC]からの手順の記述はここで繰り返されますが、読者は正確な手順のためのそのドキュメントを参照するべきです。 また、このセクションは追加要件について説明します。
A single procedure is used for creating MIME entities that are to be signed, enveloped, or both signed and enveloped. Some additional steps are recommended to defend against known corruptions that can occur during mail transport that are of particular importance for clear- signing using the multipart/signed format. It is recommended that these additional steps be performed on enveloped messages, or signed and enveloped messages in order that the message can be forwarded to any environment without modification.
ただ一つの手順は、署名されることになっているか、おおわれることになっているか、署名されて、またはおおわれることになっているMIME実体を作成するのに用いられます。 追加数ステップが明確な署名のために特別に重要なメール輸送の間に複合の、または、署名している形式を使用することで起こることができる知られている贈収賄に対して防御することが勧められます。 これらの追加ステップがおおわれたメッセージ、または署名していておおわれたメッセージに実行されるのは、変更なしでどんな環境にもメッセージを転送できるようにお勧めです。
These steps are descriptive rather than prescriptive. The implementor is free to use any procedure as long as the result is the same.
規範的であるというよりむしろこれらのステップは描写的です。 結果が同じである限り、作成者は自由にどんな手順も用いることができます。
Step 1. The MIME entity is prepared according to the local conventions
1を踏んでください。 地方のコンベンションによると、MIME実体は準備されます。
Step 2. The leaf parts of the MIME entity are converted to canonical form
2を踏んでください。 MIME実体の葉の部品は標準形に変換されます。
Ramsdell Standards Track [Page 12] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[12ページ]。
Step 3. Appropriate transfer encoding is applied to the leaves of the MIME entity
3を踏んでください。 適切な転送コード化はMIME実体の葉に当てられます。
When an S/MIME message is received, the security services on the message are processed, and the result is the MIME entity. That MIME entity is typically passed to a MIME-capable user agent where, it is further decoded and presented to the user or receiving application.
S/MIMEメッセージが受信されているとき、メッセージにおけるセキュリティー・サービスは処理されます、そして、結果はMIME実体です。 MIME有能なユーザエージェントに渡されて、そのMIME実体は通常、そうです。どこ、それはさらに解読されて、ユーザに提示されるか、またはアプリケーションを受け取っているか。
3.1.1 Canonicalization
3.1.1 Canonicalization
Each MIME entity MUST be converted to a canonical form that is uniquely and unambiguously representable in the environment where the signature is created and the environment where the signature will be verified. MIME entities MUST be canonicalized for enveloping as well as signing.
署名が確かめられるところで署名が作成される環境と環境で唯一と明白に「表-可能」な標準形にそれぞれのMIME実体を変換しなければなりません。 署名と同様におおうためにMIME実体をcanonicalizedしなければなりません。
The exact details of canonicalization depend on the actual MIME type and subtype of an entity, and are not described here. Instead, the standard for the particular MIME type should be consulted. For example, canonicalization of type text/plain is different from canonicalization of audio/basic. Other than text types, most types have only one representation regardless of computing platform or environment which can be considered their canonical representation. In general, canonicalization will be performed by the non-security part of the sending agent rather than the S/MIME implementation.
canonicalizationの正確な細部は、実体の実際のMIMEの種類と「副-タイプ」によって、ここで説明されません。 代わりに、特定のMIMEの種類の規格は相談されるべきです。 例えば、タイプテキスト/平野のcanonicalizationはオーディオ的か基本的のcanonicalizationと異なっています。 テキストタイプ以外に、ほとんどのタイプには、彼らの正準な表現であると考えることができるコンピューティングプラットホームか環境にかかわらず1つの表現しかありません。 一般に、canonicalizationはS/MIME実装よりむしろ送付エージェントの非セキュリティ部分によって実行されるでしょう。
The most common and important canonicalization is for text, which is often represented differently in different environments. MIME entities of major type "text" must have both their line endings and character set canonicalized. The line ending must be the pair of characters <CR><LF>, and the charset should be a registered charset [CHARSETS]. The details of the canonicalization are specified in [MIME-SPEC]. The chosen charset SHOULD be named in the charset parameter so that the receiving agent can unambiguously determine the charset used.
最も一般的で重要なcanonicalizationはテキストのためのものです。(それは、しばしば異なった環境で異なって表されます)。 主要なタイプ「テキスト」のMIME実体で、それらの系列結末と文字集合の両方をcanonicalizedしなければなりません。 系列結末はキャラクタ<CR><LF>の組でなければなりません、そして、charsetは登録されたcharsetであるべきです[CHARSETS]。 canonicalizationの細部は[MIME-SPEC]で指定されます。 charset SHOULDが選ばれて、受信エージェントが、charsetが使用したと明白に決心できるように、charsetパラメタで命名されてください。
Note that some charsets such as ISO-2022 have multiple representations for the same characters. When preparing such text for signing, the canonical representation specified for the charset MUST be used.
ISO-2022などのいくつかのcharsetsには同じキャラクタにおいて複数の表現があることに注意してください。 署名のためにそのようなテキストを準備するとき、charsetに指定された正準な表現を使用しなければなりません。
3.1.2 Transfer Encoding
3.1.2 転送コード化
When generating any of the secured MIME entities below, except the signing using the multipart/signed format, no transfer encoding at all is required. S/MIME implementations MUST be able to deal with binary MIME objects. If no Content-Transfer-Encoding header is present, the transfer encoding should be considered 7BIT.
複合の、または、署名している形式を使用する署名以外に、以下の機密保護しているMIME実体のどれかを生成するとき、全く転送コード化は必要ではありません。 S/MIME実装は2進のMIMEオブジェクトに対処できなければなりません。 どんなContentがコード化を移しているヘッダーも出席していないなら、転送コード化は7BITであると考えられるべきです。
Ramsdell Standards Track [Page 13] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[13ページ]。
S/MIME implementations SHOULD however use transfer encoding described in section 3.1.3 for all MIME entities they secure. The reason for securing only 7-bit MIME entities, even for enveloped data that are not exposed to the transport, is that it allows the MIME entity to be handled in any environment without changing it. For example, a trusted gateway might remove the envelope, but not the signature, of a message, and then forward the signed message on to the end recipient so that they can verify the signatures directly. If the transport internal to the site is not 8-bit clean, such as on a wide-area network with a single mail gateway, verifying the signature will not be possible unless the original MIME entity was only 7-bit data.
しかしながら、S/MIME実装SHOULDはそれらが保証するすべてのMIME実体のためにセクション3.1.3で説明された転送コード化を使用します。 7ビットの唯一のMIMEが実体であると機密保護して、輸送に暴露されないおおわれたデータさえの理由はMIME実体がそれを変えないでどんな環境でも扱われるのを許容するということです。 例えば、信じられたゲートウェイは、彼らが直接署名について確かめることができるように、署名ではなく、メッセージの封筒を取り外して、次に、署名しているメッセージを終わりの受取人に転送するかもしれません。 署名について確かめるのはオリジナルのMIME実体が7ビットのデータであっただけではないならサイトへの内部の輸送が8ビットでないなら、掃除してください、単一のメール・ゲートウェイがあるそのような同じくらいオン広域ネットワークが可能でないでしょう。
3.1.3 Transfer Encoding for Signing Using multipart/signed
3.1.3 Signing Usingのために複合か署名された状態でEncodingを移してください。
If a multipart/signed entity is EVER to be transmitted over the standard Internet SMTP infrastructure or other transport that is constrained to 7-bit text, it MUST have transfer encoding applied so that it is represented as 7-bit text. MIME entities that are 7-bit data already need no transfer encoding. Entities such as 8-bit text and binary data can be encoded with quoted-printable or base-64 transfer encoding.
複合の、または、署名している実体が標準のインターネットSMTPインフラストラクチャの上に伝えられるべきEVERか7ビットのテキストに抑制される他の輸送であるなら、それで、7ビットのテキストとして表されるように転送コード化を適用しなければなりません。 7ビットのデータであるMIME実体は既に転送コード化を必要としません。 引用されて印刷可能で8ビットのテキストやバイナリ・データなどの実体をコード化できますか、またはベース-64はコード化を移します。
The primary reason for the 7-bit requirement is that the Internet mail transport infrastructure cannot guarantee transport of 8-bit or binary data. Even though many segments of the transport infrastructure now handle 8-bit and even binary data, it is sometimes not possible to know whether the transport path is 8-bit clear. If a mail message with 8-bit data were to encounter a message transfer agent that can not transmit 8-bit or binary data, the agent has three options, none of which are acceptable for a clear-signed message:
7ビットの要件のプライマリ理由はインターネット・メール輸送インフラが8ビットかバイナリ・データの輸送を保証できないということです。 輸送インフラの多くのセグメントが現在8ビットの、そして、同等のバイナリ・データを扱いますが、輸送経路がはっきりと8ビットであるかどうかを知るのは時々可能ではありません。 8ビットのデータがあるメール・メッセージが8ビットで伝わることができないメッセージ転送エージェントかバイナリ・データに遭遇することであったなら、エージェントには、3つのオプションがあります:はっきりと署名しているメッセージにおいて、そのいずれも許容できません。
- The agent could change the transfer encoding; this would invalidate
the signature.
- The agent could transmit the data anyway, which would most likely
result in the 8th bit being corrupted; this too would invalidate the
signature.
- The agent could return the message to the sender.
- エージェントは転送コード化を変えることができました。 これは署名を無効にするでしょう。 - エージェントはとにかくデータを送ることができました(たぶん崩壊する8番目のビットをもたらすでしょう)。 これも署名を無効にするでしょう。 - エージェントはメッセージを送付者に返すことができました。
[MIME-SECURE] prohibits an agent from changing the transfer encoding of the first part of a multipart/signed message. If a compliant agent that can not transmit 8-bit or binary data encounters a multipart/signed message with 8-bit or binary data in the first part, it would have to return the message to the sender as undeliverable.
[MIME-SECURE]は複合の、または、署名しているメッセージの最初の部分の転送コード化を変えるのからエージェントを禁じます。 8ビットで伝わることができない言いなりになっているエージェントかバイナリ・データが最初の部分で8ビットかバイナリ・データで複合の、または、署名しているメッセージに遭遇するなら、それは「非-提出物」としてメッセージを送付者に返さなければならないでしょう。
Ramsdell Standards Track [Page 14] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[14ページ]。
3.1.4 Sample Canonical MIME Entity
3.1.4 サンプルの正準なMIME実体
This example shows a multipart/mixed message with full transfer encoding. This message contains a text part and an attachment. The sample message text includes characters that are not US-ASCII and thus must be transfer encoded. Though not shown here, the end of each line is <CR><LF>. The line ending of the MIME headers, the text, and transfer encoded parts, all must be <CR><LF>.
この例は完全移籍コード化で複合の、または、複雑なメッセージを示しています。 このメッセージはテキスト部分と付属を含んでいます。 サンプルメッセージ・テキストは、米国-ASCIIでないキャラクタを含んで、その結果コード化された転送であるに違いありません。 ここに示されませんが、それぞれの行の終わりは<CR><LF>です。 MIMEヘッダー、テキスト、および転送の系列結末は部品をコード化して、すべてが<CR><LF>であるに違いありません。
Note that this example is not of an S/MIME message.
この例がS/MIMEメッセージのものでないことに注意してください。
Content-Type: multipart/mixed; boundary=bar
コンテントタイプ: 複合か混ぜられる。 境界=バー
--bar
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
--コンテントタイプを禁じてください: テキスト/平野。 charset=iso-8859-1 Contentはコード化を移します: 引用されて印刷可能です。
=A1Hola Michael!
=A1Holaマイケル!
How do you like the new S/MIME specification?
新しいS/MIME仕様はいかがでしょうか?
I agree. It's generally a good idea to encode lines that begin with
From=20 because some mail transport agents will insert a
greater-than (>) sign, thus invalidating the signature.
私は同意します。 一般に、何人かのメール輸送エージェントがaを挿入するのでFrom=20と共に始まる系列をコード化するのが、名案である、すばらしさ、-、(>) 署名してください、その結果、署名を無効にします。
Also, in some cases it might be desirable to encode any =20
trailing whitespace that occurs on lines in order to ensure =20
that the message signature is not invalidated when passing =20
a gateway that modifies such whitespace (like BITNET). =20
また、いくつかの場合、そのような空白(Bitnetのような)を変更するゲートウェイを=20に通り過ぎるとき、メッセージ署名が無効にされないのも、=20を確実にするために系列に起こるどんな=20引きずり空白もコード化するのにおいて望ましいかもしれません。 =20
--bar
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
--コンテントタイプを禁じてください: jpeg Content転送イメージ/コード化: base64
iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
HOxEa44b+EI=
iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn HOxEa44b+EI=
--bar--
--バー--
3.2 The application/pkcs7-mime Type
3.2 pkcs7アプリケーション/パントマイムType
The application/pkcs7-mime type is used to carry CMS objects of several types including envelopedData and signedData. The details of constructing these entities is described in subsequent sections. This section describes the general characteristics of the application/pkcs7-mime type.
pkcs7アプリケーション/パントマイムタイプは、envelopedDataとsignedDataを含むいくつかのタイプのCMSオブジェクトを運ぶのに使用されます。 これらの実体を構成する詳細はその後のセクションで説明されます。 このセクションはpkcs7アプリケーション/パントマイムタイプの一般的特色について説明します。
Ramsdell Standards Track [Page 15] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[15ページ]。
The carried CMS object always contains a MIME entity that is prepared as described in section 3.1 if the eContentType is id-data. Other contents may be carried when the eContentType contains different values. See [ESS] for an example of this with signed receipts.
運ばれたCMSオブジェクトはいつもeContentTypeがイドデータであるならセクション3.1で説明されるように準備されたMIME実体を含んでいます。 eContentTypeが異価を含むとき、他のコンテンツは運ばれるかもしれません。 この例に関して署名している領収書で[ESS]を見てください。
Since CMS objects are binary data, in most cases base-64 transfer encoding is appropriate, in particular when used with SMTP transport. The transfer encoding used depends on the transport through which the object is to be sent, and is not a characteristic of the MIME type.
CMSオブジェクトがバイナリ・データであるので、多くの場合、ベース-64転送コード化は適切です、特定でSMTP輸送と共に使用されると。 コード化が使用した転送は、オブジェクトが送られることになっている輸送によって、MIMEの種類の特性ではありません。
Note that this discussion refers to the transfer encoding of the CMS object or "outside" MIME entity. It is completely distinct from, and unrelated to, the transfer encoding of the MIME entity secured by the CMS object, the "inside" object, which is described in section 3.1.
この議論がCMSオブジェクトか「外」のMIME実体の転送コード化について言及することに注意してください。 それは、転送がCMSオブジェクトによって保証されたMIME実体をコード化することでの“inside"オブジェクトに完全に異なって関係ありません。(それは、セクション3.1で説明されます)。
Because there are several types of application/pkcs7-mime objects, a sending agent SHOULD do as much as possible to help a receiving agent know about the contents of the object without forcing the receiving agent to decode the ASN.1 for the object. The MIME headers of all application/pkcs7-mime objects SHOULD include the optional "smime- type" parameter, as described in the following sections.
いくつかのタイプのpkcs7アプリケーション/パントマイムオブジェクトがあるので、SHOULDが受信エージェントにオブジェクトのためにASN.1を解読させないで受信エージェントがオブジェクトのコンテンツに関して知るのを助けるためにできるだけする送付エージェントです。 すべてのpkcs7アプリケーション/パントマイムオブジェクトSHOULDのMIMEヘッダーは以下のセクションで説明されるように任意の「smimeタイプ」パラメタを入れます。
3.2.1 The name and filename Parameters
3.2.1 名前とファイル名Parameters
For the application/pkcs7-mime, sending agents SHOULD emit the optional "name" parameter to the Content-Type field for compatibility with older systems. Sending agents SHOULD also emit the optional Content-Disposition field [CONTDISP] with the "filename" parameter. If a sending agent emits the above parameters, the value of the parameters SHOULD be a file name with the appropriate extension:
pkcs7アプリケーション/パントマイムのために、送付エージェントSHOULDはパラメタという任意の「名前」をより古いシステムとの互換性のためのコンテントタイプ分野に放ちます。また、送付エージェントSHOULDは「ファイル名」パラメタがある任意のContent-気質分野[CONTDISP]を放ちます。 発信エージェントは上記のパラメタを放ちます、値。パラメタSHOULDでは、適切な拡大を伴うファイル名になってください:
MIME Type File Extension
MIMEの種類ファイル拡張子
Application/pkcs7-mime (signedData, .p7m envelopedData)
pkcs7アプリケーション/パントマイム(signedData、.p7m envelopedData)
Application/pkcs7-mime (degenerate .p7c signedData "certs-only" message)
pkcs7アプリケーション/パントマイム(堕落した.p7c signedData「本命専用」メッセージ)
Application/pkcs7-signature .p7s
pkcs7アプリケーション/署名.p7s
In addition, the file name SHOULD be limited to eight characters followed by a three letter extension. The eight character filename base can be any distinct name; the use of the filename base "smime" SHOULD be used to indicate that the MIME entity is associated with S/MIME.
さらに、存在という8つのキャラクタに制限されたファイル名のSHOULDは3手紙拡張子で続きました。 8キャラクタファイル名ベースはどんな別個の名前であるかもしれませんも。 ファイル名の使用は"smime"SHOULDを基礎づけます。使用されて、MIME実体がS/MIMEに関連しているのを示してください。
Ramsdell Standards Track [Page 16] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[16ページ]。
Including a file name serves two purposes. It facilitates easier use of S/MIME objects as files on disk. It also can convey type information across gateways. When a MIME entity of type application/pkcs7-mime (for example) arrives at a gateway that has no special knowledge of S/MIME, it will default the entity's MIME type to application/octet-stream and treat it as a generic attachment, thus losing the type information. However, the suggested filename for an attachment is often carried across a gateway. This often allows the receiving systems to determine the appropriate application to hand the attachment off to, in this case a stand-alone S/MIME processing application. Note that this mechanism is provided as a convenience for implementations in certain environments. A proper S/MIME implementation MUST use the MIME types and MUST NOT rely on the file extensions.
ファイル名が2つの目的に役立つ包含。 それはディスクの上のファイルとしてS/MIMEオブジェクトの、より簡単な使用を容易にします。 また、それはゲートウェイの向こう側にタイプ情報を伝えることができます。 (例えば、)タイプpkcs7アプリケーション/パントマイムのMIME実体が到着すると、アプリケーション/への実体のMIMEの種類は、S/MIMEでは、デフォルトとするというどんな特別な知識も持っていないゲートウェイでは、八重奏で流れて、ジェネリック付属としてそれを扱います、その結果、タイプ情報を失います。 しかしながら、付属のための提案されたファイル名はゲートウェイの向こう側にしばしば運ばれます。 これはしばしば付属を渡すのが適切であるアプリケーションを決定する受電方式を許容します、この場合スタンドアロンのS/MIMEがアプリケーションを処理して。 このメカニズムが実装のための便利としてある環境に提供されることに注意してください。 適切なS/MIME実装は、MIMEの種類を使用しなければならなくて、ファイル拡張子を当てにしてはいけません。
3.2.2 The smime-type parameter
3.2.2 smime-型引数
The application/pkcs7-mime content type defines the optional "smime- type" parameter. The intent of this parameter is to convey details about the security applied (signed or enveloped) along with infomation about the contained content. This memo defines the following smime-types.
pkcs7アプリケーション/パントマイムcontent typeは任意の「smimeタイプ」パラメタを定義します。 このパラメタの意図はinfomationと共に含まれた内容に関して適用された(署名されるか、またはおおわれます)セキュリティに関する詳細を伝えることです。 このメモは以下のsmime-タイプを定義します。
Name Security Inner Content
内側の内容とセキュリティを命名してください。
enveloped-data EnvelopedData id-data
おおわれたデータEnvelopedDataイドデータ
signed-data SignedData id-data
署名しているデータSignedDataイドデータ
certs-only SignedData none
本命だけSignedData、なし
In order that consistency can be obtained with future, the following guidelines should be followed when assigning a new smime-type parameter.
新しいsmime-型引数を割り当てるとき、未来で一貫性を得ることができるように、以下のガイドラインは従われるべきです。
1. If both signing and encryption can be applied to the content, then two values for smime-type SHOULD be assigned "signed-*" and "encrypted-*". If one operation can be assigned then this may be omitted. Thus since "certs-only" can only be signed, "signed-" is omitted.
1. smime-タイプSHOULDのために満足していて、当時の2つの値に署名と暗号化の両方を適用できるなら、「署名している*」と「暗号化された*」は割り当てられてください。 1つの操作を割り当てることができるなら、これは省略されるかもしれません。 したがって、「本命専用」に署名することができるだけであるので、「署名すること」は省略されます。
2. A common string for a content oid should be assigned. We use "data" for the id-data content OID when MIME is the inner content.
2. 満足しているoidのための一般的なストリングは割り当てられるべきです。 MIMEが内側の内容であるときに、私たちはイドデータ内容OIDに「データ」を使用します。
3. If no common string is assigned. Then the common string of "OID.<oid>" is recommended (for example, "OID.1.3.6.1.5.5.7.6.1" would be DES40).
3. どんな一般的なストリングも割り当てられないなら。 次に、「OID<oid>」の一般的なストリングがお勧めである、(例えば、「OID.1.3、.6、.1、.5、.5、.7、.6、0.1インチがDES40であるだろう、)、」
Ramsdell Standards Track [Page 17] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[17ページ]。
3.3 Creating an Enveloped-only Message
3.3が作成される、おおわれて唯一のメッセージ
This section describes the format for enveloping a MIME entity without signing it. It is important to note that sending enveloped but not signed messages does not provide for data integrity. It is possible to replace ciphertext in such a way that the processed message will still be valid, but the meaning may be altered.
このセクションは、それに署名しないでMIME実体をおおうために形式について説明します。 おおわれますが、メッセージであることは署名されない発信がデータ保全に備えないことに注意するのが重要です。 処理メッセージがまだ有効になっていますが、意味が変更されるかもしれないような方法で暗号文を取り替えるのは可能です。
Step 1. The MIME entity to be enveloped is prepared according to section 3.1.
1を踏んでください。 セクション3.1によると、おおわれるべきMIME実体は準備されます。
Step 2. The MIME entity and other required data is processed into a CMS object of type envelopedData. In addition to encrypting a copy of the content-encryption key for each recipient, a copy of the content encryption key SHOULD be encrypted for the originator and included in the envelopedData (see CMS Section 6).
2を踏んでください。 MIME実体と他の必要なデータはタイプenvelopedDataのCMSオブジェクトに処理されます。 各受取人、満足している暗号化の主要なSHOULDのコピーに、主要な満足している暗号化のコピーを暗号化することに加えて、創始者のために暗号化されていて、envelopedDataで含められてください(CMSセクション6を見てください)。
Step 3. The CMS object is inserted into an application/pkcs7-mime MIME entity.
3を踏んでください。 CMSオブジェクトはpkcs7アプリケーション/パントマイムMIME実体に挿入されます。
The smime-type parameter for enveloped-only messages is "enveloped- data". The file extension for this type of message is ".p7m".
おおわれて唯一のメッセージのためのsmime-型引数は「おおわれたデータ」です。 このタイプに関するメッセージのためのファイル拡張子は".p7m"です。
A sample message would be:
サンプルメッセージは以下の通りでしょう。
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
コンテントタイプ: pkcs7アプリケーション/パントマイム。 smime-タイプはおおわれたデータと等しいです。 =smime.p7m Content-転送コード化を命名してください: base64 Content-気質: 付属。 ファイル名=smime.p7m
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
0GhIGfHfQbnj756YT64V
rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 0GhIGfHfQbnj756YT64V
3.4 Creating a Signed-only Message
aを作成する3.4、署名されて唯一のメッセージ
There are two formats for signed messages defined for S/MIME: application/pkcs7-mime with SignedData, and multipart/signed. In general, the multipart/signed form is preferred for sending, and receiving agents SHOULD be able to handle both.
S/MIMEのために定義された署名しているメッセージのための2つの形式があります: SignedDataがあるpkcs7アプリケーション/パントマイム、および複合/は署名しました。 一般に、複合の、または、署名しているフォームは送付のために好まれます、そして、エージェントSHOULDを受けて、両方を扱うことができてください。
Ramsdell Standards Track [Page 18] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[18ページ]。
3.4.1 Choosing a Format for Signed-only Messages
3.4.1 署名されて唯一のメッセージのための形式を選ぶこと。
There are no hard-and-fast rules when a particular signed-only format should be chosen because it depends on the capabilities of all the receivers and the relative importance of receivers with S/MIME facilities being able to verify the signature versus the importance of receivers without S/MIME software being able to view the message.
事項であるときに、すべての受信機の能力とS/MIME施設がS/MIMEソフトウェアなしで受信機の重要性に対して署名について確かめることができる受信機の相対的な重要性によるので、署名されて唯一の形式が選ばれるべきであるというメッセージを見ることができるどんな厳重な規則もありません。
Messages signed using the multipart/signed format can always be viewed by the receiver whether they have S/MIME software or not. They can also be viewed whether they are using a MIME-native user agent or they have messages translated by a gateway. In this context, "be viewed" means the ability to process the message essentially as if it were not a signed message, including any other MIME structure the message might have.
それらにS/MIMEソフトウェアがあるか否かに関係なく、受信機はいつも複合の、または、署名している形式を使用することで署名されるメッセージを見ることができます。 また、彼らが固有のMIMEユーザエージェントを使用しているか否かに関係なく、それらを見ることができますか、または彼らはゲートウェイでメッセージを翻訳させます。 このような関係においては、「見られてください」はまるでそれが本質的には署名しているメッセージでないかのようにメッセージを処理する能力を意味します、メッセージが持っているかもしれないいかなる他のMIME構造も含んでいて。
Messages signed using the signedData format cannot be viewed by a recipient unless they have S/MIME facilities. However, if they have S/MIME facilities, these messages can always be verified if they were not changed in transit.
それらにS/MIME施設がないなら、受取人はsignedData形式を使用することで署名されるメッセージを見ることができません。 しかしながら、彼らがS/MIME施設を持って、それらがトランジットで変えられなかったなら、いつもこれらのメッセージについて確かめることができます。
3.4.2 Signing Using application/pkcs7-mime with SignedData
3.4.2 SignedDataと共にUsingがpkcs7アプリケーション/パントマイムであると署名すること。
This signing format uses the application/pkcs7-mime MIME type. The steps to create this format are:
この署名形式はpkcs7アプリケーション/パントマイムMIMEの種類を使用します。 この形式を作成するステップは以下の通りです。
Step 1. The MIME entity is prepared according to section 3.1
1を踏んでください。 セクション3.1によると、MIME実体は準備されます。
Step 2. The MIME entity and other required data is processed into a CMS object of type signedData
2を踏んでください。 MIME実体と他の必要なデータはタイプsignedDataのCMSオブジェクトに処理されます。
Step 3. The CMS object is inserted into an application/pkcs7-mime MIME entity
3を踏んでください。 CMSオブジェクトはpkcs7アプリケーション/パントマイムMIME実体に挿入されます。
The smime-type parameter for messages using application/pkcs7-mime with SignedData is "signed-data". The file extension for this type of message is ".p7m".
SignedDataがあるpkcs7アプリケーション/パントマイムを使用するメッセージのためのsmime-型引数は「署名しているデータ」です。 このタイプに関するメッセージのためのファイル拡張子は".p7m"です。
A sample message would be:
サンプルメッセージは以下の通りでしょう。
Content-Type: application/pkcs7-mime; smime-type=signed-data;
name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
コンテントタイプ: pkcs7アプリケーション/パントマイム。 smime-タイプは署名しているデータと等しいです。 =smime.p7m Content-転送コード化を命名してください: base64 Content-気質: 付属。 ファイル名=smime.p7m
Ramsdell Standards Track [Page 19] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[19ページ]。
567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
6YT64V0GhIGfHfQbnj75
567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7 77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh6YT64V0GhIGfHfQbnj75
3.4.3 Signing Using the multipart/signed Format
3.4.3 Usingが複合の、または、署名しているFormatであると署名すること。
This format is a clear-signing format. Recipients without any S/MIME or CMS processing facilities are able to view the message. It makes use of the multipart/signed MIME type described in [MIME-SECURE]. The multipart/signed MIME type has two parts. The first part contains the MIME entity that is signed; the second part contains the "detached signature" CMS SignedData object in which the encapContentInfo eContent field is absent.
この形式は明確な署名形式です。 少しもS/MIMEやCMS処理施設のない受取人はメッセージを見ることができます。 それは[MIME-SECURE]で説明された複合の、または、署名しているMIMEの種類を利用します。 複合の、または、署名しているMIMEの種類には、2つの部品があります。 最初の部分は署名されるMIME実体を含んでいます。 第二部はencapContentInfo eContent分野が欠けている「離れている署名」CMS SignedDataオブジェクトを含んでいます。
3.4.3.1 The application/pkcs7-signature MIME Type
3.4.3.1 pkcs7アプリケーション/署名MIMEの種類
This MIME type always contains a single CMS object of type signedData. The signedData encapContentInfo eContent field MUST be absent. The signerInfos field contains the signatures for the MIME entity.
このMIMEの種類はいつもタイプsignedDataの単一のCMSオブジェクトを含んでいます。 signedData encapContentInfo eContent分野は欠けているに違いありません。 signerInfos分野はMIME実体のための署名を含んでいます。
The file extension for signed-only messages using application/pkcs7- signature is ".p7s".
アプリケーション/pkcs7署名を使用する署名されて唯一のメッセージのためのファイル拡張子は".p7s"です。
3.4.3.2 Creating a multipart/signed Message
3.4.3.2 複合の、または、署名しているMessageを作成すること。
Step 1. The MIME entity to be signed is prepared according to section 3.1, taking special care for clear-signing.
1を踏んでください。 明確な署名のために特別に注意を払って、セクション3.1によると、署名されるMIME実体は準備されます。
Step 2. The MIME entity is presented to CMS processing in order to obtain an object of type signedData in which the encapContentInfo eContent field is absent.
2を踏んでください。 MIME実体は、encapContentInfo eContent分野が欠けているタイプsignedDataのオブジェクトを入手するためにCMS処理に提示されます。
Step 3. The MIME entity is inserted into the first part of a multipart/signed message with no processing other than that described in section 3.1.
3を踏んでください。 セクション3.1で説明されるのを除いて、MIME実体は処理なしで複合の、または、署名しているメッセージの最初の部分に挿入されます。
Step 4. Transfer encoding is applied to the "detached signature" CMS SignedData object and it is inserted into a MIME entity of type application/pkcs7-signature.
4を踏んでください。 転送コード化は「離れている署名」CMS SignedDataオブジェクトに適用されます、そして、それはタイプpkcs7アプリケーション/署名のMIME実体に挿入されます。
Step 5. The MIME entity of the application/pkcs7-signature is inserted into the second part of the multipart/signed entity.
5を踏んでください。 pkcs7アプリケーション/署名のMIME実体は複合の、または、署名している実体の第二部に挿入されます。
The multipart/signed Content type has two required parameters: the protocol parameter and the micalg parameter.
複合の、または、署名しているContentタイプには、2つの必要なパラメタがあります: プロトコルパラメタとmicalgパラメタ。
Ramsdell Standards Track [Page 20] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[20ページ]。
The protocol parameter MUST be "application/pkcs7-signature". Note that quotation marks are required around the protocol parameter because MIME requires that the "/" character in the parameter value MUST be quoted.
プロトコルパラメタは「pkcs7アプリケーション/署名」であるに違いありません。 「MIMEがそれを必要とするので引用符がプロトコルパラメタの周りで必要であることに注意してください、」 /、」 パラメタ値におけるキャラクタを引用しなければなりません。
The micalg parameter allows for one-pass processing when the signature is being verified. The value of the micalg parameter is dependent on the message digest algorithm(s) used in the calculation of the Message Integrity Check. If multiple message digest algorithms are used they MUST be separated by commas per [MIME-SECURE]. The values to be placed in the micalg parameter SHOULD be from the following:
署名が確かめられているとき、micalgパラメタは1パスの処理を考慮します。 micalgパラメタの値はMessage Integrity Checkの計算に使用されるメッセージダイジェストアルゴリズムに依存しています。 複数のメッセージダイジェストアルゴリズムが使用されているなら、[MIME-SECURE]あたりのコンマでそれらを切り離さなければなりません。 micalgパラメタSHOULDに置かれるべき値は以下からの以下の通りです。
Algorithm Value used
Valueが使用したアルゴリズム
MD5 md5 SHA-1 sha1 Any other unknown
MD5 md5 SHA-1 sha1 Any他の未知
(Historical note: some early implementations of S/MIME emitted and expected "rsa-md5" and "rsa-sha1" for the micalg parameter.) Receiving agents SHOULD be able to recover gracefully from a micalg parameter value that they do not recognize.
そして、(歴史的な注意: S/MIMEのいくつかの早めの実装が放って、予想した、「rsa-md5"、「micalgパラメタのためのrsa-sha1")。」 エージェントSHOULDを受けて、彼らが認識しないmicalgパラメタ価値から優雅に回復できてください。
3.4.3.3 Sample multipart/signed Message
3.4.3.3 サンプルの複合の、または、署名しているMessage
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
コンテントタイプ: 複合か署名される。 =「pkcs7アプリケーション/署名」について議定書の中で述べてください。 micalg=sha1。 境界=boundary42
--boundary42
Content-Type: text/plain
--boundary42コンテントタイプ: テキスト/平野
This is a clear-signed message.
これははっきりと署名しているメッセージです。
--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
--boundary42コンテントタイプ: pkcs7アプリケーション/署名。 =smime.p7s Content-転送コード化を命名してください: base64 Content-気質: 付属。 ファイル名=smime.p7s
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756
ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756
--boundary42--
--boundary42--
Ramsdell Standards Track [Page 21] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[21ページ]。
3.5 Signing and Encrypting
3.5 署名と暗号化
To achieve signing and enveloping, any of the signed-only and encrypted-only formats may be nested. This is allowed because the above formats are all MIME entities, and because they all secure MIME entities.
署名とおおう署名されて唯一で暗号化されて唯一の形式のどれかを達成するのは入れ子にされるかもしれません。 上の形式がすべてMIME実体であり、MIMEが実体であると機密保護するので、これは許容されています。
An S/MIME implementation MUST be able to receive and process arbitrarily nested S/MIME within reasonable resource limits of the recipient computer.
S/MIME実装は、受取人コンピュータの妥当なリソース限界の中で任意に入れ子にされたS/MIMEを、受けて、処理できなければなりません。
It is possible to either sign a message first, or to envelope the message first. It is up to the implementor and the user to choose. When signing first, the signatories are then securely obscured by the enveloping. When enveloping first the signatories are exposed, but it is possible to verify signatures without removing the enveloping. This may be useful in an environment were automatic signature verification is desired, as no private key material is required to verify a signature.
最初に最初にか封筒へのメッセージがメッセージであると署名するのは可能です。 選ぶのは、作成者とユーザ次第です。 最初に署名すると、署名者はおおうことでしっかりと見えなくされます。 1番目をおおうとき、署名者は暴露されますが、おおうことを取り除かないで署名について確かめるのは可能です。 これによる環境で役に立つのが、自動署名照合は望まれています、秘密鍵の材料が全く署名について確かめるのに必要でないときにことであったということであるかもしれません。
There are security ramifications to choosing whether to sign first or encrypt first. A recipient of a message that is encrypted and then signed can validate that the encrypted block was unaltered, but cannot determine any relationship between the signer and the unencrypted contents of the message. A recipient of a message that is signed-then-encrypted can assume that the signed message itself has not been altered, but that a careful attacker may have changed the unauthenticated portions of the encrypted message.
最初に、署名するか、または1番目を暗号化するかを選ぶことへのセキュリティ分岐があります。 非変更しましたが、暗号化されたブロックがそうであったという暗号化されていて、次に、署名されて、有効にされることができるメッセージの受取人はメッセージの署名者と非暗号化されたコンテンツとの少しの関係も決定できません。 その時暗号化されていた状態で署名されて、慎重な攻撃者が暗号化メッセージの非認証された部分を変えていなかったかもしれないなら署名しているメッセージ自体が変更されていないと仮定できるということであるメッセージの受取人。
3.6 Creating a Certificates-only Message
3.6 証明書だけメッセージを作成すること。
The certificates only message or MIME entity is used to transport certificates, such as in response to a registration request. This format can also be used to convey CRLs.
メッセージかMIME実体だけが使用されている証明書は登録要求に対応したなど証明書を輸送します。 また、CRLsを運ぶのにこの形式を使用できます。
Step 1. The certificates are made available to the CMS generating process which creates a CMS object of type signedData. The signedData encapContentInfo eContent field MUST be absent and signerInfos field MUST be empty.
1を踏んでください。 タイプsignedDataのCMSオブジェクトを作成するプロセスを生成するCMSは証明書を入手します。 signedData encapContentInfo eContent分野は欠けるに違いありません、そして、signerInfos分野は人影がないに違いありません。
Step 2. The CMS signedData object is enclosed in an application/pkcs7-mime MIME entity
2を踏んでください。 CMS signedDataオブジェクトはpkcs7アプリケーション/パントマイムMIME実体で同封されます。
The smime-type parameter for a certs-only message is "certs-only". The file extension for this type of message is ".p7c".
本命だけメッセージのためのsmime-型引数は「本命専用」です。 このタイプに関するメッセージのためのファイル拡張子は".p7c"です。
Ramsdell Standards Track [Page 22] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[22ページ]。
3.7 Registration Requests
3.7 登録要求
A sending agent that signs messages MUST have a certificate for the signature so that a receiving agent can verify the signature. There are many ways of getting certificates, such as through an exchange with a certificate authority, through a hardware token or diskette, and so on.
メッセージに署名する送付エージェントは、受信エージェントが署名について確かめることができるように、署名のための証明書を持たなければなりません。 証明書を手に入れる多くの方法があります、ハードウェアトークンかディスケットを通して認証局がある交換などなどのように。
S/MIME v2 [SMIMEV2] specified a method for "registering" public keys with certificate authorities using an application/pkcs10 body part. The IETF's PKIX Working Group is preparing another method for requesting certificates; however, that work was not finished at the time of this memo. S/MIME v3 does not specify how to request a
S/MIME v2[SMIMEV2]は、認証局でアプリケーション/pkcs10身体の部分を使用することで「登録」公開鍵にメソッドを指定しました。 IETFのPKIX作業部会は証明書を要求するために別のメソッドを準備しています。 しかしながら、その仕事はこのメモ時点で、終わりませんでした。 S/MIME v3はaを要求する方法を指定しません。
certificate, but instead mandates that every sending agent already has a certificate. Standardization of certificate management is being pursued separately in the IETF.
証明しますが、すべての送付エージェントには証明書が既にあるのを代わりに強制します。 証明書管理の標準化は別々にIETFで追求されています。
3.8 Identifying an S/MIME Message
3.8 S/MIMEメッセージを特定すること。
Because S/MIME takes into account interoperation in non-MIME environments, several different mechanisms are employed to carry the type information, and it becomes a bit difficult to identify S/MIME messages. The following table lists criteria for determining whether or not a message is an S/MIME message. A message is considered an S/MIME message if it matches any below.
S/MIMEが非MIME環境でinteroperationを考慮に入れるので、数個の異なったメカニズムがタイプ情報を運ぶのに使われます、そして、S/MIMEメッセージを特定するのは少し難しくなります。 以下のテーブルはメッセージがS/MIMEメッセージであるかどうか決定する評価基準を記載します。 以下のいずれかも合わせるなら、メッセージはS/MIMEメッセージであると考えられます。
The file suffix in the table below comes from the "name" parameter in the content-type header, or the "filename" parameter on the content- disposition header. These parameters that give the file suffix are not listed below as part of the parameter section.
以下のテーブルのファイル接尾語はcontent typeヘッダーの「名前」パラメタ、または内容気質ヘッダーに関する「ファイル名」パラメタから来ます。 ファイル接尾語を与えるこれらのパラメタがパラメタ部の一部として以下にリストアップされていません。
MIME type: application/pkcs7-mime parameters: any file suffix: any
MIMEの種類: pkcs7アプリケーション/パントマイムパラメタ: どんなファイル接尾語も: いくらか
MIME type: multipart/signed parameters: protocol="application/pkcs7-signature" file suffix: any
MIMEの種類: 複合の、または、署名しているパラメタ: =「pkcs7アプリケーション/署名」ファイル接尾語について議定書の中で述べてください: いくらか
MIME type: application/octet-stream parameters: any file suffix: p7m, p7s, p7c
MIMEの種類: 八重奏アプリケーション/ストリームパラメタ: どんなファイル接尾語も: p7m、p7s、p7c
Ramsdell Standards Track [Page 23] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[23ページ]。
4. Certificate Processing
4. 証明書処理
A receiving agent MUST provide some certificate retrieval mechanism in order to gain access to certificates for recipients of digital envelopes. This memo does not cover how S/MIME agents handle certificates, only what they do after a certificate has been validated or rejected. S/MIME certification issues are covered in [CERT3].
受信エージェントは、デジタル封筒の受取人への証明書へのアクセスを得るために何らかの証明書回収機構を提供しなければなりません。 このメモはS/MIMEエージェントがどう証明書を扱うかをカバーしていません、証明書が有効にされるか、または拒絶された後にそれらがすることだけ。 S/MIME証明問題は[CERT3]でカバーされています。
At a minimum, for initial S/MIME deployment, a user agent could automatically generate a message to an intended recipient requesting that recipient's certificate in a signed return message. Receiving and sending agents SHOULD also provide a mechanism to allow a user to "store and protect" certificates for correspondents in such a way so as to guarantee their later retrieval.
最小限では、初期のS/MIME展開のために、ユーザエージェントは自動的に署名しているリターンメッセージのその受取人の証明書を要求する意図している受取人にメッセージを生成することができました。 また、エージェントSHOULDを受けて、送ると、メカニズムは、彼らの後の検索を保証するためにユーザが通信員のためにそのような方法で証明書を「保存して、保護すること」を許容するために提供されます。
4.1 Key Pair Generation
主要な4.1組世代
If an S/MIME agent needs to generate a key pair, then the S/MIME agent or some related administrative utility or function MUST be capable of generating separate DH and DSS public/private key pairs on behalf of the user. Each key pair MUST be generated from a good source of non-deterministic random input [RANDOM] and the private key MUST be protected in a secure fashion.
S/MIMEエージェントが、主要な組を生成する必要があるなら、何らかのS/MIMEエージェント、関連する管理ユーティリティまたは機能がユーザを代表して別々のDHとDSS公衆/秘密鍵組を生成することができなければなりません。 非決定論的な無作為の入力[RANDOM]の良い源からそれぞれの主要な組を生成しなければなりません、そして、安全なファッションで秘密鍵を保護しなければなりません。
If an S/MIME agent needs to generate a key pair, then the S/MIME agent or some related administrative utility or function SHOULD generate RSA key pairs.
S/MIMEエージェントが、主要な組を生成する必要があるなら、S/MIMEエージェントか或るものが管理ユーティリティについて話したか、または機能SHOULDはRSA主要な組を生成します。
A user agent SHOULD generate RSA key pairs at a minimum key size of 768 bits. A user agent MUST NOT generate RSA key pairs less than 512 bits long. Creating keys longer than 1024 bits may cause some older S/MIME receiving agents to not be able to verify signatures, but gives better security and is therefore valuable. A receiving agent SHOULD be able to verify signatures with keys of any size over 512 bits. Some agents created in the United States have chosen to create 512 bit keys in order to get more advantageous export licenses. However, 512 bit keys are considered by many to be cryptographically insecure. Implementors should be aware that multiple (active) key pairs may be associated with a single individual. For example, one key pair may be used to support confidentiality, while a different key pair may be used for authentication.
SHOULDがRSAキーを生成するユーザエージェントは最低768ビットの主要なサイズで対にします。 ユーザエージェントは長さ512ビットのRSA主要な組を生成してはいけません。 1024ビットより長い間キーを作成するのは、エージェントを受ける何らかのより古いS/MIMEが署名について確かめることができないことを引き起こすかもしれませんが、より良いセキュリティを与えて、したがって、貴重です。 エージェントSHOULDを受けて、どんな512ビット以上のサイズのキーによる署名についても確かめることができてください。 合衆国で創造されたエージェントの中には、より有利な輸出承認を得るために512ビットのキーを作成するのを選んだ人もいました。 しかしながら、512ビットのキーは多くによって暗号で不安定な状態で考えられます。 作成者は複数の(アクティブ)の主要な組が単独の個人に関連しているかもしれないのを意識しているべきです。 例えば、主要な1組は秘密性をサポートするのに使用されるかもしれません、異なった主要な組が認証に使用されるかもしれませんが。
Ramsdell Standards Track [Page 24] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[24ページ]。
5. Security
5. セキュリティ
This entire memo discusses security. Security issues not covered in other parts of the memo include:
この全体のメモはセキュリティについて議論します。 メモの他の部分でカバーされなかった安全保障問題は:
40-bit encryption is considered weak by most cryptographers. Using weak cryptography in S/MIME offers little actual security over sending plaintext. However, other features of S/MIME, such as the specification of tripleDES and the ability to announce stronger cryptographic capabilities to parties with whom you communicate, allow senders to create messages that use strong encryption. Using weak cryptography is never recommended unless the only alternative is no cryptography. When feasible, sending and receiving agents should inform senders and recipients the relative cryptographic strength of messages.
40ビットの暗号化は弱いとほとんどの暗号使用者によって考えられます。 S/MIMEに弱い暗号を使用するのはほとんど送付平文の上に実際のセキュリティを提供しません。 しかしながら、tripleDESの仕様などのS/MIMEの他の特徴とあなたと交信するパーティーへの、より強い暗号の能力を発表する能力で、送付者は強い暗号化を使用するメッセージを作成できます。 弱い暗号を使用するのは唯一の選択肢が暗号であるなら決してお勧めではありません。 可能であるときに、送受信エージェントはメッセージの相対的な暗号の強さの送付者と受取人に知らせるべきです。
It is impossible for most software or people to estimate the value of a message. Further, it is impossible for most software or people to estimate the actual cost of decrypting a message that is encrypted with a key of a particular size. Further, it is quite difficult to determine the cost of a failed decryption if a recipient cannot decode a message. Thus, choosing between different key sizes (or choosing whether to just use plaintext) is also impossible. However, decisions based on these criteria are made all the time, and therefore this memo gives a framework for using those estimates in choosing algorithms.
ほとんどのソフトウェアか人々がメッセージの値を見積もっているのは、不可能です。 さらに、ほとんどのソフトウェアか人々が、メッセージがそれであると解読する実費が特定のサイズのキーで暗号化されると見積もっているのは、不可能です。 さらに、受取人が暗号文を普通文に直すことができないなら、失敗した復号化の費用を決定するのはかなり難しいです。 また、したがって、異なった主要なサイズ(ただ平文を使用するかどうかを選んで)を選ぶのも不可能です。 しかしながら、絶えずこれらの評価基準に基づく決定をします、そして、したがって、このメモはアルゴリズムを選ぶ際にそれらの見積りを使用するためにフレームワークを与えます。
If a sending agent is sending the same message using different strengths of cryptography, an attacker watching the communications channel may be able to determine the contents of the strongly- encrypted message by decrypting the weakly-encrypted version. In other words, a sender should not send a copy of a message using weaker cryptography than they would use for the original of the message.
送付エージェントが暗号の異なった強さを使用することで同じメッセージを送るなら、コミュニケーションチャンネルを監視している攻撃者は、弱々しく暗号化されたバージョンを解読することによって、強く暗号化されたメッセージのコンテンツを決定できるかもしれません。 言い換えれば、送付者は、彼らがメッセージのオリジナルに使用するだろうより弱い暗号を使用することでメッセージのコピーを送るべきではありません。
Modification of the ciphertext can go undetected if authentication is not also used, which is the case when sending EnvelopedData without wrapping it in SignedData or enclosing SignedData within it.
また、認証(SignedDataでそれを包装するか、またはそれの中にSignedDataを同封しないでEnvelopedDataを送るとき、ケースである)が使用されないなら、暗号文の変更は察知されずにいることができます。
Ramsdell Standards Track [Page 25] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[25ページ]。
A. ASN.1 Module
A。 ASN.1モジュール
SecureMimeMessageV3
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) smime(4) }
SecureMimeMessageV3iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)smime(4)
DEFINITIONS IMPLICIT TAGS ::= BEGIN
定義、内在しているタグ:、:= 始まってください。
IMPORTS
-- Cryptographic Message Syntax
SubjectKeyIdentifier, IssuerAndSerialNumber,
RecipientKeyIdentifier
FROM CryptographicMessageSyntax
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) };
IMPORTS--暗号のMessage Syntax SubjectKeyIdentifier、IssuerAndSerialNumber、RecipientKeyIdentifier FROM CryptographicMessageSyntax、iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)cm(1)、。
-- id-aa is the arc with all new authenticated and unauthenticated -- attributes produced the by S/MIME Working Group
-- 認証されて、非認証されて、イド-aaはすべてが新しいアークです--属性が作り出された、S/MIME作業部会
id-aa OBJECT IDENTIFIER ::= {iso(1) member-body(2) usa(840)
rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) attributes(2)}
イド-aa OBJECT IDENTIFIER:、:= iso(1)メンバーボディー(2)usa(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)は(2)を結果と考えます。
-- S/MIME Capabilities provides a method of broadcasting the symetric -- capabilities understood. Algorithms should be ordered by preference -- and grouped by type
-- S/MIME Capabilitiesはsymetricを放送するメソッドを提供します--能力は分かりました。 アルゴリズムは好みで注文されるべきです--そして、タイプによって分類されます。
smimeCapabilities OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}
smimeCapabilitiesオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9)15をメンバーと同じくらい具体化させます。
SMIMECapability ::= SEQUENCE {
capabilityID OBJECT IDENTIFIER,
parameters ANY DEFINED BY capabilityID OPTIONAL }
SMIMECapability:、:= 系列capabilityID OBJECT IDENTIFIER、パラメタいずれもDEFINED BY capabilityID OPTIONAL
SMIMECapabilities ::= SEQUENCE OF SMIMECapability
SMIMECapabilities:、:= SMIMECapabilityの系列
-- Encryption Key Preference provides a method of broadcasting the -- preferred encryption certificate.
-- 暗号化Key Preferenceが放送のメソッドを提供する、--都合のよい暗号化証明書。
id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11}
イド-aa-encrypKeyPrefオブジェクト識別子:、:= イド-aa11
SMIMEEncryptionKeyPreference ::= CHOICE {
issuerAndSerialNumber [0] IssuerAndSerialNumber,
receipentKeyId [1] RecipientKeyIdentifier,
subjectAltKeyIdentifier [2] SubjectKeyIdentifier
}
SMIMEEncryptionKeyPreference:、:= 選択issuerAndSerialNumber[0]IssuerAndSerialNumber、receipentKeyId[1]RecipientKeyIdentifier、subjectAltKeyIdentifier[2]SubjectKeyIdentifier
Ramsdell Standards Track [Page 26] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[26ページ]。
-- The Content Encryption Algorithms defined for SMIME are:
-- SMIMEのために定義されたContent Encryption Algorithmsは以下の通りです。
-- Triple-DES is the manditory algorithm with CBCParameter being the -- parameters
-- 三重のDESがCBCParameter存在があるmanditoryアルゴリズムである、--、パラメタ
dES-EDE3-CBC OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549)
encryptionAlgorithm(3) 7}
dES-EDE3-CBCオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) encryptionAlgorithm(3)7をメンバーと同じくらい具体化させます。
CBCParameter ::= IV
CBCParameter:、:= IV
IV ::= OCTET STRING (SIZE (8..8))
IV:、:= 八重奏ストリング(サイズ(8 .8))
-- RC2 (or compatable) is an optional algorithm w/ RC2-CBC-paramter -- as the parameter
-- RC2(または、compatable)はパラメタとしてのRC2-CBC-paramterがある任意のアルゴリズムです。
rC2-CBC OBJECT IDENTIFIER ::=
{iso(1) member-body(2) us(840) rsadsi(113549)
encryptionAlgorithm(3) 2}
rC2-CBCオブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) encryptionAlgorithm(3)2をメンバーと同じくらい具体化させます。
-- For the effective-key-bits (key size) greater than 32 and less than -- 256, the RC2-CBC algorithm parameters are encoded as:
-- より32有効なキービット(主要なサイズ)と以下、--256 RC2-CBCアルゴリズムパラメタは以下としてコード化されます。
RC2-CBC-parameter ::= SEQUENCE {
rc2ParameterVersion INTEGER,
iv IV}
RC2-CBC-パラメタ:、:= 系列rc2ParameterVersion INTEGER、iv IV
-- For the effective-key-bits of 40, 64, and 128, the -- rc2ParameterVersion values are 160, 120, 58 respectively.
-- 40、64、および128の有効なキービット--rc2ParameterVersion値はそれぞれ160、120、58です。
-- The following list the OIDs to be used with S/MIME V3
-- 以下は、S/MIME V3と共に使用されるためにOIDsを記載します。
-- Digest Algorithms:
-- アルゴリズムを読みこなしてください:
-- md5 OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549)
-- digestAlgorithm(2) 5}
-- md5 OBJECT IDENTIFIER:、:= -- iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840)rsadsi(113549)--、digestAlgorithm(2)5
-- sha-1 OBJECT IDENTIFIER ::=
-- {iso(1) identified-organization(3) oiw(14) secsig(3)
-- algorithm(2) 26}
-- sha-1 OBJECT IDENTIFIER:、:= -- iso(1)の特定された組織(3)oiw(14) secsig(3)--、アルゴリズム(2)26
-- Asymmetric Encryption Algorithms
--
-- rsaEncryption OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
-- 1}
--
-- 非対称の暗号化アルゴリズム----rsaEncryptionオブジェクト識別子:、:= -- iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840)rsadsi(113549) pkcs(1) pkcs-1(1)--、1、--
Ramsdell Standards Track [Page 27] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[27ページ]。
-- rsa OBJECT IDENTIFIER ::=
-- {joint-iso-ccitt(2) ds(5) algorithm(8) encryptionAlgorithm(1) 1}
--
-- id-dsa OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 }
-- rsa OBJECT IDENTIFIER:、:= -- 共同iso-ccitt(2) ds(5)アルゴリズム(8)encryptionAlgorithm(1)1----イド-dsa OBJECT IDENTIFIER、:、:= -- iso(1)は(2) 私たち(840)x9-57(10040) x9cm(4)1をメンバーと同じくらい具体化させます。
-- Signature Algorithms
--
-- md2WithRSAEncryption OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
-- 2}
--
-- md5WithRSAEncryption OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
-- 4}
--
-- sha-1WithRSAEncryption OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
-- 5}
--
-- id-dsa-with-sha1 OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 3}
-- 署名アルゴリズム----md2WithRSAEncryptionオブジェクト識別子:、:= -- iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840)rsadsi(113549) pkcs(1) pkcs-1(1)--、2、--、--、md5WithRSAEncryption OBJECT IDENTIFIER:、:= -- iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840)rsadsi(113549) pkcs(1) pkcs-1(1)--、4、--、--、sha-1WithRSAEncryption OBJECT IDENTIFIER:、:= -- iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840)rsadsi(113549) pkcs(1) pkcs-1(1)--、5、----sha1 OBJECT IDENTIFIERとイドdsa:、:= -- iso(1)は(2) 私たち(840)x9-57(10040) x9cm(4)3をメンバーと同じくらい具体化させます。
-- Other Signed Attributes
--
-- signingTime OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
-- 5}
-- See [CMS] for a description of how to encode the attribute
-- value.
-- 他の署名している属性----signingTimeオブジェクト識別子:、:= -- iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840)rsadsi(113549) pkcs(1) pkcs-9(9)--、5、--どう属性をコード化するかに関する記述に関して[CMS]を見てください--値
END
終わり
Ramsdell Standards Track [Page 28] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[28ページ]。
B. References
B。 参照
[3DES] ANSI X9.52-1998, "Triple Data Encryption Algorithm
Modes of Operation", American National Standards
Institute, 1998.
[3DES]ANSI X9.52-1998、「三重のデータ暗号化アルゴリズム運転モード」、American National Standards Institut、1998。
[CERT3] Ramsdell, B., Editor, "S/MIME Version 3 Certificate
Handling", RFC 2632, June 1999.
[CERT3] Ramsdell、B.、エディタ、「S/MIMEバージョン3証明書取り扱い」、RFC2632、1999年6月。
[CHARSETS] Character sets assigned by IANA. See
<ftp://ftp.isi.edu/in-
notes/iana/assignments/character-sets>.
IANAによって割り当てられた[CHARSETS]文字集合。 <ftp://ftp.isi.edu/コネ注意/iana/課題/文字集合>を見てください。
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.
[cm] Housley、R.、「暗号のメッセージ構文」、RFC2630、1999年6月。
[CONTDISP] Troost, R., Dorner, S. and K. Moore, "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August
1997.
[CONTDISP] Troost、R.、デルナー、S.、およびK.ムーア、「中でプレゼンテーション情報を伝えて、インターネットは通信します」。 「満足している気質ヘッダーフィールド」、RFC2183、1997年8月。
[DES] ANSI X3.106, "American National Standard for
Information Systems- Data Link Encryption," American
National Standards Institute, 1983.
[デス]ANSI X3.106、「情報システムデータリンク暗号化のための米国標準規格」、American National Standards Institut、1983。
[DH] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, June 1999.
[DH] レスコラ、E.、「ディフィー-ヘルマンの主要な協定メソッド」、RFC2631、1999年6月。
[DSS] NIST FIPS PUB 186, "Digital Signature Standard", 18
May 1994.
[DSS]NIST FIPSパブ186、「デジタル署名基準」、1994年5月18日。
[ESS] Hoffman, P., Editor "Enhanced Security Services for
S/MIME", RFC 2634, June 1999.
[ESS]ホフマン、P.、「S/のための警備の強化サービスはまねる」エディタ、RFC2634、1999年6月。
[MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC
1321, April 1992.
[MD5] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。
[MIME-SPEC] The primary definition of MIME. "MIME Part 1: Format
of Internet Message Bodies", RFC 2045; "MIME Part 2:
Media Types", RFC 2046; "MIME Part 3: Message Header
Extensions for Non-ASCII Text", RFC 2047; "MIME Part
4: Registration Procedures", RFC 2048; "MIME Part 5:
Conformance Criteria and Examples", RFC 2049,
September 1993.
[MIME-SPEC] MIMEのプライマリ定義。 「第1部をまねてください」 「インターネットメッセージ本体の形式」、RFC2045。 「第2部をまねてください」 「メディアタイプ」、RFC2046。 「パート3をまねてください」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047。 「パート4をまねてください」 「登録手順」、RFC2048。 「パート5をまねてください」 「順応評価基準と例」、RFC2049、9月1993日
[MIME-SECURE] Galvin, J., Murphy, S., Crocker, S. and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995.
[MIME安全な] ガルビン、J.、マーフィー、S.、クロッカー、S.、および解放されたN.、「MIMEのためのセキュリティMultiparts:」 「署名していて複合の/が暗号化した複合/」、RFC1847、1995年10月。
Ramsdell Standards Track [Page 29] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[29ページ]。
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP14, RFC 2119, March 1997.
[MUSTSHOULD] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[PKCS-1] Kaliski, B., "PKCS #1: RSA Encryption Version 2.0",
RFC 2437, October 1998.
[PKCS-1]Kaliski、B.、「PKCS#1:」 RSA、暗号化バージョン2インチ、RFC2437、10月1998日
[PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
Version 1.5", RFC 2315, March 1998.
[PKCS-7]Kaliski、B.、「PKCS#7:」 暗号のメッセージ構文バージョン1.5インチ、RFC2315、1998年3月。
[RANDOM] Eastlake, 3rd, D., Crocker, S. and J. Schiller,
"Randomness Recommendations for Security", RFC 1750,
December 1994.
[無作為の] イーストレークと3番目とD.とクロッカーとS.とJ.シラー、「セキュリティのための偶発性推薦」、RFC1750、1994年12月。
[RC2] Rivest, R., "A Description of the RC2 (r) Encryption
Algorithm", RFC 2268, January 1998.
[RC2] Rivest、R.、「RC2(r)暗号化アルゴリズムの記述」、RFC2268、1998年1月。
[SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National
Institute of Standards and Technology, U.S. Department
of Commerce, DRAFT, 31May 1994.
[SHA1]NIST FIPSパブ180-1、米国商務省標準技術局、米国商務省は「安全なハッシュ規格」と作成します、31May1994。
[SMIMEV2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L.
and L. Repka, "S/MIME Version 2 Message
Specification", RFC 2311, March 1998.
[SMIMEV2] DusseとS.とホフマンとP.とRamsdellとB.とLundbladeとL.とL.Repka、「S/MIMEバージョン2メッセージ仕様」、RFC2311、1998年3月。
Ramsdell Standards Track [Page 30] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[30ページ]。
C. Acknowledgements
C。 承認
Many thanks go out to the other authors of the S/MIME Version 2 Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence Lundblade and Lisa Repka. Without v2, there wouldn't be a v3.
許可していた状態で、S/MIMEバージョン2Message Specification RFCの他の作者への外でありがとうございます: スティーブDusse、ポール・ホフマン、ローレンスLundblade、およびリサRepka。 v2がなければ、v3がないでしょう。
A number of the members of the S/MIME Working Group have also worked very hard and contributed to this document. Any list of people is doomed to omission, and for that I apologize. In alphabetical order, the following people stand out in my mind due to the fact that they made direct contributions to this document.
S/MIME作業部会の多くのメンバーが、また、一生懸命仕事して、このドキュメントに貢献しました。 人々のどんなリストも省略に運命づけられます、そして、それを、私は謝ります。 彼らが直接的な貢献をこのドキュメントにしたという事実のため、アルファベット順に、以下の人々は私の心で際立っています。
Dave Crocker Bill Flanigan Paul Hoffman Russ Housley John Pawling Jim Schaad
デーヴ医者ビルフラニガンポールホフマンラスHousleyジョンPawlingジムSchaad
Editor's Address
エディタのアドレス
Blake Ramsdell Worldtalk 17720 NE 65th St Ste 201 Redmond, WA 98052
ワシントン Ste201レッドモンド、ブレークRamsdell Worldtalk17720のNeの第65通り98052
Phone: +1 425 376 0225 EMail: blaker@deming.com
以下に電話をしてください。 +1 0225年の425 376メール: blaker@deming.com
Ramsdell Standards Track [Page 31] RFC 2633 S/MIME Version 3 Message Specification June 1999
Ramsdell規格はメッセージ仕様1999年6月にRFCの2633秒間/MIMEのバージョン3を追跡します[31ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Ramsdell Standards Track [Page 32]
Ramsdell標準化過程[32ページ]
一覧
スポンサーリンク
