[要約] RFC 8591は、S/MIMEを使用したSIPベースのメッセージングに関する仕様です。このRFCの目的は、SIPセッションにおけるセキュアなメッセージングを実現するための手法を提供することです。
Internet Engineering Task Force (IETF) B. Campbell
Request for Comments: 8591 Standard Velocity
Updates: 3261, 3428, 4975 R. Housley
Category: Standards Track Vigil Security
ISSN: 2070-1721 April 2019
SIP-Based Messaging with S/MIME
S / MIMEを使用したSIPベースのメッセージング
Abstract
概要
Mobile messaging applications used with the Session Initiation Protocol (SIP) commonly use some combination of the SIP MESSAGE method and the Message Session Relay Protocol (MSRP). While these provide mechanisms for hop-by-hop security, neither natively provides end-to-end protection. This document offers guidance on how to provide end-to-end authentication, integrity protection, and confidentiality using the Secure/Multipurpose Internet Mail Extensions (S/MIME). It updates and provides clarifications for RFCs 3261, 3428, and 4975.
セッション開始プロトコル（SIP）で使用されるモバイルメッセージングアプリケーションは、通常、SIP MESSAGEメソッドとメッセージセッションリレープロトコル（MSRP）のいくつかの組み合わせを使用します。これらはホップバイホップのセキュリティのためのメカニズムを提供しますが、どちらもネイティブでエンドツーエンドの保護を提供しません。このドキュメントでは、Secure / Multipurpose Internet Mail Extensions（S / MIME）を使用してエンドツーエンドの認証、整合性保護、および機密性を提供する方法についてのガイダンスを提供します。 RFC 3261、3428、および4975の更新と説明を提供します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8591.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8591で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement and Scope . . . . . . . . . . . . . . . . . 5
4. Applicability of S/MIME . . . . . . . . . . . . . . . . . . . 6
4.1. Signed Messages . . . . . . . . . . . . . . . . . . . . . 6
4.2. Encrypted Messages . . . . . . . . . . . . . . . . . . . 7
4.3. Signed and Encrypted Messages . . . . . . . . . . . . . . 9
4.4. Certificate Handling . . . . . . . . . . . . . . . . . . 9
4.4.1. Subject Alternative Name . . . . . . . . . . . . . . 9
4.4.2. Certificate Validation . . . . . . . . . . . . . . . 9
5. Transfer Encoding . . . . . . . . . . . . . . . . . . . . . . 9
6. User Agent Capabilities . . . . . . . . . . . . . . . . . . . 10
7. Using S/MIME with the SIP MESSAGE Method . . . . . . . . . . 11
7.1. Size Limit . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. SIP User Agent Capabilities . . . . . . . . . . . . . . . 11
7.3. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 12
8. Using S/MIME with MSRP . . . . . . . . . . . . . . . . . . . 12
8.1. Chunking . . . . . . . . . . . . . . . . . . . . . . . . 12
8.2. Streamed Data . . . . . . . . . . . . . . . . . . . . . . 13
8.3. Indicating Support for S/MIME . . . . . . . . . . . . . . 14
8.4. MSRP URIs . . . . . . . . . . . . . . . . . . . . . . . . 14
8.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 15
9. S/MIME Interaction with Other SIP Messaging Features . . . . 15
9.1. Common Profile for Instant Messaging . . . . . . . . . . 15
9.2. Instant Message Disposition Notifications . . . . . . . . 16
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Signed Message in SIP including the Sender's Certificate 17
10.2. Signed Message in SIP with No Certificate . . . . . . . 19
10.3. MSRP Signed and Encrypted Message in a Single Chunk . . 20
10.4. MSRP Signed and Encrypted Message Sent in Multiple
Chunks . . . . . . . . . . . . . . . . . . . . . . . . . 21
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
12. Security Considerations . . . . . . . . . . . . . . . . . . . 23
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
13.1. Normative References . . . . . . . . . . . . . . . . . . 25
13.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Message Details . . . . . . . . . . . . . . . . . . 30
A.1. Signed Message . . . . . . . . . . . . . . . . . . . . . 30
A.2. Short Signed Message . . . . . . . . . . . . . . . . . . 32
A.3. Signed and Encrypted Message . . . . . . . . . . . . . . 33
A.3.1. Signed Message prior to Encryption . . . . . . . . . 33
A.3.2. Encrypted Message . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
Several mobile messaging systems use the Session Initiation Protocol (SIP) [RFC3261], typically as some combination of the SIP MESSAGE method [RFC3428] and the Message Session Relay Protocol (MSRP) [RFC4975]. For example, Voice over LTE (VoLTE) uses the SIP MESSAGE method to send Short Message Service (SMS) messages. The Open Mobile Alliance (OMA) Converged IP Messaging (CPM) system [CPM] uses the SIP MESSAGE method for short "pager mode" messages and uses MSRP for large messages and for sessions of messages. The Global System for Mobile Communications Association (GSMA) Rich Communication Services (RCS) uses CPM for messaging [RCS].
いくつかのモバイルメッセージングシステムは、通常、SIP MESSAGEメソッド[RFC3428]とメッセージセッションリレープロトコル（MSRP）[RFC4975]のいくつかの組み合わせとして、セッション開始プロトコル（SIP）[RFC3261]を使用します。たとえば、Voice over LTE（VoLTE）はSIP MESSAGEメソッドを使用してショートメッセージサービス（SMS）メッセージを送信します。 Open Mobile Alliance（OMA）コンバージドIPメッセージング（CPM）システム[CPM]は、短い「ページャーモード」メッセージにはSIP MESSAGEメソッドを使用し、大きなメッセージとメッセージのセッションにはMSRPを使用します。モバイル通信協会（GSMA）リッチコミュニケーションサービス（RCS）のグローバルシステムは、メッセージングにCPMを使用します[RCS]。
At the same time, organizations increasingly depend on mobile messaging systems to send notifications to their customers. Many of these notifications are security sensitive. For example, such notifications are commonly used for notice of financial transactions, notice of login or password change attempts, and the sending of two-factor authentication codes.
同時に、組織は顧客に通知を送信するためにモバイルメッセージングシステムにますます依存しています。これらの通知の多くはセキュリティ上重要です。たとえば、このような通知は通常、金融取引の通知、ログインまたはパスワードの変更試行の通知、および2要素認証コードの送信に使用されます。
Both SIP and MSRP can be used to transport any content using Multipurpose Internet Mail Extensions (MIME) formats. The SIP MESSAGE method is typically limited to short messages (under 1300 octets for the MESSAGE request). MSRP can carry arbitrarily large messages and can break large messages into chunks.
SIPとMSRPの両方を使用して、MIME（Multipurpose Internet Mail Extensions）形式でコンテンツを転送できます。 SIP MESSAGEメソッドは通常、短いメッセージ（MESSAGEリクエストの場合は1300オクテット未満）に制限されます。 MSRPは任意の大きなメッセージを運ぶことができ、大きなメッセージをチャンクに分割できます。
While both SIP and MSRP provide mechanisms for hop-by-hop security, neither provides native end-to-end protection. Instead, they depend on S/MIME [RFC8550] [RFC8551]. However, at the time of this writing, S/MIME is not in common use for SIP-based and MSRP-based messaging services. This document updates and clarifies RFCs 3261, 3428, and 4975 in an attempt to make S/MIME for SIP and MSRP easier to implement and deploy in an interoperable fashion.
SIPとMSRPの両方がホップバイホップセキュリティのメカニズムを提供しますが、どちらもネイティブのエンドツーエンド保護を提供しません。代わりに、S / MIME [RFC8550] [RFC8551]に依存しています。ただし、この記事の執筆時点では、S / MIMEはSIPベースおよびMSRPベースのメッセージングサービスでは一般的に使用されていません。このドキュメントは、SIPおよびMSRPのS / MIMEを相互運用可能な方法で実装および展開しやすくするために、RFC 3261、3428、および4975を更新および明確化します。
This document updates RFCs 3261, 3428, and 4975 to update the cryptographic algorithm recommendations and the handling of S/MIME data objects. It updates RFC 3261 to allow S/MIME signed messages to be sent without embedded certificates in some situations. Finally, it updates RFCs 3261, 3428, and 4975 to clarify error-reporting requirements for certain situations.
このドキュメントでは、RFC 3261、3428、4975を更新して、暗号アルゴリズムの推奨事項とS / MIMEデータオブジェクトの処理を更新しています。 RFC 3261を更新して、一部の状況でS / MIME署名付きメッセージを埋め込み証明書なしで送信できるようにします。最後に、RFC 3261、3428、および4975を更新して、特定の状況のエラー報告要件を明確にします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This document discusses the use of S/MIME with SIP-based messaging. Other standardized messaging protocols exist, such as the Extensible Messaging and Presence Protocol (XMPP) [RFC6121]. Likewise, other end-to-end protection formats exist, such as JSON Web Signatures [RFC7515] and JSON Web Encryption [RFC7516].
このドキュメントでは、SIPベースのメッセージングでのS / MIMEの使用について説明します。 Extensible Messaging and Presence Protocol（XMPP）[RFC6121]など、他の標準化されたメッセージングプロトコルが存在します。同様に、JSON Web Signatures [RFC7515]やJSON Web Encryption [RFC7516]などの他のエンドツーエンドの保護形式が存在します。
This document focuses on SIP-based messaging because its use is becoming more common in mobile environments. It focuses on S/MIME, since several mobile operating systems already have S/MIME libraries installed. While there may also be value in specifying end-to-end security for other messaging and security mechanisms, it is out of scope for this document.
このドキュメントでは、モバイル環境での使用が一般的になっているため、SIPベースのメッセージングに焦点を当てています。いくつかのモバイルオペレーティングシステムにはすでにS / MIMEライブラリがインストールされているため、S / MIMEに重点を置いています。他のメッセージングおよびセキュリティメカニズムにエンドツーエンドのセキュリティを指定することにも価値があるかもしれませんが、それはこのドキュメントの範囲外です。
MSRP sessions are negotiated using the Session Description Protocol (SDP) [RFC4566] offer/answer mechanism [RFC3264] or similar mechanisms. This document assumes that SIP is used for the offer/answer exchange. However, the techniques should be adaptable to other signaling protocols.
MSRPセッションは、Session Description Protocol（SDP）[RFC4566]オファー/アンサーメカニズム[RFC3264]または同様のメカニズムを使用してネゴシエートされます。このドキュメントでは、オファー/アンサー交換にSIPが使用されていることを前提としています。ただし、この技術は他の信号プロトコルに適応可能でなければなりません。
[RFC3261], [RFC3428], and [RFC4975] already describe the use of S/MIME. [RFC3853] updates SIP to support the Advanced Encryption Standard (AES). In aggregate, that guidance is incomplete, contains inconsistencies, and is still out of date in terms of supported and recommended algorithms.
[RFC3261]、[RFC3428]、および[RFC4975]は、S / MIMEの使用についてすでに説明しています。 [RFC3853]はSIPを更新してAdvanced Encryption Standard（AES）をサポートします。全体として、そのガイダンスは不完全であり、不整合が含まれており、サポートされている推奨アルゴリズムに関してはまだ古くなっています。
The guidance in RFC 3261 is based on an implicit assumption that S/MIME is being used to secure signaling applications. That advice is not entirely appropriate for messaging applications. For example, it assumes that message decryption always happens before the SIP transaction completes.
RFC 3261のガイダンスは、S / MIMEがシグナリングアプリケーションのセキュリティ保護に使用されているという暗黙の前提に基づいています。そのアドバイスは、メッセージングアプリケーションに完全に適しているわけではありません。たとえば、SIPトランザクションが完了する前にメッセージの復号化が常に発生すると想定しています。
This document offers normative updates and clarifications to the use of S/MIME with the SIP MESSAGE method and MSRP. It does not attempt to define a complete secure messaging system. Such a system would require considerable work around user enrollment, certificate and key generation and management, multi-party chats, device management, etc. While nothing herein should preclude those efforts, they are out of scope for this document.
このドキュメントでは、SIP MESSAGEメソッドとMSRPでのS / MIMEの使用に関する規範的な更新と説明を提供します。完全な安全なメッセージングシステムを定義しようとするものではありません。このようなシステムでは、ユーザーの登録、証明書とキーの生成と管理、マルチパーティチャット、デバイス管理などに関してかなりの作業が必要になります。ここではそれらの取り組みを妨げるものはありませんが、このドキュメントの範囲外です。
This document primarily covers the sending of single messages -- for example, "pager-mode messages" sent using the SIP MESSAGE method and "large messages" sent in MSRP. Techniques to use a common signing or encryption key across a session of messages are out of scope for this document.
このドキュメントでは主に、SIP MESSAGEメソッドを使用して送信される「ページャーモードメッセージ」やMSRPで送信される「大きなメッセージ」などの単一メッセージの送信について説明します。メッセージのセッション全体で共通の署名または暗号化キーを使用する手法は、このドキュメントの範囲外です。
Cryptographic algorithm requirements in this document are intended to supplement those already specified for SIP and MSRP.
このドキュメントの暗号化アルゴリズムの要件は、SIPおよびMSRPですでに指定されているものを補足することを目的としています。
The Cryptographic Message Syntax (CMS) [RFC5652] is an encapsulation syntax that is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. The CMS supports a variety of architectures for certificate-based key management, especially the one defined by the IETF PKIX (Public Key Infrastructure using X.509) Working Group [RFC5280]. The CMS values are generated using ASN.1 [X680], using the Basic Encoding Rules (BER) and Distinguished Encoding Rules (DER) [X690].
暗号化メッセージ構文（CMS）[RFC5652]は、任意のメッセージコンテンツのデジタル署名、ダイジェスト、認証、または暗号化に使用されるカプセル化構文です。 CMSは、証明書ベースのキー管理のためのさまざまなアーキテクチャ、特にIETF PKIX（X.509を使用した公開キーインフラストラクチャ）ワーキンググループ[RFC5280]によって定義されたものをサポートしています。 CMS値は、ASN.1 [X680]を使用して、基本エンコーディングルール（BER）およびDistinguished Encodingルール（DER）[X690]を使用して生成されます。
The S/MIME Message Specification [RFC8551] defines MIME body parts based on the CMS. In this document, the application/pkcs7-mime media type is used to digitally sign an encapsulated body part, and it is also used to encrypt an encapsulated body part.
S / MIMEメッセージ仕様[RFC8551]は、CMSに基づいてMIMEボディパーツを定義しています。このドキュメントでは、application / pkcs7-mimeメディアタイプは、カプセル化されたボディパーツにデジタル署名するために使用され、カプセル化されたボディパーツを暗号化するためにも使用されます。
While both SIP and MSRP require support for the multipart/signed format, the use of application/pkcs7-mime is RECOMMENDED for most signed messages. Experience with the use of S/MIME in electronic mail has shown that multipart/signed bodies are at greater risk of "helpful" tampering by intermediaries, a common cause of signature validation failure. This risk is also present for messaging applications; for example, intermediaries might insert Instant Message Disposition Notification (IMDN) requests [RFC5438] into messages. (See Section 9.2.) The application/pkcs7-mime format is also more compact, which can be important for messaging applications, especially when using the SIP MESSAGE method. (See Section 7.1.) The use of multipart/signed may still make sense if the message needs to be readable by receiving agents that do not support S/MIME.
SIPとMSRPの両方でmultipart / signed形式のサポートが必要ですが、ほとんどの署名付きメッセージではapplication / pkcs7-mimeの使用をお勧めします。電子メールでS / MIMEを使用した経験から、マルチパート/署名済みの本文には、署名検証の失敗の一般的な原因である仲介者による「役立つ」改ざんのリスクが高いことが示されています。このリスクは、メッセージングアプリケーションにも存在します。たとえば、仲介者はインスタントメッセージ処理通知（IMDN）リクエスト[RFC5438]をメッセージに挿入する場合があります。 （セクション9.2を参照してください。）application / pkcs7-mime形式もよりコンパクトになり、メッセージングアプリケーション、特にSIP MESSAGEメソッドを使用する場合に重要になる場合があります。 （セクション7.1を参照。）S / MIMEをサポートしていない受信エージェントがメッセージを読み取る必要がある場合は、multipart / signedを使用しても意味があります。
When generating a signed message, sending User Agents (UAs) SHOULD follow the conventions specified in [RFC8551] for the application/pkcs7-mime media type with smime-type=signed-data. When validating a signed message, receiving UAs MUST follow the conventions specified in [RFC8551] for the application/pkcs7-mime media type with smime-type=signed-data.
署名付きメッセージを生成する場合、送信ユーザーエージェント（UA）は、smime-type = signed-dataを使用したapplication / pkcs7-mimeメディアタイプについて、[RFC8551]で指定された規則に従う必要があります（SHOULD）。署名されたメッセージを検証するとき、受信UAは、smime-type = signed-dataを含むapplication / pkcs7-mimeメディアタイプについて、[RFC8551]で指定された規則に従う必要があります。
Sending and receiving UAs MUST support the SHA-256 message digest algorithm [RFC5754]. For convenience, the SHA-256 algorithm identifier is repeated here:
UAの送受信は、SHA-256メッセージダイジェストアルゴリズム[RFC5754]をサポートする必要があります。便宜上、SHA-256アルゴリズム識別子はここで繰り返されます。
id-sha256 OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 1 }
Sending and receiving UAs MAY support other message digest algorithms.
UAの送受信は、他のメッセージダイジェストアルゴリズムをサポートする場合があります。
Sending and receiving UAs MUST support the Elliptic Curve Digital Signature Algorithm (ECDSA) using the NIST P-256 elliptic curve and the SHA-256 message digest algorithm [RFC5480] [RFC5753]. Sending and receiving UAs SHOULD support the Edwards-curve Digital Signature Algorithm (EdDSA) with curve25519 (Ed25519) [RFC8032] [RFC8419]. For convenience, the ECDSA with SHA-256 algorithm identifier, the object identifier for the well-known NIST P-256 elliptic curve, and the Ed25519 algorithm identifier are repeated here:
送受信UAは、NIST P-256楕円曲線とSHA-256メッセージダイジェストアルゴリズム[RFC5480] [RFC5753]を使用して、楕円曲線デジタル署名アルゴリズム（ECDSA）をサポートする必要があります。 UAの送受信は、curve25519（Ed25519）[RFC8032] [RFC8419]でEdwards-curveデジタル署名アルゴリズム（EdDSA）をサポートする必要があります（SHOULD）。便宜上、SHA-256アルゴリズム識別子付きのECDSA、既知のNIST P-256楕円曲線のオブジェクト識別子、およびEd25519アルゴリズム識別子をここで繰り返します。
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
ecdsa-with-SHA2(3) 2 }
-- Note: The NIST P-256 elliptic curve is also known as secp256r1.
-注：NIST P-256楕円曲線は、secp256r1とも呼ばれます。
secp256r1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3)
prime(1) 7 }
id-Ed25519 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) thawte(101) 112 }
When generating an encrypted message, sending UAs MUST follow the conventions specified in [RFC8551] for the application/pkcs7-mime media type with smime-type=auth-enveloped-data. When decrypting a received message, receiving UAs MUST follow the conventions specified in [RFC8551] for the application/pkcs7-mime media type with smime-type=auth-enveloped-data.
暗号化されたメッセージを生成するとき、UAの送信は、smime-type = auth-enveloped-dataを使用したapplication / pkcs7-mimeメディアタイプについて、[RFC8551]で指定された規則に従う必要があります。受信したメッセージを解読するとき、受信UAは、smime-type = auth-enveloped-dataを使用したapplication / pkcs7-mimeメディアタイプの[RFC8551]で指定された規則に従う必要があります。
Sending and receiving UAs MUST support the AES-128-GCM algorithm for content encryption [RFC5084]. For convenience, the AES-128-GCM algorithm identifier is repeated here:
UAの送受信は、コンテンツ暗号化のためのAES-128-GCMアルゴリズムをサポートする必要があります[RFC5084]。便宜上、AES-128-GCMアルゴリズム識別子をここで繰り返します。
id-aes128-GCM OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistAlgorithm(4) aes(1) 6 }
Sending and receiving UAs MAY support other content-authenticated encryption algorithms.
UAの送受信は、他のコンテンツ認証された暗号化アルゴリズムをサポートする場合があります。
Sending and receiving UAs MUST support the AES-128-WRAP algorithm for encryption of one AES key with another AES key [RFC3565]. For convenience, the AES-128-WRAP algorithm identifier is repeated here:
UAの送受信は、あるAESキーを別のAESキーで暗号化するためのAES-128-WRAPアルゴリズムをサポートする必要があります[RFC3565]。便宜上、AES-128-WRAPアルゴリズム識別子をここで繰り返します。
id-aes128-wrap OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistAlgorithm(4) aes(1) 5 }
Sending and receiving UAs MAY support other key-encryption algorithms.
UAの送受信は、他のキー暗号化アルゴリズムをサポートする場合があります。
Symmetric key-encryption keys can be distributed before messages are sent. If sending and receiving UAs support previously distributed key-encryption keys, then they MUST assign a KEKIdentifier [RFC5652] to the previously distributed symmetric key.
対称鍵暗号鍵は、メッセージが送信される前に配布できます。送受信UAが以前に配布されたキー暗号化キーをサポートする場合、それらは以前に配布された対称キーにKEKIdentifier [RFC5652]を割り当てなければなりません（MUST）。
Alternatively, a key agreement algorithm can be used to establish a single-use key-encryption key. If sending and receiving UAs support key agreement, then they MUST support the Elliptic Curve Diffie-Hellman (ECDH) algorithm using the NIST P-256 elliptic curve and the ANSI-X9.63-KDF key derivation function with the SHA-256 message digest algorithm [RFC5753]. If sending and receiving UAs support key agreement, then they SHOULD support the ECDH algorithm using curve25519 (X25519) [RFC7748] [RFC8418]. For convenience, (1) the identifier for the ECDH algorithm using the ANSI-X9.63-KDF with the SHA-256 algorithm and (2) the identifier for the X25519 algorithm are repeated here:
または、キー合意アルゴリズムを使用して、使い捨てのキー暗号化キーを確立することもできます。送受信UAが鍵合意をサポートしている場合、NIST P-256楕円曲線とSHA-256メッセージダイジェストでのANSI-X9.63-KDF鍵導出関数を使用して、楕円曲線Diffie-Hellman（ECDH）アルゴリズムをサポートする必要があります。アルゴリズム[RFC5753]。送受信UAが鍵合意をサポートする場合、curve25519（X25519）[RFC7748] [RFC8418]を使用するECDHアルゴリズムをサポートする必要があります（SHOULD）。便宜上、（1）SHA-256アルゴリズムでANSI-X9.63-KDFを使用するECDHアルゴリズムの識別子、および（2）X25519アルゴリズムの識別子をここで繰り返します。
dhSinglePass-stdDH-sha256kdf-scheme OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132)
schemes(1) 11 1 }
id-X25519 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) thawte(101) 110 }
RFC 3261, Section 23.2 says that when a User Agent Client (UAC) sends signed and encrypted data, it "SHOULD" send an EnvelopedData object encapsulated within a SignedData message. That essentially says that one should encrypt first, then sign. This document updates RFC 3261 to say that, when sending signed and encrypted user content in a SIP MESSAGE request, the sending UAs MUST sign the message first, and then encrypt it. That is, it must send the SignedData object inside an AuthEnvelopedData object. For interoperability reasons, recipients SHOULD accept messages signed and encrypted in either order.
RFC 3261のセクション23.2では、ユーザーエージェントクライアント（UAC）が署名および暗号化されたデータを送信するとき、SignedDataメッセージ内にカプセル化されたEnvelopedDataオブジェクトを送信する必要があると「SHOULD」している。つまり、最初に暗号化してから署名する必要があるということです。このドキュメントはRFC 3261を更新し、SIP MESSAGEリクエストで署名および暗号化されたユーザーコンテンツを送信する場合、送信側UAは最初にメッセージに署名してから暗号化する必要があると述べています。つまり、AuthEnvelopedDataオブジェクト内でSignedDataオブジェクトを送信する必要があります。相互運用性の理由から、受信者は、署名および暗号化されたメッセージをいずれかの順序で受け入れる必要があります。
Sending and receiving UAs MUST follow the S/MIME certificate-handling procedures [RFC8550], with a few exceptions detailed below.
UAの送受信は、S / MIME証明書処理手順[RFC8550]に従う必要がありますが、以下にいくつかの例外があります。
In both SIP and MSRP, the identity of the sender of a message is typically expressed as a SIP URI.
SIPとMSRPの両方で、メッセージの送信者のIDは通常、SIP URIとして表現されます。
The subject alternative name extension is used as the preferred means to convey the SIP URI of the subject of a certificate. Any SIP URI present MUST be encoded using the uniformResourceIdentifier CHOICE of the GeneralName type as described in [RFC5280], Section 4.2.1.6. Since the SubjectAltName type is a SEQUENCE OF GeneralName, multiple URIs MAY be present.
サブジェクトの別名の拡張子は、証明書のサブジェクトのSIP URIを伝えるための推奨手段として使用されます。 [RFC5280]のセクション4.2.1.6で説明されているように、存在するSIP URIはGeneralNameタイプのuniformResourceIdentifier CHOICEを使用してエンコードする必要があります。 SubjectAltNameタイプはGeneralNameのシーケンスであるため、複数のURIが存在する場合があります。
Other methods of identifying a certificate subject MAY be used.
証明書のサブジェクトを識別する他の方法が使用される場合があります。
When validating a certificate, receiving UAs MUST support the ECDSA using the NIST P-256 elliptic curve and the SHA-256 message digest algorithm [RFC5480].
証明書を検証するとき、受信UAは、NIST P-256楕円曲線とSHA-256メッセージダイジェストアルゴリズム[RFC5480]を使用してECDSAをサポートする必要があります。
Sending and receiving UAs MAY support other digital signature algorithms for certificate validation.
UAの送受信は、証明書の検証のために他のデジタル署名アルゴリズムをサポートする場合があります。
SIP and MSRP UAs are always capable of receiving binary data. Inner S/MIME entities do not require base64 encoding [RFC4648].
SIPおよびMSRP UAは、常にバイナリデータを受信できます。内部S / MIMEエンティティは、base64エンコードを必要としません[RFC4648]。
Both SIP and MSRP provide 8-bit safe transport channels; base64 encoding is not generally needed for the outer S/MIME entities.
SIPとMSRPはどちらも8ビットの安全なトランスポートチャネルを提供します。通常、外側のS / MIMEエンティティにはbase64エンコーディングは必要ありません。
However, if there is a chance a message might cross a 7-bit transport (for example, gateways that convert to a 7-bit transport for intermediate transfer), base64 encoding may be needed for the outer entity.
ただし、メッセージが7ビットトランスポート（たとえば、中間転送のために7ビットトランスポートに変換するゲートウェイ）を通過する可能性がある場合は、外部エンティティにbase64エンコーディングが必要になることがあります。
Messaging UAs may implement a subset of S/MIME capabilities. Even when implemented, some features may not be available due to configuration. For example, UAs that do not have user certificates cannot sign messages on behalf of the user or decrypt encrypted messages sent to the user. At a minimum, a UA that supports S/MIME MUST be able to validate a signed message.
メッセージングUAは、S / MIME機能のサブセットを実装できます。実装した場合でも、構成によっては一部の機能を使用できない場合があります。たとえば、ユーザー証明書を持たないUAは、ユーザーに代わってメッセージに署名したり、ユーザーに送信された暗号化されたメッセージを復号化したりできません。少なくとも、S / MIMEをサポートするUAは、署名されたメッセージを検証できる必要があります。
End-user certificates have long been a barrier to large-scale S/MIME deployment. But since UAs can validate signatures even without local certificates, the use case of organizations sending secure notifications to their users becomes a sort of "low-hanging fruit". That being said, the signed-notification use case still requires shared trust anchors.
エンドユーザー証明書は、大規模なS / MIME展開の障害となってきました。しかし、UAはローカル証明書がなくても署名を検証できるため、ユーザーに安全な通知を送信する組織の使用例は、一種の「簡単な実り」になります。そうは言っても、署名付き通知のユースケースでは、共有トラストアンカーが必要です。
SIP and MSRP UAs advertise their level of support for S/MIME by indicating their capability to receive the "application/pkcs7-mime" media type.
SIPおよびMSRP UAは、「application / pkcs7-mime」メディアタイプを受信する機能を示すことにより、S / MIMEのサポートレベルを通知します。
The fact that a UA indicates support for the "multipart/signed" media type does not necessarily imply support for S/MIME. The UA might just be able to display clear-signed content without validating the signature. UAs that wish to indicate the ability to validate signatures for clear-signed messages MUST also indicate support for "application/pkcs7-signature".
UAが "multipart / signed"メディアタイプのサポートを示すという事実は、必ずしもS / MIMEのサポートを意味するわけではありません。 UAは、署名を検証せずに、クリア署名されたコンテンツを表示できる場合があります。クリア署名付きメッセージの署名を検証する機能を示すことを望むUAは、「application / pkcs7-signature」のサポートも示す必要があります。
A UA can indicate that it can receive all smime-types by advertising "application/pkcs7-mime" with no parameters. If a UA does not accept all smime-types, it advertises the media type with the appropriate parameters. If more than one smime-type is supported, the UA includes a separate instance of the media-type string, appropriately parameterized, for each.
UAは、「application / pkcs7-mime」をパラメーターなしでアドバタイズすることにより、すべてのスミームタイプを受信できることを示すことができます。 UAがすべてのsmimeタイプを受け入れない場合、UAは適切なパラメーターを使用してメディアタイプを通知します。複数のsmime-typeがサポートされている場合、UAには、適切にパラメーター化された、メディアタイプ文字列の個別のインスタンスがそれぞれに含まれます。
For example, a UA that can only receive signed-data would advertise "application/pkcs7-mime; smime-type=signed-data".
たとえば、署名されたデータのみを受信できるUAは、「application / pkcs7-mime; smime-type = signed-data」をアドバタイズします。
SIP signaling can fork to multiple destinations for a given Address of Record (AoR). A user might have multiple UAs with different capabilities; the capabilities remembered from an interaction with one such UA might not apply to another. (See Section 7.2.)
SIPシグナリングは、指定されたAddress of Record（AoR）の複数の宛先に分岐できます。ユーザーには、異なる機能を持つ複数のUAがある場合があります。そのようなUAとの対話から記憶された機能は、別のUAには適用されない場合があります。 （セクション7.2を参照。）
UAs can also advertise or discover S/MIME using out-of-band mechanisms. Such mechanisms are beyond the scope of this document.
UAは、アウトオブバンドメカニズムを使用してS / MIMEをアドバタイズまたは検出することもできます。このようなメカニズムは、このドキュメントの範囲を超えています。
The use of S/MIME with the SIP MESSAGE method is described in Section 11.3 of [RFC3428], and for SIP in general in Section 23 of [RFC3261]. This section and its child sections offer clarifications for the use of S/MIME with the SIP MESSAGE method, along with related updates to RFCs 3261 and 3428.
SIP MESSAGEメソッドでのS / MIMEの使用については、[RFC3428]のセクション11.3で説明されており、SIPについては一般に[RFC3261]のセクション23で説明されています。このセクションとその子セクションでは、SIP MESSAGEメソッドでのS / MIMEの使用に関する説明と、RFC 3261および3428への関連する更新を提供します。
SIP MESSAGE requests are typically limited to 1300 octets. That limit applies to the entire message, including both SIP header fields and the message content. This is due to the potential for fragmentation of larger requests sent over UDP. In general, it is hard to be sure that no proxy or other intermediary will forward a SIP request over UDP somewhere along the path. Therefore, S/MIME messages sent using the SIP MESSAGE method should be kept as small as possible. Messages that will not fit within the limit can be sent using MSRP.
SIP MESSAGEリクエストは通常1300オクテットに制限されています。この制限は、SIPヘッダーフィールドとメッセージコンテンツの両方を含むメッセージ全体に適用されます。これは、UDPを介して送信されるより大きなリクエストの断片化の可能性があるためです。一般に、プロキシやその他の仲介者が、パスに沿ったどこかでUDPを介してSIPリクエストを転送しないことを確認するのは困難です。したがって、SIP MESSAGEメソッドを使用して送信されるS / MIMEメッセージは、できるだけ小さくする必要があります。制限内に収まらないメッセージは、MSRPを使用して送信できます。
Section 23.2 of [RFC3261] requires that a SignedData message contain a certificate to be used to validate the signature. In order to reduce the message size, this document updates that text to say that a SignedData message sent in a SIP MESSAGE request SHOULD contain the certificate but MAY omit it if the sender has reason to believe that the recipient (1) already has the certificate in its keychain or (2) has some other method of accessing the certificate.
[RFC3261]のセクション23.2では、SignedDataメッセージに、署名の検証に使用する証明書が含まれている必要があります。メッセージのサイズを小さくするために、このドキュメントはそのテキストを更新して、SIP MESSAGEリクエストで送信されたSignedDataメッセージに証明書が含まれる必要があることを伝えますが、送信者が受信者（1）がすでに証明書を持っていると信じる理由がある場合は省略しても構いませんキーチェーンまたは（2）には、証明書にアクセスする他の方法があります。
SIP UAs can theoretically indicate support for S/MIME by including the appropriate media type or types in the SIP Accept header field in a response to an OPTIONS request, or in a 415 (Unsupported Media Type) response to a SIP request that contained an unsupported media type in the body. Unfortunately, this approach may not be reliable in the general case. In the case where a downstream SIP proxy forks an OPTIONS or other non-INVITE request to multiple User Agent Servers (UASs), that proxy will only forward the "best" response. If the recipient has multiple devices, the sender may only learn the capabilities of the device that sent the forwarded response. Blindly trusting this information could result in S/MIME messages being sent to UAs that do not support it, which would be at best confusing and at worst misleading to the recipient.
SIP UAは理論的には、OPTIONS要求への応答のSIP Acceptヘッダーフィールドに、またはサポートされていないSIP要求への415（Unsupported Media Type）応答に適切なメディアタイプを含めることにより、S / MIMEのサポートを示すことができます。本文のメディアタイプ。残念ながら、このアプローチは一般的なケースでは信頼できない場合があります。ダウンストリームSIPプロキシが複数のユーザーエージェントサーバー（UAS）へのOPTIONSまたは他の非INVITE要求をフォークする場合、そのプロキシは「最良の」応答のみを転送します。受信者が複数のデバイスを持っている場合、送信者は転送された応答を送信したデバイスの機能のみを学習できます。この情報を盲目的に信頼すると、S / MIMEメッセージがそれをサポートしていないUAに送信される可能性があり、混乱を招き、最悪の場合は受信者を誤解させる可能性があります。
UAs might be able to use the UA capabilities framework [RFC3840] to indicate support. However, doing so would require the registration of one or more media feature tags with IANA.
UAは、UA機能フレームワーク[RFC3840]を使用してサポートを示すことができる場合があります。ただし、そのためには、1つ以上のメディア機能タグをIANAに登録する必要があります。
UAs MAY use other out-of-band methods to indicate their level of support for S/MIME.
UAは他のアウトオブバンド方式を使用して、S / MIMEのサポートのレベルを示すことができます。
Section 23.2 of [RFC3261] requires that the recipient of a SIP request that includes a body part of an unsupported media type and a Content-Disposition header field "handling" parameter of "required" return a 415 (Unsupported Media Type) response. Given that SIP MESSAGE exists for no reason other than to deliver content in the body, it is reasonable to treat the top-level body part as always required. However, [RFC3428] makes no such assertion. This document updates Section 11.3 of [RFC3428] to add the statement that a UAC that receives a SIP MESSAGE request with an unsupported media type MUST return a 415 response.
[RFC3261]のセクション23.2では、サポートされていないメディアタイプの本文部分と、「必須」のContent-Dispositionヘッダーフィールドの「処理」パラメータを含むSIPリクエストの受信者が415（サポートされていないメディアタイプ）レスポンスを返す必要があります。本文でコンテンツを配信する以外の理由でSIPメッセージが存在しないことを考えると、トップレベルの本文部分を常に必要なものとして扱うことが合理的です。しかしながら、[RFC3428]はそのような主張をしません。このドキュメントは、[RFC3428]のセクション11.3を更新して、サポートされていないメディアタイプのSIP MESSAGEリクエストを受信したUACが415応答を返さなければならない（MUST）ことを示すステートメントを追加します。
Section 23.2 of [RFC3261] says that if a recipient receives an S/MIME body encrypted to the wrong certificate, it MUST return a SIP 493 (Undecipherable) response and SHOULD send a valid certificate in that response. This is not always possible in practice for SIP MESSAGE requests. The UAS may choose not to decrypt a message until the user is ready to read it. Messages may be delivered to a message store or sent via a store-and-forward service. This document updates RFC 3261 to say that the UAS SHOULD return a SIP 493 response if it immediately attempts to decrypt the message and determines that the message was encrypted to the wrong certificate. However, it MAY return a 200-class response if decryption is deferred.
[RFC3261]のセクション23.2は、受信者が間違った証明書に暗号化されたS / MIME本文を受信した場合、SIP 493（解読不能）応答を返さなければならず、その応答で有効な証明書を送信する必要がある（SHOULD）と述べています。これは、SIP MESSAGE要求では実際には常に可能とは限りません。 UASは、ユーザーがメッセージを読む準備ができるまでメッセージを復号化しないことを選択できます。メッセージは、メッセージストアに配信されるか、ストアアンドフォワードサービスを介して送信されます。このドキュメントはRFC 3261を更新し、UASがメッセージの復号化をすぐに試み、メッセージが間違った証明書に暗号化されたと判断した場合、UASはSIP 493応答を返す必要があると述べています。ただし、復号化が延期されると、200クラスの応答が返される場合があります。
MSRP has features that interact with the use of S/MIME. In particular, the ability to send messages in chunks, the ability to send messages of unknown size, and the use of SDP to indicate media-type support create considerations for the use of S/MIME.
MSRPには、S / MIMEの使用と相互作用する機能があります。特に、メッセージをチャンクで送信する機能、サイズが不明なメッセージを送信する機能、メディアタイプのサポートを示すSDPの使用により、S / MIMEの使用に関する考慮事項が作成されます。
MSRP allows a message to be broken into "chunks" for transmission. In this context, the term "message" refers to an entire message that one user might send to another. A chunk is a fragment of that message sent in a single MSRP SEND request. All of the chunks that make up a particular message share the same Message-ID value.
MSRPでは、メッセージを「チャンク」に分割して送信できます。この文脈では、「メッセージ」という用語は、あるユーザーが別のユーザーに送信する可能性があるメッセージ全体を指します。チャンクは、単一のMSRP SEND要求で送信されるそのメッセージのフラグメントです。特定のメッセージを構成するすべてのチャンクは、同じMessage-ID値を共有します。
The sending UA may break a message into chunks, which the receiving UA will reassemble to form the complete message. Intermediaries such as MSRP relays [RFC4976] might break chunks into smaller chunks or might reassemble chunks into larger ones; therefore, the message received by the recipient may be broken into a different number of chunks than were sent by the recipient. Intermediaries might also cause chunks to be received in a different order than sent.
送信側UAはメッセージをチャンクに分割し、受信側UAは再構成して完全なメッセージを形成します。 MSRPリレー[RFC4976]などの仲介者は、チャンクを小さなチャンクに分割するか、チャンクを大きなチャンクに再構成する場合があります。したがって、受信者が受信したメッセージは、受信者が送信したものとは異なる数のチャンクに分割される可能性があります。仲介者は、チャンクを送信された順序とは異なる順序で受信する可能性もあります。
The sender MUST apply any S/MIME operations to the whole message prior to breaking it into chunks. Likewise, the receiver needs to reassemble the message from its chunks prior to decrypting, validating a signature, etc.
送信者は、メッセージをチャンクに分割する前に、メッセージ全体にS / MIME操作を適用する必要があります。同様に、受信者は、復号化、署名の検証などを行う前に、チャンクからメッセージを再構成する必要があります。
MSRP chunks are framed using an end-line. The end-line comprises seven hyphens, a 64-bit random value taken from the start line, and a continuation flag. MSRP requires the sending UA to scan data to be sent in a specific chunk to ensure that the end-line does not accidentally occur as part of the data. This scanning occurs on a chunk rather than a whole message; consequently, it must occur after the sender applies any S/MIME operations.
MSRPチャンクは、エンドラインを使用してフレーム化されます。終了行は、7つのハイフン、開始行から取得された64ビットのランダム値、および継続フラグで構成されます。 MSRPでは、エンドラインがデータの一部として誤って発生しないようにするために、送信UAが特定のチャンクで送信されるデータをスキャンする必要があります。このスキャンは、メッセージ全体ではなくチャンクで行われます。したがって、送信者がS / MIME操作を適用した後に発生する必要があります。
MSRP allows a mode of operation where a UA sends some chunks of a message prior to knowing the full length of the message. For example, a sender might send streamed data over MSRP as a single message, even though it doesn't know the full length of that data in advance. This mode is incompatible with S/MIME, since a sending UA must apply S/MIME operations to the entire message in advance of breaking it into chunks.
MSRPでは、UAがメッセージの完全な長さを知る前に、メッセージのいくつかのチャンクを送信する動作モードを使用できます。たとえば、送信者は、そのデータの全長が事前にわからなくても、MSRPを介して単一のメッセージとしてストリーミングデータを送信する場合があります。送信UAがメッセージをチャンクに分割する前にメッセージ全体にS / MIME操作を適用する必要があるため、このモードはS / MIMEと互換性がありません。
Therefore, when sending a message in an S/MIME format, the sender MUST include the Byte-Range header field for every chunk, including the first chunk. The Byte-Range header field MUST include the total length of the message.
したがって、メッセージをS / MIME形式で送信する場合、送信者はすべてのチャンク（最初のチャンクを含む）のByte-Rangeヘッダーフィールドを含める必要があります。 Byte-Rangeヘッダーフィールドには、メッセージの全長を含める必要があります。
A higher layer could choose to break such streamed data into a series of messages prior to applying S/MIME operations, so that each fragment appears as a distinct (separate) S/MIME message in MSRP. Such mechanisms are beyond the scope of this document.
上位層は、S / MIME操作を適用する前に、そのようなストリーミングデータを一連のメッセージに分割することを選択できます。これにより、各フラグメントは、MSRPで個別の（個別の）S / MIMEメッセージとして表示されます。このようなメカニズムは、このドキュメントの範囲を超えています。
A UA that supports this specification MUST explicitly include the appropriate media type or types in the "accept-types" attribute in any SDP offer or answer that proposes MSRP. It MAY indicate that it requires S/MIME wrappers for all messages by putting appropriate S/MIME media types in the "accept-types" attribute and putting all other supported media types in the "accept-wrapped-types" attribute.
この仕様をサポートするUAは、MSRPを提案するすべてのSDPオファーまたは回答の「accept-types」属性に適切なメディアタイプを明示的に含める必要があります。 「accept-types」属性に適切なS / MIMEメディアタイプを配置し、「accept-wrapped-types」属性にサポートされている他のすべてのメディアタイプを配置することにより、すべてのメッセージにS / MIMEラッパーが必要であることを示す場合があります。
For backwards compatibility, a sender MAY treat a peer that includes an asterisk ("*") in the "accept-types" attribute as potentially supporting S/MIME. If the peer returns an MSRP 415 (MIME type not understood) response to an attempt to send an S/MIME message, the sender should treat the peer as not supporting S/MIME for the duration of the session, as indicated in Section 7.3.1 of [RFC4975].
下位互換性のために、送信者は、「accept-types」属性にアスタリスク（「*」）を含むピアを、S / MIMEをサポートする可能性があるものとして扱うことができます（MAY）。ピアがS / MIMEメッセージを送信する試みに対してMSRP 415（MIMEタイプが不明）応答を返した場合、送信者は、セクション7.3に示すように、セッションの間、ピアをS / MIMEをサポートしていないものとして扱う必要があります。 [RFC4975]の1。
While these SDP attributes allow an endpoint to express support for certain media types only when wrapped in a specified envelope type, it does not allow the expression of more complex structures. For example, an endpoint can say that it supports text/plain and text/html, but only when inside an application/pkcs7 or message/cpim container, but it cannot express a requirement for the leaf types to always be contained in an application/pkcs7 container nested inside a message/cpim container. This has implications for the use of S/MIME with the message/cpim format. (See Section 9.1.)
これらのSDP属性により、エンドポイントは特定のメディアタイプのサポートを、指定されたエンベロープタイプにラップされた場合にのみ表現できますが、より複雑な構造の表現は許可されません。たとえば、エンドポイントは、text / plainおよびtext / htmlをサポートしていると言うことができますが、application / pkcs7またはmessage / cpimコンテナー内にある場合のみですが、リーフタイプが常にapplication /に含まれているという要件を表すことはできません。メッセージ/ cpimコンテナー内にネストされたpkcs7コンテナー。これは、message / cpim形式でのS / MIMEの使用に影響を与えます。 （9.1項を参照してください。）
MSRP allows multiple reporting modes that provide different levels of feedback. If the sender includes a Failure-Report header field with a value of "no", it will not receive failure reports. This mode should not be used carelessly, since such a sender would never see a 415 response as described above and would have no way to learn that the recipient could not process an S/MIME body.
MSRPでは、さまざまなレベルのフィードバックを提供する複数のレポートモードを使用できます。送信者が「no」の値を持つFailure-Reportヘッダーフィールドを含んでいる場合、失敗レポートを受信しません。このモードは不注意に使用しないでください。そのような送信者は上記のように415応答を決して見ることができず、受信者がS / MIME本体を処理できなかったことを知る方法がありません。
MSRP URIs are ephemeral. Endpoints MUST NOT use MSRP URIs to identify certificates or insert MSRP URIs into certificate Subject Alternative Name fields. When MSRP sessions are negotiated using SIP [RFC3261], the SIP AoRs of the peers are used instead.
MSRP URIは短命です。エンドポイントは、MSRP URIを使用して証明書を識別したり、MSRP URIを証明書のサブジェクトの別名フィールドに挿入してはなりません（MUST NOT）。 MSRPセッションがSIP [RFC3261]を使用してネゴシエートされると、代わりにピアのSIP AoRが使用されます。
Note that MSRP allows messages to be sent between peers in either direction. A given MSRP message might be sent from the SIP offerer to the SIP answerer. Thus, the sender and recipient roles may reverse between one message and another in a given session.
MSRPでは、ピア間でメッセージをどちらの方向にも送信できることに注意してください。特定のMSRPメッセージがSIP提供者からSIP回答者に送信される場合があります。したがって、送信者と受信者の役割は、特定のセッションでメッセージ間で逆になる場合があります。
Successful delivery of an S/MIME message does not indicate that the recipient successfully decrypted the contents or validated a signature. Decryption and/or validation may not occur immediately on receipt, since the recipient may not immediately view the message, and the UA may choose not to attempt decryption or validation until the user requests it.
S / MIMEメッセージの配信が成功しても、受信者がコンテンツを正常に復号化したか、署名を検証したかどうかはわかりません。受信者はメッセージをすぐには表示できないため、ユーザーが要求するまで、UAは復号化または検証を行わないことを選択する可能性があるため、復号化や検証は受信直後に行われない場合があります。
Likewise, successful delivery of S/MIME enveloped data does not, on its own, indicate that the recipient supports the enclosed media type. If the peer only implicitly indicated support for the enclosed media type through the use of a wildcard in the "accept-types" or "accept-wrapped types" SDP attributes, it may not decrypt the message in time to send a 415 response.
同様に、S / MIMEエンベロープデータの配信が成功しても、受信者が同封のメディアタイプをサポートしていることを示すものではありません。ピアが「accept-types」または「accept-wrapped types」SDP属性でワイルドカードを使用して、囲まれたメディアタイプのサポートを暗黙的に示しただけの場合、415応答を送信するためにメッセージを復号化できないことがあります。
The Common Profile for Instant Messaging (CPIM) [RFC3860] defines an abstract messaging service, with the goal of creating gateways between different messaging protocols that could relay instant messages without change. The SIP MESSAGE method and MSRP were initially designed to map to the CPIM abstractions. However, at the time of this writing, CPIM-compliant gateways have not been deployed. To the authors' knowledge, no other IM protocols have been explicitly mapped to CPIM.
インスタントメッセージングの共通プロファイル（CPIM）[RFC3860]は、インスタントメッセージングを変更せずに中継できる異なるメッセージングプロトコル間にゲートウェイを作成することを目的として、抽象的なメッセージングサービスを定義します。 SIP MESSAGEメソッドとMSRPは、最初はCPIM抽象にマップするように設計されました。ただし、この記事の執筆時点では、CPIM準拠のゲートウェイは展開されていません。著者の知る限りでは、他のIMプロトコルは明示的にCPIMにマッピングされていません。
CPIM also defines the abstract messaging URI scheme "im:". As of the time of this writing, the "im:" scheme is not in common use.
CPIMは、抽象メッセージングURIスキーム「im：」も定義します。この記事の執筆時点では、「im：」スキームは一般的に使用されていません。
The CPIM message format [RFC3862] allows UAs to attach transport-neutral metadata to arbitrary MIME content. The format was designed as a canonicalization format to allow signed data to cross protocol-converting gateways without loss of metadata needed to verify the signature. While it has not typically been used for that purpose, it has been used for other metadata applications -- for example, IMDNs [RFC5438] and MSRP multi-party chat [RFC7701].
CPIMメッセージフォーマット[RFC3862]により、UAはトランスポートニュートラルメタデータを任意のMIMEコンテンツに添付できます。この形式は、署名の検証に必要なメタデータを失うことなく、署名されたデータがプロトコル変換ゲートウェイを通過できるようにする正規化形式として設計されました。通常、この目的には使用されていませんが、IMDN [RFC5438]やMSRPマルチパーティチャット[RFC7701]などの他のメタデータアプリケーションに使用されています。
In the general case, a sender applies end-to-end signature and encryption operations to the entire MIME body. However, some messaging systems expect to inspect and in some cases add or modify metadata in CPIM header fields. For example, CPM-based and RCS-based services include application servers that may need to insert timestamps into chat messages and may use additional metadata to characterize the content and purpose of a message to determine application behavior. The former will cause validation failure for signatures that cover CPIM metadata, while the latter is not possible if the metadata is encrypted. Clients intended for use in such networks MAY choose to apply end-to-end signatures and encryption operations to only the CPIM payload, leaving the CPIM metadata unprotected from inspection and modification. UAs that support S/MIME and CPIM SHOULD be able to validate signatures and decrypt enveloped data both (1) when those operations are applied to the entire CPIM body and (2) when they are applied to just the CPIM payload. This means that the receiver needs to be flexible in its MIME document parsing and that it cannot make assumptions that S/MIME-protected body parts will always be in the same position or level in the message payload.
一般的なケースでは、送信者はエンドツーエンドの署名および暗号化操作をMIME本文全体に適用します。ただし、一部のメッセージングシステムは、CPIMヘッダーフィールドのメタデータを検査し、場合によっては追加または変更することを期待しています。たとえば、CPMベースおよびRCSベースのサービスには、チャットメッセージにタイムスタンプを挿入する必要があり、追加のメタデータを使用してメッセージの内容と目的を特徴づけ、アプリケーションの動作を決定するアプリケーションサーバーが含まれます。前者はCPIMメタデータをカバーする署名の検証エラーを引き起こしますが、後者はメタデータが暗号化されている場合は不可能です。そのようなネットワークでの使用を目的としたクライアントは、エンドツーエンドの署名と暗号化操作をCPIMペイロードのみに適用し、CPIMメタデータを検査と変更から保護しないままにすることを選択できます。 S / MIMEとCPIMをサポートするUAは、（1）これらの操作がCPIM本体全体に適用される場合と、（2）CPIMペイロードのみに適用される場合の両方で、署名を検証してエンベロープデータを復号化できる必要があります（SHOULD）。つまり、受信者はMIMEドキュメントの解析において柔軟である必要があり、S / MIMEで保護されたボディパーツが常にメッセージペイロードの同じ位置またはレベルにあるとは想定できません。
If such clients need to encrypt or sign CPIM metadata end to end, they can nest a protected CPIM message format payload inside an unprotected CPIM message envelope.
このようなクライアントは、CPIMメタデータをエンドツーエンドで暗号化または署名する必要がある場合、保護されていないCPIMメッセージエンベロープを保護されていないCPIMメッセージエンベロープ内にネストできます。
The use of CPIM metadata fields to identify certificates or to authenticate SIP or MSRP header fields is out of scope for this document.
証明書を識別したり、SIPまたはMSRPヘッダーフィールドを認証したりするためのCPIMメタデータフィールドの使用は、このドキュメントの範囲外です。
The IMDN mechanism [RFC5438] allows both endpoints and intermediary application servers to request and to generate delivery notifications. The use of S/MIME does not impact strictly end-to-end use of IMDNs. The IMDN mechanism recommends that devices that are capable of doing so sign delivery notifications. It further requires that delivery notifications that result from encrypted messages also be encrypted.
IMDNメカニズム[RFC5438]を使用すると、エンドポイントと中間アプリケーションサーバーの両方が配信通知を要求および生成できます。 S / MIMEの使用は、IMDNの厳密なエンドツーエンドの使用には影響しません。 IMDNメカニズムでは、そのようにできるデバイスが配信通知に署名することを推奨しています。さらに、暗号化されたメッセージに起因する配信通知も暗号化する必要があります。
However, the IMDN mechanism allows intermediary application servers to insert notification requests into messages, to add routing information to messages, and to act on notification requests. It also allows list servers to aggregate delivery notifications.
ただし、IMDNメカニズムにより、中間アプリケーションサーバーはメッセージに通知要求を挿入し、メッセージにルーティング情報を追加し、通知要求に基づいて動作することができます。また、リストサーバーで配信通知を集約することもできます。
Such intermediaries will be unable to read end-to-end encrypted messages in order to interpret delivery notice requests. Intermediaries that insert information into end-to-end signed messages will cause the signature validation to fail. (See Section 9.1.)
このような仲介者は、配信通知要求を解釈するために、エンドツーエンドの暗号化されたメッセージを読み取ることができません。エンドツーエンドの署名付きメッセージに情報を挿入する仲介者は、署名の検証に失敗します。 （9.1項を参照してください。）
The following sections show examples of S/MIME messages in SIP and MSRP. The examples include the tags "[start-hex]" and "[end-hex]" to denote binary content shown in hexadecimal. The tags are not part of the actual message and do not count towards the Content-Length header field values.
以下のセクションでは、SIPおよびMSRPでのS / MIMEメッセージの例を示します。例には、タグ「[start-hex]」および「[end-hex]」が含まれ、16進数で表示されるバイナリコンテンツを示します。タグは実際のメッセージの一部ではなく、Content-Lengthヘッダーフィールドの値にはカウントされません。
In all of these examples, the cleartext message is the string "Watson, come here - I want to see you." followed by a newline character.
これらすべての例で、クリアテキストメッセージは「ワトソン、ここに来て-会いたい」という文字列です。改行文字が続きます。
The cast of characters includes Alice, with a SIP AoR of "alice@example.com", and Bob, with a SIP AoR of "bob@example.org".
文字のキャストには、SIP AoRが「alice@example.com」であるアリスと、SIP AoRが「bob@example.org」であるボブが含まれます。
Appendix A shows the detailed content of each S/MIME body.
付録Aは、各S / MIME本文の詳細な内容を示しています。
Figure 1 shows a message signed by Alice. This body uses the "application/pkcs7-mime" media type with an smime-type parameter value of "signed-data".
図1は、アリスが署名したメッセージを示しています。この本文では、smime-typeパラメータ値が「signed-data」の「application / pkcs7-mime」メディアタイプを使用しています。
The S/MIME body includes Alice's signing certificate. Even though the original message content is fairly short and only minimal SIP header fields are included, the total message size approaches the maximum allowed for the SIP MESSAGE method unless the UAC has advance knowledge that all SIP hops will use congestion-controlled transport protocols. A message that included all the SIP header fields that are commonly in use in some SIP deployments would likely exceed the limit.
S / MIME本文には、アリスの署名証明書が含まれています。元のメッセージコンテンツはかなり短く、最小限のSIPヘッダーフィールドのみが含まれていますが、UACがすべてのSIPホップが輻輳制御のトランスポートプロトコルを使用するという事前知識がない限り、合計メッセージサイズはSIP MESSAGEメソッドで許可される最大値に近づきます。一部のSIP展開で一般的に使用されているすべてのSIPヘッダーフィールドを含むメッセージは、制限を超える可能性があります。
MESSAGE sip:bob@example.org SIP/2.0
Via: SIP/2.0/TCP alice-pc.example.com;branch=z9hG4bK776sgdkfie
Max-Forwards: 70
From: sip:alice@example.com;tag=49597
To: sip:bob@example.org
Call-ID: asd88asd66b@1.2.3.4
CSeq: 1 MESSAGE
Content-Transfer-Encoding: binary
Content-Type: application/pkcs7-mime; smime-type=signed-data;
name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Length: 762
[start-hex] 308202f606092a864886f70d010702a08202e7308202e3020101310d300b0609 608648016503040201305306092a864886f70d010701a0460444436f6e74656e 742d547970653a20746578742f706c61696e0d0a0d0a576174736f6e2c20636f 6d652068657265202d20492077616e7420746f2073656520796f752e0d0aa082 016b308201673082010da003020102020900b8793ec0e4c21530300a06082a86 48ce3d040302302631143012060355040a0c0b6578616d706c652e636f6d310e 300c06035504030c05416c696365301e170d3137313231393233313230355a17 0d3138313231393233313230355a302631143012060355040a0c0b6578616d70 6c652e636f6d310e300c06035504030c05416c6963653059301306072a8648ce 3d020106082a8648ce3d03010703420004d87b54729f2c22feebd9ddba0efa40 642297a6093887a4dae7990b23f87fa7ed99db8cf5a314f2ee64106ef1ed61db fc0a4b91c953cbd022a751b914807bb794a324302230200603551d1104193017 86157369703a616c696365406578616d706c652e636f6d300a06082a8648ce3d 040302034800304502207879be1c27f846276fdf15e333e53c6f17a757388a02 cb7b8ae481c1641ae7a9022100ff99cd9c94076c82b02fea3b1350179a4b7752 e16fa30a3f9ab29650b0e2818931820109308201050201013033302631143012 060355040a0c0b6578616d706c652e636f6d310e300c06035504030c05416c69 6365020900b8793ec0e4c21530300b0609608648016503040201a06930180609 2a864886f70d010903310b06092a864886f70d010701301c06092a864886f70d 010905310f170d3139303132363036313335345a302f06092a864886f70d0109 0431220420ef778fc940d5e6dc2576f47a599b3126195a9f1a227adaf35fa22c 050d8d195a300a06082a8648ce3d04030204473045022005fdc2b55b0f444a46 be468dfc7ef3b7de30019ef0952a223e8521890b35bb4e02210090e43a9d9846 cf2af8159c5c0ef48848fa2f39f998b1bb99b52a6fc6c776f2c8 [end-hex]
[開始ヘクス] 308202f606092a864886f70d010702a08202e7308202e3020101310d300b0609 608648016503040201305306092a864886f70d010701a0460444436f6e74656e 742d547970653a20746578742f706c61696e0d0a0d0a576174736f6e2c20636f 6d652068657265202d20492077616e7420746f2073656520796f752e0d0aa082 016b308201673082010da003020102020900b8793ec0e4c21530300a06082a86 48ce3d040302302631143012060355040a0c0b6578616d706c652e636f6d310e 300c06035504030c05416c696365301e170d3137313231393233313230355a17 0d3138313231393233313230355a302631143012060355040a0c0b6578616d70 6c652e636f6d310e300c06035504030c05416c6963653059301306072a8648ce 3d020106082a8648ce3d03010703420004d87b54729f2c22feebd9ddba0efa40 642297a6093887a4dae7990b23f87fa7ed99db8cf5a314f2ee64106ef1ed61db fc0a4b91c953cbd022a751b914807bb794a324302230200603551d1104193017 86157369703a616c696365406578616d706c652e636f6d300a06082a8648ce3d 040302034800304502207879be1c27f846276fdf15e333e53c6f17a757388a02 cb7b8ae481c1641ae7a9022100ff99cd9c94076c82b02fea3b1350179a4b7752 e16fa30a3f9ab 29650b0e2818931820109308201050201013033302631143012 060355040a0c0b6578616d706c652e636f6d310e300c06035504030c05416c69 6365020900b8793ec0e4c21530300b0609608648016503040201a06930180609 2a864886f70d010903310b06092a864886f70d010701301c06092a864886f70d 010905310f170d3139303132363036313335345a302f06092a864886f70d0109 0431220420ef778fc940d5e6dc2576f47a599b3126195a9f1a227adaf35fa22c 050d8d195a300a06082a8648ce3d04030204473045022005fdc2b55b0f444a46 be468dfc7ef3b7de30019ef0952a223e8521890b35bb4e02210090e43a9d9846 cf2af8159c5c0ef48848fa2f39f998b1bb99b52a6fc6c776f2c8 [エンド - ヘキサ]
Figure 1: Signed Message in SIP
図1：SIPでの署名付きメッセージ
Figure 2 shows the same message from Alice without the embedded certificate. The shorter total message length may be more manageable.
図2は、埋め込まれた証明書なしのアリスからの同じメッセージを示しています。メッセージの長さの合計が短いほど、管理しやすくなります。
MESSAGE sip:bob@example.org SIP/2.0
Via: SIP/2.0/TCP alice-pc.example.com;branch=z9hG4bK776sgdkfie
Max-Forwards: 70
From: sip:alice@example.com;tag=49597
To: sip:bob@example.org
Call-ID: asd88asd66b@1.2.3.4
CSeq: 1 MESSAGE
Content-Transfer-Encoding: binary
Content-Type: application/pkcs7-mime; smime-type=signed-data;
name="smime.p7m"
Content-Disposition: attachment; filename="smime.p7m"
Content-Length: 395
[start-hex] 3082018706092a864886f70d010702a082017830820174020101310d300b0609 608648016503040201305306092a864886f70d010701a0460444436f6e74656e 742d547970653a20746578742f706c61696e0d0a0d0a576174736f6e2c20636f 6d652068657265202d20492077616e7420746f2073656520796f752e0d0a3182 0109308201050201013033302631143012060355040a0c0b6578616d706c652e 636f6d310e300c06035504030c05416c696365020900b8793ec0e4c21530300b 0609608648016503040201a069301806092a864886f70d010903310b06092a86 4886f70d010701301c06092a864886f70d010905310f170d3139303132363036 313335345a302f06092a864886f70d01090431220420ef778fc940d5e6dc2576 f47a599b3126195a9f1a227adaf35fa22c050d8d195a300a06082a8648ce3d04 03020447304502203607275592d30c8c5a931041a01804d60c638ac9a8080918 87172a0887c8d4aa022100cd9e14bd21817336e9052fe590af2e2bcde16dd3e9 48d0f5f78a969e26382682 [end-hex]
[開始ヘクス] 3082018706092a864886f70d010702a082017830820174020101310d300b0609 608648016503040201305306092a864886f70d010701a0460444436f6e74656e 742d547970653a20746578742f706c61696e0d0a0d0a576174736f6e2c20636f 6d652068657265202d20492077616e7420746f2073656520796f752e0d0a3182 0109308201050201013033302631143012060355040a0c0b6578616d706c652e 636f6d310e300c06035504030c05416c696365020900b8793ec0e4c21530300b 0609608648016503040201a069301806092a864886f70d010903310b06092a86 4886f70d010701301c06092a864886f70d010905310f170d3139303132363036 313335345a302f06092a864886f70d01090431220420ef778fc940d5e6dc2576 f47a599b3126195a9f1a227adaf35fa22c050d8d195a300a06082a8648ce3d04 03020447304502203607275592d30c8c5a931041a01804d60c638ac9a8080918 87172a0887c8d4aa022100cd9e14bd21817336e9052fe590af2e2bcde16dd3e9 48d0f5f78a969e26382682 [エンド - ヘキサ]
Figure 2: Signed Message in SIP with No Certificate Included
図2：証明書が含まれていないSIPでの署名付きメッセージ
Figure 3 shows a signed and encrypted message from Bob to Alice sent via MSRP.
図3は、MSRPを介して送信されたボブからアリスへの署名および暗号化されたメッセージを示しています。
MSRP dsdfoe38sd SEND
To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bobpc.example.org:8888/9di4eae923wzd;tcp
Message-ID: 456so39s
Byte-Range: 1-1940/1940
Content-Disposition: attachment; filename="smime.p7m"
Content-Type: application/pkcs7-mime; smime-type=auth-enveloped-data;
name="smime.p7m"
[start-hex]
30820790060b2a864886f70d0109100117a082077f3082077b0201003182024f
3082024b0201003033302631143012060355040a0c0b6578616d706c652e636f
6d310e300c06035504030c05416c69636502090083f50bb70bd5c40e300d0609
2a864886f70d010101050004820200759a61b4ddf1f1af24668005635e476110
fa2723c1b9e45484b6d33e8387de967dc5e0cafb35571a56a1975cb550e7be31
c131da80fb731024845babb8d64cac26040424d9330561c843999415dd644b3c
ad95072f71451393c99f282c4883bd0ccc5dd54b931464e00a6e55e592c51a68
de1062516ec7d3ca8e764bb8ac789a88377765ef8dc36c0a6ed3ecae5285cac6
a29d5059445719a1bdcf906e0ff37e2c2ef0f4ec6225100cc062e1c748963bbc
88b8e3dfcf714073729dd5c7583e758acf3d186f2fa417be22c37c9a76c6b427
29aad27f73ae44ac98474d1eeb48948c12a403d0b3ce08a218d6af456924897c
c5c9664f6dfeb3f18141158dfc3b84090aa60380aa865137e1699c5c81974167
9d7a3c90ba79e6d7d5c8d89bb54a667423e43b0b7d6f78c0b4ab67bc343662a6
35fe595f1149c53950cac2e0ba318c227e6f76a8d940400fd3d3ea1c8ecea003
dcce2f1fb00f5cea335de1303fcbf93d8e1cbfd682f19beb624bacd1d7b8f580
f114a13b890894fb4044a5daa764b7f8c5ff92949452b35aeb9639b8ad63c051
5c95ccc6f823c2201067ea2262413fef397d48f7b6143f842ae8e1a48cad3ae0
1abaa3cf9ee7e36620e05cca0611bfac00eef1a498f2d259b9f0f7da83ef6f1b
061f387c2dc48c8b5dbaca862308f32f47925165c9e5ebb467799884918dd697
b447f4c407989b889b0c2e9580af783082050f06092a864886f70d010701301e
06096086480165030401063011040c4d8757222eac5294117f0c120201108082
04e0fe2fb3de0bf06998c39bf4a952fabf8b0fee3d7e2e85181aecf1a89e1a2e
decd9404885612dfc6984334d8602b7749b2504e45f57c3b066626b0fc746236
1eec267c560139be5cd286a2af9696cf51852278e52c3818cab0a68c598de4fc
e14a333884e4de5ddf57edd78867027a31e4a7c0c0299144c5de6bae39699e70
0e057eb0f0dad73b8b369f42eb321b41538781d982a11a0b3943ac10c97b54ee
b73b38ec131afc5610e373487274d69cafa9541902886c64f6962d42eb33f904
1a4ae11b88dc6958d53df50b8bb52aa35e2299885d0aae416b86f0a88d0eb7a9
81dbb283e8b94e9d50bf6265c2348a18a169aacb5a37a529bda2f9cb10efddcf
14231095d87964637bd33fb13c68b4cff9a1906960c1ea2301d325b7a15c5829
f3ea038f24df6b23180377d37131f75db18f41f9d85b653dfa46bf2617126326
ccf1cb833457752352c8417a094484d7b64bcf51b26a9beb3a0ed4b9caf1bd23
c690c654f7eb9ce9852e2f6d068eef8ba33bc6c4dddca7aef4d3574737d7c4dc
1e93770d8f4f22dea61d73083c32c4038c1eb3dd3383a89a8795e241c2ed7cb6
80758c041069489860fc9f490e85236072548b3249698f99953acf1ec658b7aa
85e554c449701a6d4b039ed103dc458df4b29cb04b8cedd540c84348da79c186
56d5188f9f3a9e4b9b840c70664b90296c60b7ac984e918d48a09dbddfb281fc
862510db59d9fa9dc93f10f9c6d7bef72931d184cad7ac13c1a5295fc89fe3bb
7eb8e02085a828c5a138786e607ade4f5e8d4115909209ba878a79305a5316c2
2229e42b886d06481c8473f9d51269e2af6341bce20f768e860d7784ed46150e
04ff50cd209c5b127511369fe06bc4aa9a72d8f1fe4fcf0866d664b365ffa86e
8c1b43e7a9212aecc16ca350a28efae25fac054dd934bfe7e5fa4f753aa41596
8c7ebec439e0ac0270b4874a068d22484c09d9e8abe17f1372b4b2f65f1148e8
933eda92e5d1774564963b391c3bbd9f1c27ffe36f832e05155fc39ee6652fa7
b4188975ec5c67b32c9f213c8ac6b8e132a5a7c3bf74f016405cd8c201d10521
93e186d44358de388d73211ba2f1792f3cfeb9bbde7211d26f56ab06e11ccc9c
cde2b88cd8373773eafc37fd85b7a7a2bcaec752e617d6e01c02b86e9d9a40f3
20462c5d66f8351716dcd6014bdf30a60f75fc0631c920845ed8c0bad35ddf19
84f2241cd3b529dc1028845f8089543df4f1441ede36b1bf31af5afc8c2b708d
50b645d4e7db88648c3eefe14765158fb0e8d3bb53ddcbe26d7124c6e1d992f8
3230aa953376ee8c68109568e8571f0c9bbda48f4df306fe747f371175148f31
832767cd766cf07b450cbf62cad2a7bd71f1f88233f116a1a7f3caf12f34bcf4
0d21e79ffc9827221b68b080ff03ad782d6d6d07871676f798943e54f13fd75c
89c0b4263bf10f56243f9e72ef3b3899a539d9a3ac5be2b69400a3cf8d196c5c
ed697b2ed803b987a5ee85c5095b48da7a5b03b47e2b9fe4cd4bc3098e864e0c
e7d467da99cd7f3a9e947b5eea77f7a6be16c8c7e9e0decc1ff132559c234321
7b9c2950386e85d2942121086cdfa19658195be6d7f86bca9881b695082964f1
2e7cf801025d6792c6882409414d703321ec83abd698d68956118713a0ff1272
acbc9a6d148900c74c16921df9b38f29ec46d4f10060fffe5e36bbbacaf2d1ba
d7dd057ed3e30ebcd69083f9d3a2a26ef90b751d6a1adfa0590db19da107cf3e
a8db0410f6ffc6e1aef19cd23d985a921976352d
[end-hex]
-------dsdfoe38sd$
Figure 3: Signed and Encrypted Message in MSRP
図3：MSRPでの署名および暗号化されたメッセージ
Figure 4 shows the same message as in Figure 3 except that the message is broken into two chunks. The S/MIME operations were performed prior to breaking the message into chunks.
図4は、メッセージが2つのチャンクに分割されていることを除いて、図3と同じメッセージを示しています。 S / MIME操作は、メッセージをチャンクに分割する前に実行されました。
MSRP d93kswow SEND
To-Path: msrp://alicepc.example.com:7777/iau39soe2843z;tcp
From-Path: msrp://bobpc.example.org:8888/9di4eae923wzd;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-960/1940
Content-Disposition: attachment; filename="smime.p7m"
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name="smime.p7m"
[start-hex]
30820790060b2a864886f70d0109100117a082077f3082077b0201003182024f
3082024b0201003033302631143012060355040a0c0b6578616d706c652e636f
6d310e300c06035504030c05416c69636502090083f50bb70bd5c40e300d0609
2a864886f70d010101050004820200759a61b4ddf1f1af24668005635e476110
fa2723c1b9e45484b6d33e8387de967dc5e0cafb35571a56a1975cb550e7be31
c131da80fb731024845babb8d64cac26040424d9330561c843999415dd644b3c
ad95072f71451393c99f282c4883bd0ccc5dd54b931464e00a6e55e592c51a68
de1062516ec7d3ca8e764bb8ac789a88377765ef8dc36c0a6ed3ecae5285cac6
a29d5059445719a1bdcf906e0ff37e2c2ef0f4ec6225100cc062e1c748963bbc
88b8e3dfcf714073729dd5c7583e758acf3d186f2fa417be22c37c9a76c6b427
29aad27f73ae44ac98474d1eeb48948c12a403d0b3ce08a218d6af456924897c
c5c9664f6dfeb3f18141158dfc3b84090aa60380aa865137e1699c5c81974167
9d7a3c90ba79e6d7d5c8d89bb54a667423e43b0b7d6f78c0b4ab67bc343662a6
35fe595f1149c53950cac2e0ba318c227e6f76a8d940400fd3d3ea1c8ecea003
dcce2f1fb00f5cea335de1303fcbf93d8e1cbfd682f19beb624bacd1d7b8f580
f114a13b890894fb4044a5daa764b7f8c5ff92949452b35aeb9639b8ad63c051
5c95ccc6f823c2201067ea2262413fef397d48f7b6143f842ae8e1a48cad3ae0
1abaa3cf9ee7e36620e05cca0611bfac00eef1a498f2d259b9f0f7da83ef6f1b
061f387c2dc48c8b5dbaca862308f32f47925165c9e5ebb467799884918dd697
b447f4c407989b889b0c2e9580af783082050f06092a864886f70d010701301e
06096086480165030401063011040c4d8757222eac5294117f0c120201108082
04e0fe2fb3de0bf06998c39bf4a952fabf8b0fee3d7e2e85181aecf1a89e1a2e
decd9404885612dfc6984334d8602b7749b2504e45f57c3b066626b0fc746236
1eec267c560139be5cd286a2af9696cf51852278e52c3818cab0a68c598de4fc
e14a333884e4de5ddf57edd78867027a31e4a7c0c0299144c5de6bae39699e70
0e057eb0f0dad73b8b369f42eb321b41538781d982a11a0b3943ac10c97b54ee
b73b38ec131afc5610e373487274d69cafa9541902886c64f6962d42eb33f904
1a4ae11b88dc6958d53df50b8bb52aa35e2299885d0aae416b86f0a88d0eb7a9
81dbb283e8b94e9d50bf6265c2348a18a169aacb5a37a529bda2f9cb10efddcf
14231095d87964637bd33fb13c68b4cff9a1906960c1ea2301d325b7a15c5829
[end-hex]
-------d93kswow+
MSRP op2nc9a SEND
To-Path: msrp://alicepc.example.com:8888/9di4eae923wzd;tcp
From-Path: msrp://bobpc.example.org:7654/iau39soe2843z;tcp
Message-ID: 12339sdqwer
Byte-Range: 961-1940/1940
Content-Disposition: attachment; filename="smime.p7m"
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name="smime.p7m"
[start-hex]
f3ea038f24df6b23180377d37131f75db18f41f9d85b653dfa46bf2617126326
ccf1cb833457752352c8417a094484d7b64bcf51b26a9beb3a0ed4b9caf1bd23
c690c654f7eb9ce9852e2f6d068eef8ba33bc6c4dddca7aef4d3574737d7c4dc
1e93770d8f4f22dea61d73083c32c4038c1eb3dd3383a89a8795e241c2ed7cb6
80758c041069489860fc9f490e85236072548b3249698f99953acf1ec658b7aa
85e554c449701a6d4b039ed103dc458df4b29cb04b8cedd540c84348da79c186
56d5188f9f3a9e4b9b840c70664b90296c60b7ac984e918d48a09dbddfb281fc
862510db59d9fa9dc93f10f9c6d7bef72931d184cad7ac13c1a5295fc89fe3bb
7eb8e02085a828c5a138786e607ade4f5e8d4115909209ba878a79305a5316c2
2229e42b886d06481c8473f9d51269e2af6341bce20f768e860d7784ed46150e
04ff50cd209c5b127511369fe06bc4aa9a72d8f1fe4fcf0866d664b365ffa86e
8c1b43e7a9212aecc16ca350a28efae25fac054dd934bfe7e5fa4f753aa41596
8c7ebec439e0ac0270b4874a068d22484c09d9e8abe17f1372b4b2f65f1148e8
933eda92e5d1774564963b391c3bbd9f1c27ffe36f832e05155fc39ee6652fa7
b4188975ec5c67b32c9f213c8ac6b8e132a5a7c3bf74f016405cd8c201d10521
93e186d44358de388d73211ba2f1792f3cfeb9bbde7211d26f56ab06e11ccc9c
cde2b88cd8373773eafc37fd85b7a7a2bcaec752e617d6e01c02b86e9d9a40f3
20462c5d66f8351716dcd6014bdf30a60f75fc0631c920845ed8c0bad35ddf19
84f2241cd3b529dc1028845f8089543df4f1441ede36b1bf31af5afc8c2b708d
50b645d4e7db88648c3eefe14765158fb0e8d3bb53ddcbe26d7124c6e1d992f8
3230aa953376ee8c68109568e8571f0c9bbda48f4df306fe747f371175148f31
832767cd766cf07b450cbf62cad2a7bd71f1f88233f116a1a7f3caf12f34bcf4
0d21e79ffc9827221b68b080ff03ad782d6d6d07871676f798943e54f13fd75c
89c0b4263bf10f56243f9e72ef3b3899a539d9a3ac5be2b69400a3cf8d196c5c
ed697b2ed803b987a5ee85c5095b48da7a5b03b47e2b9fe4cd4bc3098e864e0c
e7d467da99cd7f3a9e947b5eea77f7a6be16c8c7e9e0decc1ff132559c234321
7b9c2950386e85d2942121086cdfa19658195be6d7f86bca9881b695082964f1
2e7cf801025d6792c6882409414d703321ec83abd698d68956118713a0ff1272
acbc9a6d148900c74c16921df9b38f29ec46d4f10060fffe5e36bbbacaf2d1ba
d7dd057ed3e30ebcd69083f9d3a2a26ef90b751d6a1adfa0590db19da107cf3e
a8db0410f6ffc6e1aef19cd23d985a921976352d
[end-hex]
-------op2nc9a$
Figure 4: Signed, Encrypted, and Chunked MSRP Message
図4：署名、暗号化、およびチャンク化されたMSRPメッセージ
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
The security considerations for S/MIME [RFC8550] [RFC8551] and elliptic curves in CMS [RFC5753] apply. The S/MIME-related security considerations for SIP [RFC3261], SIP MESSAGE [RFC3428], and MSRP [RFC4975] apply.
S / MIME [RFC8550] [RFC8551]およびCMSの楕円曲線[RFC5753]のセキュリティに関する考慮事項が適用されます。 SIP [RFC3261]、SIP MESSAGE [RFC3428]、およびMSRP [RFC4975]のS / MIME関連のセキュリティに関する考慮事項が適用されます。
The security considerations for algorithms recommended in this document also apply; see [RFC3565], [RFC5480], [RFC5753], [RFC5754], [RFC7748], [RFC8032], [RFC8418], and [RFC8419].
このドキュメントで推奨されているアルゴリズムのセキュリティに関する考慮事項も適用されます。 [RFC3565]、[RFC5480]、[RFC5753]、[RFC5754]、[RFC7748]、[RFC8032]、[RFC8418]、および[RFC8419]を参照してください。
This document assumes that end-entity certificate validation is provided by a chain of trust to a certification authority (CA), using a public key infrastructure. The security considerations from [RFC5280] apply. However, other validations methods may be possible -- for example, sending a signed fingerprint for the end entity in SDP. The relationship between this work and the techniques discussed in [RFC8224] and [RTP-Sec] are out of scope for this document.
このドキュメントは、エンドエンティティ証明書の検証が、公開キー基盤を使用して、証明機関（CA）への信頼の連鎖によって提供されることを前提としています。 [RFC5280]のセキュリティに関する考慮事項が適用されます。ただし、SDPでエンドエンティティの署名済み指紋を送信するなど、他の検証方法も可能です。この作業と、[RFC8224]および[RTP-Sec]で説明されている手法との関係は、このドキュメントの範囲外です。
When matching an end-entity certificate to the sender or recipient identity, the respective SIP AoRs are used. Typically, these will match the SIP From and To header fields. Some UAs may extract the sender identity from SIP AoRs in other header fields -- for example, P-Asserted-Identity [RFC3325]. In general, the UAS should compare the certificate to the identity that it relies upon -- for example, for display to the end user or comparison against message-filtering rules.
エンドエンティティ証明書を送信者または受信者のIDと照合する場合、それぞれのSIP AoRが使用されます。通常、これらはSIP FromおよびToヘッダーフィールドと一致します。一部のUAは、他のヘッダーフィールドのSIP AoRから送信者IDを抽出する場合があります-たとえば、P-Asserted-Identity [RFC3325]。一般に、UASは証明書を証明書が依存しているIDと比較する必要があります。たとえば、エンドユーザーに表示したり、メッセージフィルタリングルールと比較したりします。
The secure notification use case discussed in Section 1 has significant vulnerabilities when used in an insecure environment. For example, "phishing" messages could be used to trick users into revealing credentials. Eavesdroppers could learn confirmation codes from unprotected two-factor authentication messages. Unsolicited messages sent by impersonators could tarnish the reputation of an organization. While hop-by-hop protection can mitigate some of those risks, it still leaves messages vulnerable to malicious or compromised intermediaries. End-to-end protection prevents modification by intermediaries. However, neither provides much protection unless the recipient knows to expect messages from a particular sender to be signed and refuses to accept unsigned messages that appear to be from that source.
セクション1で説明されている安全な通知の使用例は、安全でない環境で使用される場合に重大な脆弱性があります。たとえば、「フィッシング」メッセージを使用して、ユーザーをだまして認証情報を開示させることができます。盗聴者は、保護されていない2要素認証メッセージから確認コードを取得する可能性があります。なりすましによって送信された迷惑なメッセージは、組織の評判を傷つける可能性があります。ホップバイホップ保護はこれらのリスクの一部を軽減することができますが、それでもメッセージは悪意のある、または侵害された仲介者に対して脆弱です。エンドツーエンドの保護により、仲介者による変更を防ぎます。ただし、受信者が特定の送信者からのメッセージが署名されることを期待していることを知り、その送信元からのように見える署名されていないメッセージの受け入れを拒否しない限り、どちらも多くの保護を提供しません。
Mobile messaging is typically an online application; online certificate revocation checks should usually be feasible.
モバイルメッセージングは通常、オンラインアプリケーションです。オンラインの証明書失効チェックは通常、実行可能であるはずです。
S/MIME does not normally protect the SIP or MSRP headers. While it normally does protect the CPIM header, certain CPIM header fields may not be protected if the sender excludes them from the encrypted or signed part of the message. (See Section 9.1.) Certain messaging services -- for example, those based on RCS -- may include intermediaries that attach metadata to user-generated messages in the form of SIP, MSRP, or CPIM header fields. This metadata could possibly reveal information to third parties that the sender might prefer not to send as cleartext. Implementors and operators should consider whether inserted metadata may create privacy leaks. Such an analysis is beyond the scope of this document.
S / MIMEは通常、SIPまたはMSRPヘッダーを保護しません。通常はCPIMヘッダーを保護しますが、送信者がメッセージの暗号化または署名された部分からそれらを除外すると、特定のCPIMヘッダーフィールドが保護されない場合があります。 （セクション9.1を参照してください。）特定のメッセージングサービス（RCSに基づくサービスなど）には、SIP、MSRP、またはCPIMヘッダーフィールドの形式でユーザー生成メッセージにメタデータを添付する中間機能が含まれる場合があります。このメタデータは、送信者がクリアテキストとして送信することを望まない情報を第三者に明らかにする可能性があります。実装者とオペレーターは、挿入されたメタデータがプライバシーリークを引き起こす可能性があるかどうかを検討する必要があります。このような分析は、このドキュメントの範囲を超えています。
MSRP messages broken into chunks must be reassembled by the recipient prior to decrypting or validation of signatures. (See Section 8.1.) Section 14.5 of [RFC4975] describes a potential denial-of-service attack where the attacker puts large values in the Byte-Range header field. Implementations should sanity-check these values before allocating memory space for reassembly.
チャンクに分割されたMSRPメッセージは、署名を復号化または検証する前に、受信者が再構成する必要があります。 （セクション8.1を参照。）[RFC4975]のセクション14.5は、攻撃者がByte-Rangeヘッダーフィールドに大きな値を入力する潜在的なサービス拒否攻撃について説明しています。実装では、再アセンブリ用のメモリ空間を割り当てる前に、これらの値を健全性チェックする必要があります。
Modification of the ciphertext in EnvelopedData 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. This is one of the reasons for moving from EnvelopedData to AuthEnvelopedData, as the authenticated encryption algorithms provide the authentication without needing the SignedData layer.
EnvelopedData内の暗号文の変更は、認証も使用されていない場合に検出されない可能性があります。これは、SignedDataでラップしたり、SignedDataを含めたりせずにEnvelopedDataを送信する場合です。認証された暗号化アルゴリズムはSignedDataレイヤーを必要とせずに認証を提供するため、これがEnvelopedDataからAuthEnvelopedDataに移行する理由の1つです。
An attack on S/MIME implementations of HTML and multipart/mixed messages is highlighted in [Efail]. To avoid this attack, clients MUST ensure that a text/html content type is a complete HTML document. Clients SHOULD treat each of the different pieces of the multipart/mixed construct as coming from different origins. Clients MUST treat each encrypted or signed piece of a MIME message as being from different origins both from unprotected content and from each other.
HTMLおよびマルチパート/混合メッセージのS / MIME実装に対する攻撃は、[Efail]で強調表示されています。この攻撃を回避するには、クライアントはtext / htmlコンテンツタイプが完全なHTMLドキュメントであることを確認する必要があります。クライアントは、マルチパート/混合構成の異なる部分のそれぞれを異なる起源からのものとして扱う必要があります（SHOULD）。クライアントは、MIMEメッセージの暗号化または署名された各部分を、保護されていないコンテンツと相互の異なる発信元からのものとして扱う必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<https://www.rfc-editor.org / info / rfc3264>。
[RFC3428] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, DOI 10.17487/RFC3428, December 2002, <https://www.rfc-editor.org/info/rfc3428>.
[RFC3428] Campbell、B.、Ed。、Rosenberg、J.、Schulzrinne、H.、Huitema、C.、and D. Gurle、 "Session Initiation Protocol（SIP）Extension for Instant Messaging"、RFC 3428、DOI 10.17487 / RFC3428、2002年12月、<https://www.rfc-editor.org/info/rfc3428>。
[RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, DOI 10.17487/RFC3565, July 2003, <https://www.rfc-editor.org/info/rfc3565>.
[RFC3565] Schaad、J。、「暗号化メッセージ構文（CMS）でのAdvanced Encryption Standard（AES）暗号化アルゴリズムの使用」、RFC 3565、DOI 10.17487 / RFC3565、2003年7月、<https：//www.rfc-editor .org / info / rfc3565>。
[RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)", RFC 3853, DOI 10.17487/RFC3853, July 2004, <https://www.rfc-editor.org/info/rfc3853>.
[RFC3853] Peterson、J。、「Session Initiation Protocol（SIP）のS / MIME Advanced Encryption Standard（AES）要件」、RFC 3853、DOI 10.17487 / RFC3853、2004年7月、<https：//www.rfc-editor .org / info / rfc3853>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<https://www.rfc-editor.org/ info / rfc4566>。
[RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, DOI 10.17487/RFC4975, September 2007, <https://www.rfc-editor.org/info/rfc4975>.
[RFC4975] Campbell、B.、Ed。、Mahy、R.、Ed。、and C. Jennings、Ed。、 "The Message Session Relay Protocol（MSRP）"、RFC 4975、DOI 10.17487 / RFC4975、September 2007、< https://www.rfc-editor.org/info/rfc4975>。
[RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)", RFC 5084, DOI 10.17487/RFC5084, November 2007, <https://www.rfc-editor.org/info/rfc5084>.
[RFC5084] Housley、R。、「暗号化メッセージ構文（CMS）でのAES-CCMおよびAES-GCM認証済み暗号化の使用」、RFC 5084、DOI 10.17487 / RFC5084、2007年11月、<https：//www.rfc-editor .org / info / rfc5084>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, <https://www.rfc-editor.org/info/rfc5480>.
[RFC5480]ターナー、S。、ブラウン、D。、ユウ、K。、ハウズリー、R。、およびT.ポーク、「楕円曲線暗号化サブジェクト公開鍵情報」、RFC 5480、DOI 10.17487 / RFC5480、2009年3月、< https://www.rfc-editor.org/info/rfc5480>。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/info/rfc5652>.
[RFC5652] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、DOI 10.17487 / RFC5652、2009年9月、<https://www.rfc-editor.org/info/rfc5652>。
[RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January 2010, <https://www.rfc-editor.org/info/rfc5753>.
[RFC5753]ターナーS.およびD.ブラウン、「Cryptographic Message Syntax（CMS）での楕円曲線暗号（ECC）アルゴリズムの使用」、RFC 5753、DOI 10.17487 / RFC5753、2010年1月、<https：//www.rfc -editor.org/info/rfc5753>。
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January 2010, <https://www.rfc-editor.org/info/rfc5754>.
[RFC5754] Turner、S。、「Using SHA2 Algorithms with Cryptographic Message Syntax」、RFC 5754、DOI 10.17487 / RFC5754、2010年1月、<https://www.rfc-editor.org/info/rfc5754>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8418] Housley, R., "Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)", RFC 8418, DOI 10.17487/RFC8418, August 2018, <https://www.rfc-editor.org/info/rfc8418>.
[RFC8418] Housley、R。、「Cryptographic Message Syntax（CMS）でのX25519およびX448での楕円曲線Diffie-Hellman鍵合意アルゴリズムの使用」、RFC 8418、DOI 10.17487 / RFC8418、2018年8月、<https：// www.rfc-editor.org/info/rfc8418>。
[RFC8419] Housley, R., "Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS)", RFC 8419, DOI 10.17487/RFC8419, August 2018, <https://www.rfc-editor.org/info/rfc8419>.
[RFC8419] Housley、R。、「Cryptographic Message Syntax（CMS）でのEdwards-Curveデジタル署名アルゴリズム（EdDSA）署名の使用」、RFC 8419、DOI 10.17487 / RFC8419、2018年8月、<https：//www.rfc -editor.org/info/rfc8419>。
[RFC8550] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling", RFC 8550, DOI 10.17487/RFC8550, April 2019, <https://www.rfc-editor.org/info/rfc8550>.
[RFC8550] Schaad、J.、Ramsdell、B。、およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 4.0 Certificate Handling」、RFC 8550、DOI 10.17487 / RFC8550、2019年4月、<https： //www.rfc-editor.org/info/rfc8550>。
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[RFC8551] Schaad、J.、Ramsdell、B。、およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 4.0 Message Specification」、RFC 8551、DOI 10.17487 / RFC8551、2019年4月、<https： //www.rfc-editor.org/info/rfc8551>。
[X680] ITU-T, "Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, ISO/IEC 8824-1, August 2015, <https://www.itu.int/rec/T-REC-X.680>.
[X680] ITU-T、「情報技術-抽象構文記法1（ASN.1）：基本記法の仕様」、ITU-T勧告X.680、ISO / IEC 8824-1、2015年8月、<https：/ /www.itu.int/rec/T-REC-X.680>。
[X690] ITU-T, "Information Technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, August 2015, <https://www.itu.int/rec/T-REC-X.690/>.
[X690] ITU-T、「情報技術-ASN.1エンコーディングルール：基本エンコーディングルール（BER）、正規エンコーディングルール（CER）およびDistinguished Encodingルール（DER）の仕様」、ITU-T勧告X.690、 ISO / IEC 8825-1、2015年8月、<https://www.itu.int/rec/T-REC-X.690/>。
[CPM] Open Mobile Alliance, "OMA Converged IP Messaging System Description, Candidate Version 2.2", September 2017.
[CPM] Open Mobile Alliance、「OMA Converged IP Messaging System Description、Candidate Version 2.2」、2017年9月。
[Efail] Poddebniak, D., Dresen, C., Muller, J., Ising, F., Schinzel, S., Friedberger, S., Somorovsky, J., and J. Schwenk, "Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels", August 2018, <https://www.usenix.org/system/files/conference/ usenixsecurity18/sec18-poddebniak.pdf>.
[Efail] Poddebniak、D.、Dresen、C.、Muller、J.、Ising、F.、Shinzel、S.、Friedberger、S.、Somorovsky、J。、およびJ. Schwenk、「Efail：Breaking S / MIMEおよびOpenPGP Email Encryption With Exfiltration Channels」、2018年8月、<https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-poddebniak.pdf>。
[RCS] GSMA, "RCS Universal Profile Service Definition Document, Version 2.2", May 2018, <https://www.gsma.com/futurenetworks/wp-content/uploads/2018/05/ Universal-Profile-RCC.71-v2.2.pdf>.
[RCS] GSMA、「RCS Universal Profile Service Definition Document、バージョン2.2」、2018年5月、<https://www.gsma.com/futurenetworks/wp-content/uploads/2018/05/ Universal-Profile-RCC.71 -v2.2.pdf>。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, DOI 10.17487/RFC3325, November 2002, <https://www.rfc-editor.org/info/rfc3325>.
[RFC3325]ジェニングス、C。、ピーターソン、J。、およびM.ワトソン、「信頼できるネットワーク内のアサートされたIDのためのセッション開始プロトコル（SIP）のプライベート拡張」、RFC 3325、DOI 10.17487 / RFC3325、2002年11月、<https ：//www.rfc-editor.org/info/rfc3325>。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004, <https://www.rfc-editor.org/info/rfc3840>.
[RFC3840] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）でのユーザーエージェント機能の表示」、RFC 3840、DOI 10.17487 / RFC3840、2004年8月、<https：// www .rfc-editor.org / info / rfc3840>。
[RFC3860] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, DOI 10.17487/RFC3860, August 2004, <https://www.rfc-editor.org/info/rfc3860>.
[RFC3860] Peterson、J。、「Common Profile for Instant Messaging（CPIM）」、RFC 3860、DOI 10.17487 / RFC3860、2004年8月、<https://www.rfc-editor.org/info/rfc3860>。
[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, DOI 10.17487/RFC3862, August 2004, <https://www.rfc-editor.org/info/rfc3862>.
[RFC3862] Klyne、G。およびD. Atkins、「Common Presence and Instant Messaging（CPIM）：Message Format」、RFC 3862、DOI 10.17487 / RFC3862、2004年8月、<https://www.rfc-editor.org/ info / rfc3862>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<https://www.rfc-editor.org/info/rfc4648>。
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", RFC 4976, DOI 10.17487/RFC4976, September 2007, <https://www.rfc-editor.org/info/rfc4976>.
[RFC4976] Jennings、C.、Mahy、R。、およびA. Roach、「Relay Extensions for the Message Sessions Relay Protocol（MSRP）」、RFC 4976、DOI 10.17487 / RFC4976、2007年9月、<https：// www。 rfc-editor.org/info/rfc4976>。
[RFC5438] Burger, E. and H. Khartabil, "Instant Message Disposition Notification (IMDN)", RFC 5438, DOI 10.17487/RFC5438, February 2009, <https://www.rfc-editor.org/info/rfc5438>.
[RFC5438]バーガー、E.、H。カルタビル、「インスタントメッセージ処理通知（IMDN）」、RFC 5438、DOI 10.17487 / RFC5438、2009年2月、<https://www.rfc-editor.org/info/rfc5438> 。
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, DOI 10.17487/RFC6121, March 2011, <https://www.rfc-editor.org/info/rfc6121>.
[RFC6121] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Instant Messaging and Presence」、RFC 6121、DOI 10.17487 / RFC6121、2011年3月、<https://www.rfc-editor.org/ info / rfc6121>。
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7515]ジョーンズ、M。、ブラッドリー、J。、およびN.崎村、「JSON Web Signature（JWS）」、RFC 7515、DOI 10.17487 / RFC7515、2015年5月、<https://www.rfc-editor.org / info / rfc7515>。
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <https://www.rfc-editor.org/info/rfc7516>.
[RFC7516]ジョーンズ、M。およびJ.ヒルデブランド、「JSON Web Encryption（JWE）」、RFC 7516、DOI 10.17487 / RFC7516、2015年5月、<https://www.rfc-editor.org/info/rfc7516>。
[RFC7701] Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi-party Chat Using the Message Session Relay Protocol (MSRP)", RFC 7701, DOI 10.17487/RFC7701, December 2015, <https://www.rfc-editor.org/info/rfc7701>.
[RFC7701] Niemi、A.、Garcia-Martin、M。、およびG. Sandbakken、「メッセージセッションリレープロトコル（MSRP）を使用したマルチパーティチャット」、RFC 7701、DOI 10.17487 / RFC7701、2015年12月、<https： //www.rfc-editor.org/info/rfc7701>。
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC7748]ラングレー、A。、ハンブルク、M。、およびS.ターナー、「セキュリティのための楕円曲線」、RFC 7748、DOI 10.17487 / RFC7748、2016年1月、<https://www.rfc-editor.org/info / rfc7748>。
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/info/rfc8032>.
[RFC8032] Josefsson、S。およびI. Liusvaara、「Edwards-Curve Digital Signature Algorithm（EdDSA）」、RFC 8032、DOI 10.17487 / RFC8032、2017年1月、<https://www.rfc-editor.org/info/ rfc8032>。
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, February 2018, <https://www.rfc-editor.org/info/rfc8224>.
[RFC8224] Peterson、J.、Jennings、C.、Rescorla、E。、およびC. Wendt、「Session Initiation Protocol（SIP）での認証済みID管理」、RFC 8224、DOI 10.17487 / RFC8224、2018年2月、<https ：//www.rfc-editor.org/info/rfc8224>。
[RTP-Sec] Peterson, J., Barnes, R., and R. Housley, "Best Practices for Securing RTP Media Signaled with SIP", Work in Progress, draft-ietf-sipbrandy-rtpsec-08, April 2019.
[RTP-Sec] Peterson、J.、Barnes、R。、およびR. Housley、「SIPでシグナリングされるRTPメディアを保護するためのベストプラクティス」、作業中、draft-ietf-sipbrandy-rtpsec-08、2019年4月。
The following section shows the detailed content of the S/MIME bodies used in Section 10.
次のセクションでは、セクション10で使用されるS / MIME本文の詳細な内容を示します。
Figure 5 shows the details of the message signed by Alice used in the example in Section 10.1.
図5は、セクション10.1の例で使用されているアリスによって署名されたメッセージの詳細を示しています。
CMS_ContentInfo:
contentType: pkcs7-signedData (1.2.840.113549.1.7.2)
d.signedData:
version: 1
digestAlgorithms:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
encapContentInfo:
eContentType: pkcs7-data (1.2.840.113549.1.7.1)
eContent:
0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t
000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61 ext/plain....Wa
001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, come here
002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - I want to se
003c - 65 20 79 6f 75 2e 0d 0a- e you...
certificates:
d.certificate:
cert_info:
version: 2
serialNumber: 13292724773353297200
signature:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
issuer: O=example.com, CN=Alice
validity:
notBefore: Dec 19 23:12:05 2017 GMT
notAfter: Dec 19 23:12:05 2018 GMT
subject: O=example.com, CN=Alice
key:
algor:
algorithm: id-ecPublicKey (1.2.840.10045.2.1)
parameter: OBJECT:prime256v1 (1.2.840.10045.3.1.7)
public_key: (0 unused bits)
0000 - 04 d8 7b 54 72 9f 2c 22-fe eb d9 dd ba 0e ..{Tr.,"......
000e - fa 40 64 22 97 a6 09 38-87 a4 da e7 99 0b .@d"...8......
001c - 23 f8 7f a7 ed 99 db 8c-f5 a3 14 f2 ee 64 #............d
002a - 10 6e f1 ed 61 db fc 0a-4b 91 c9 53 cb d0 .n..a...K..S..
0038 - 22 a7 51 b9 14 80 7b b7-94 ".Q...{..
issuerUID: <ABSENT>
subjectUID: <ABSENT>
extensions:
object: X509v3 Subject Alternative Name (2.5.29.17)
critical: BOOL ABSENT
value:
0000 - 30 17 86 15 73 69 70 3a-61 6c 69 63 65 0...sip:alice
000d - 40 65 78 61 6d 70 6c 65-2e 63 6f 6d @example.com
sig_alg:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
signature: (0 unused bits)
0000 - 30 45 02 20 78 79 be 1c-27 f8 46 27 6f df 15 0E. xy..'.F'o..
000f - e3 33 e5 3c 6f 17 a7 57-38 8a 02 cb 7b 8a e4 .3.<o..W8...{..
001e - 81 c1 64 1a e7 a9 02 21-00 ff 99 cd 9c 94 07 ..d....!.......
002d - 6c 82 b0 2f ea 3b 13 50-17 9a 4b 77 52 e1 6f l../.;.P..KwR.o
003c - a3 0a 3f 9a b2 96 50 b0-e2 81 89 ..?...P....
crls:
<ABSENT>
signerInfos:
version: 1
d.issuerAndSerialNumber:
issuer: O=example.com, CN=Alice
serialNumber: 13292724773353297200
digestAlgorithm:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
signedAttrs:
object: contentType (1.2.840.113549.1.9.3)
set:
OBJECT:pkcs7-data (1.2.840.113549.1.7.1)
object: signingTime (1.2.840.113549.1.9.5)
set:
UTCTIME:Jan 24 23:52:56 2019 GMT
object: messageDigest (1.2.840.113549.1.9.4)
set:
OCTET STRING:
0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59 .w..@...%v.zY
000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2 .1&.Z.."z.._.
001a - 2c 05 0d 8d 19 5a ,....Z
signatureAlgorithm:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
signature:
0000 - 30 45 02 20 58 79 cc 62-85 e0 86 06 19 d3 bf 0E. Xy.b.......
000f - 53 d4 67 9f 03 73 d7 45-20 cf 56 10 c2 55 5b S.g..s.E .V..U[
001e - 7b ec 61 d4 72 dc 02 21-00 83 aa 53 44 28 4d {.a.r..!...SD(M
002d - 4c ef de 31 07 9c f9 71-bd 69 5d 6e c8 71 e9 L..1...q.i]n.q.
003c - a4 60 ec 2e 12 65 2b 77-a4 62 4d .`...e+w.bM
unsignedAttrs:
<ABSENT>
Figure 5: Signed Message
図5：署名されたメッセージ
Figure 6 shows the message signed by Alice with no embedded certificate, as used in the example in Section 10.2.
図6は、セクション10.2の例で使用されている、証明書が埋め込まれていないAliceによって署名されたメッセージを示しています。
CMS_ContentInfo:
contentType: pkcs7-signedData (1.2.840.113549.1.7.2)
d.signedData:
version: 1
digestAlgorithms:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
encapContentInfo:
eContentType: pkcs7-data (1.2.840.113549.1.7.1)
eContent:
0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t
000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61 ext/plain....Wa
001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, come here
002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - I want to se
003c - 65 20 79 6f 75 2e 0d 0a- e you...
certificates:
<ABSENT>
crls:
<ABSENT>
signerInfos:
version: 1
d.issuerAndSerialNumber:
issuer: O=example.com, CN=Alice
serialNumber: 13292724773353297200
digestAlgorithm:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
signedAttrs:
object: contentType (1.2.840.113549.1.9.3)
set:
OBJECT:pkcs7-data (1.2.840.113549.1.7.1)
object: signingTime (1.2.840.113549.1.9.5)
set:
UTCTIME:Jan 24 23:52:56 2019 GMT
object: messageDigest (1.2.840.113549.1.9.4)
set:
OCTET STRING:
0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59 .w..@...%v.zY
000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2 .1&.Z.."z.._.
001a - 2c 05 0d 8d 19 5a ,....Z
signatureAlgorithm:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
signature:
0000 - 30 44 02 20 1c 51 6e ed-9c 10 10 a2 87 e1 11 0D. .Qn........
000f - 6b af 76 1d f1 c4 e6 48-da ea 17 89 bc e2 8a k.v....H.......
001e - 9d 8a f4 a4 ae f9 02 20-72 7f 5e 4b cc e2 0b ....... r.^K...
002d - cf 3c af 07 c8 1c 11 64-f0 21 e7 70 e0 f6 a0 .<.....d.!.p...
003c - 96 2e 0a 7b 19 b7 42 ad-cb 34 ...{..B..4
unsignedAttrs:
<ABSENT>
Figure 6: Signed Message without Embedded Certificate
図6：埋め込み証明書なしの署名付きメッセージ
The following sections show details for the message signed by Bob and encrypted to Alice, as used in the examples in Sections 10.3 and 10.4.
次のセクションでは、セクション10.3および10.4の例で使用されている、ボブによって署名され、アリスに暗号化されたメッセージの詳細を示します。
CMS_ContentInfo:
contentType: pkcs7-signedData (1.2.840.113549.1.7.2)
d.signedData:
version: 1
digestAlgorithms:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
encapContentInfo:
eContentType: pkcs7-data (1.2.840.113549.1.7.1)
eContent:
0000 - 43 6f 6e 74 65 6e 74 2d-54 79 70 65 3a 20 74 Content-Type: t
000f - 65 78 74 2f 70 6c 61 69-6e 0d 0a 0d 0a 57 61 ext/plain....Wa
001e - 74 73 6f 6e 2c 20 63 6f-6d 65 20 68 65 72 65 tson, come here
002d - 20 2d 20 49 20 77 61 6e-74 20 74 6f 20 73 65 - I want to se
003c - 65 20 79 6f 75 2e 0d 0a- e you...
certificates:
d.certificate:
cert_info:
version: 2
serialNumber: 11914627415941064473
signature:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
issuer: O=example.org, CN=Bob
validity:
notBefore: Dec 20 23:07:49 2017 GMT
notAfter: Dec 20 23:07:49 2018 GMT
subject: O=example.org, CN=Bob
key:
algor:
algorithm: id-ecPublicKey (1.2.840.10045.2.1)
parameter: OBJECT:prime256v1 (1.2.840.10045.3.1.7)
public_key: (0 unused bits)
0000 - 04 86 4f ff fc 53 f1 a8-76 ca 69 b1 7e 27 ..O..S..v.i.~'
000e - 48 7a 07 9c 71 52 ae 1b-13 7e 39 3b af 1a Hz..qR...~9;..
001c - ae bd 12 74 3c 7d 41 43-a2 fd 8a 37 0f 02 ...t<}AC...7..
002a - ba 9d 03 b7 30 1f 1d a6-4e 30 55 94 bb 6f ....0...N0U..o
0038 - 95 cb 71 fa 48 b6 d0 a3-83 ..q.H....
issuerUID: <ABSENT>
subjectUID: <ABSENT>
extensions:
object: X509v3 Subject Alternative Name (2.5.29.17)
critical: TRUE
value:
0000 - 30 15 86 13 73 69 70 3a-62 6f 62 40 65 0...sip:bob@e
000d - 78 61 6d 70 6c 65 2e 6f-72 67 xample.org
sig_alg:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
signature: (0 unused bits)
0000 - 30 45 02 21 00 b2 24 8c-92 40 28 22 38 9e c9 0E.!..$..@("8..
000f - 25 7f 64 cc fd 10 6f ba-0b 96 c1 19 07 30 34 %.d...o......04
001e - d5 1b 10 2f 73 39 6c 02-20 15 8e b1 51 f0 85 .../s9l. ...Q..
002d - b9 bd 2e 04 cf 27 8f 0d-52 2e 6b b6 fe 4f 36 .....'..R.k..O6
003c - f7 4c 77 10 b1 5a 4f 47-9d e4 0d .Lw..ZOG...
crls:
<ABSENT>
signerInfos:
version: 1
d.issuerAndSerialNumber:
issuer: O=example.org, CN=Bob
serialNumber: 11914627415941064473
digestAlgorithm:
algorithm: sha256 (2.16.840.1.101.3.4.2.1)
parameter: <ABSENT>
signedAttrs:
object: contentType (1.2.840.113549.1.9.3)
set:
OBJECT:pkcs7-data (1.2.840.113549.1.7.1)
object: signingTime (1.2.840.113549.1.9.5)
set:
UTCTIME:Jan 24 23:52:56 2019 GMT
object: messageDigest (1.2.840.113549.1.9.4)
set:
OCTET STRING:
0000 - ef 77 8f c9 40 d5 e6 dc-25 76 f4 7a 59 .w..@...%v.zY
000d - 9b 31 26 19 5a 9f 1a 22-7a da f3 5f a2 .1&.Z.."z.._.
001a - 2c 05 0d 8d 19 5a ,....Z
signatureAlgorithm:
algorithm: ecdsa-with-SHA256 (1.2.840.10045.4.3.2)
parameter: <ABSENT>
signature:
0000 - 30 45 02 21 00 f7 88 ed-44 6a b7 0f ff 2c 1f 0E.!....Dj...,.
000f - fa 4c 03 74 fd 08 77 fd-61 ee 91 7c 31 45 b3 .L.t..w.a..|1E.
001e - 89 a6 76 15 c7 46 fa 02-20 77 94 ad c5 7f 00 ..v..F.. w.....
002d - 61 c7 84 b9 61 23 cc 6e-54 bb 82 82 65 b6 d4 a...a#.nT...e..
003c - cc 12 99 76 a6 b1 fc 6d-bc 28 d6 ...v...m.(.
unsignedAttrs:
<ABSENT>
Figure 7: Message Signed by Bob prior to Encryption
図7：暗号化の前にボブが署名したメッセージ
CMS_ContentInfo:
contentType: pkcs7-authEnvelopedData (1.2.840.113549.1.9.16.1.23)
d.authEnvelopedData:
version: 0
originatorInfo: <ABSENT>
recipientInfos:
d.ktri:
version: <ABSENT>
d.issuerAndSerialNumber:
issuer: O=example.com, CN=Alice
serialNumber: 9508519069068149774
keyEncryptionAlgorithm:
algorithm: rsaEncryption (1.2.840.113549.1.1.1)
parameter: NULL
encryptedKey:
0000 - 75 9a 61 b4 dd f1 f1 af-24 66 80 05 63 5e 47 u.a.....$f..c^G
000f - 61 10 fa 27 23 c1 b9 e4-54 84 b6 d3 3e 83 87 a..'#...T...>..
001e - de 96 7d c5 e0 ca fb 35-57 1a 56 a1 97 5c b5 ..}....5W.V..\.
002d - 50 e7 be 31 c1 31 da 80-fb 73 10 24 84 5b ab P..1.1...s.$.[.
003c - b8 d6 4c ac 26 04 04 24-d9 33 05 61 c8 43 99 ..L.&..$.3.a.C.
004b - 94 15 dd 64 4b 3c ad 95-07 2f 71 45 13 93 c9 ...dK<.../qE...
005a - 9f 28 2c 48 83 bd 0c cc-5d d5 4b 93 14 64 e0 .(,H....].K..d.
0069 - 0a 6e 55 e5 92 c5 1a 68-de 10 62 51 6e c7 d3 .nU....h..bQn..
0078 - ca 8e 76 4b b8 ac 78 9a-88 37 77 65 ef 8d c3 ..vK..x..7we...
0087 - 6c 0a 6e d3 ec ae 52 85-ca c6 a2 9d 50 59 44 l.n...R.....PYD
0096 - 57 19 a1 bd cf 90 6e 0f-f3 7e 2c 2e f0 f4 ec W.....n..~,....
00a5 - 62 25 10 0c c0 62 e1 c7-48 96 3b bc 88 b8 e3 b%...b..H.;....
00b4 - df cf 71 40 73 72 9d d5-c7 58 3e 75 8a cf 3d ..q@sr...X>u..=
00c3 - 18 6f 2f a4 17 be 22 c3-7c 9a 76 c6 b4 27 29 .o/...".|.v..')
00d2 - aa d2 7f 73 ae 44 ac 98-47 4d 1e eb 48 94 8c ...s.D..GM..H..
00e1 - 12 a4 03 d0 b3 ce 08 a2-18 d6 af 45 69 24 89 ...........Ei$.
00f0 - 7c c5 c9 66 4f 6d fe b3-f1 81 41 15 8d fc 3b |..fOm....A...;
00ff - 84 09 0a a6 03 80 aa 86-51 37 e1 69 9c 5c 81 ........Q7.i.\.
010e - 97 41 67 9d 7a 3c 90 ba-79 e6 d7 d5 c8 d8 9b .Ag.z<..y......
011d - b5 4a 66 74 23 e4 3b 0b-7d 6f 78 c0 b4 ab 67 .Jft#.;.}ox...g
012c - bc 34 36 62 a6 35 fe 59-5f 11 49 c5 39 50 ca .46b.5.Y_.I.9P.
013b - c2 e0 ba 31 8c 22 7e 6f-76 a8 d9 40 40 0f d3 ...1."~ov..@@..
014a - d3 ea 1c 8e ce a0 03 dc-ce 2f 1f b0 0f 5c ea ........./...\.
0159 - 33 5d e1 30 3f cb f9 3d-8e 1c bf d6 82 f1 9b 3].0?..=.......
0168 - eb 62 4b ac d1 d7 b8 f5-80 f1 14 a1 3b 89 08 .bK.........;..
0177 - 94 fb 40 44 a5 da a7 64-b7 f8 c5 ff 92 94 94 ..@D...d.......
0186 - 52 b3 5a eb 96 39 b8 ad-63 c0 51 5c 95 cc c6 R.Z..9..c.Q\...
0195 - f8 23 c2 20 10 67 ea 22-62 41 3f ef 39 7d 48 .#. .g."bA?.9}H
01a4 - f7 b6 14 3f 84 2a e8 e1-a4 8c ad 3a e0 1a ba ...?.*.....:...
01b3 - a3 cf 9e e7 e3 66 20 e0-5c ca 06 11 bf ac 00 .....f .\......
01c2 - ee f1 a4 98 f2 d2 59 b9-f0 f7 da 83 ef 6f 1b ......Y......o.
01d1 - 06 1f 38 7c 2d c4 8c 8b-5d ba ca 86 23 08 f3 ..8|-...]...#..
01e0 - 2f 47 92 51 65 c9 e5 eb-b4 67 79 98 84 91 8d /G.Qe....gy....
01ef - d6 97 b4 47 f4 c4 07 98-9b 88 9b 0c 2e 95 80 ...G...........
01fe - af 78 .x
authEncryptedContentInfo:
contentType: pkcs7-data (1.2.840.113549.1.7.1)
contentEncryptionAlgorithm:
algorithm: aes-128-gcm (2.16.840.1.101.3.4.1.6)
parameter:
aes-nonce:
0000 - 4d 87 57 22 2e ac 52 94-11 7f 0c 12 M.W"..R.....
aes-ICVlen: 16
encryptedContent:
0000 - fe 2f b3 de 0b f0 69 98-c3 9b f4 a9 52 fa bf ./....i.....R..
000f - 8b 0f ee 3d 7e 2e 85 18-1a ec f1 a8 9e 1a 2e ...=~..........
001e - de cd 94 04 88 56 12 df-c6 98 43 34 d8 60 2b .....V....C4..+
002d - 77 49 b2 50 4e 45 f5 7c-3b 06 66 26 b0 fc 74 wI.PNE.|..f&..t
003c - 62 36 1e ec 26 7c 56 01-39 be 5c d2 86 a2 af b6..&|V.9.\....
004b - 96 96 cf 51 85 22 78 e5-2c 38 18 ca b0 a6 8c ...Q."x.,8.....
005a - 59 8d e4 fc e1 4a 33 38-84 e4 de 5d df 57 ed Y....J38...].W.
0069 - d7 88 67 02 7a 31 e4 a7-c0 c0 29 91 44 c5 de ..g.z1....).D..
0078 - 6b ae 39 69 9e 70 0e 05-7e b0 f0 da d7 3b 8b k.9i.p..~......
0087 - 36 9f 42 eb 32 1b 41 53-87 81 d9 82 a1 1a 0b 6.B.2.AS.......
0096 - 39 43 ac 10 c9 7b 54 ee-b7 3b 38 ec 13 1a fc 9C...{T...8....
00a5 - 56 10 e3 73 48 72 74 d6-9c af a9 54 19 02 88 V..sHrt....T...
00b4 - 6c 64 f6 96 2d 42 eb 33-f9 04 1a 4a e1 1b 88 ld..-B.3...J...
00c3 - dc 69 58 d5 3d f5 0b 8b-b5 2a a3 5e 22 99 88 .iX.=....*.^"..
00d2 - 5d 0a ae 41 6b 86 f0 a8-8d 0e b7 a9 81 db b2 ]..Ak..........
00e1 - 83 e8 b9 4e 9d 50 bf 62-65 c2 34 8a 18 a1 69 ...N.P.be.4...i
00f0 - aa cb 5a 37 a5 29 bd a2-f9 cb 10 ef dd cf 14 ..Z7.).........
00ff - 23 10 95 d8 79 64 63 7b-d3 3f b1 3c 68 b4 cf #...ydc{.?.<h..
010e - f9 a1 90 69 60 c1 ea 23-01 d3 25 b7 a1 5c 58 ...i...#..%..\X
011d - 29 f3 ea 03 8f 24 df 6b-23 18 03 77 d3 71 31 )....$.k#..w.q1
012c - f7 5d b1 8f 41 f9 d8 5b-65 3d fa 46 bf 26 17 .]..A..[e=.F.&.
013b - 12 63 26 cc f1 cb 83 34-57 75 23 52 c8 41 7a .c&....4Wu#R.Az
014a - 09 44 84 d7 b6 4b cf 51-b2 6a 9b eb 3a 0e d4 .D...K.Q.j..:..
0159 - b9 ca f1 bd 23 c6 90 c6-54 f7 eb 9c e9 85 2e ....#...T......
0168 - 2f 6d 06 8e ef 8b a3 3b-c6 c4 dd dc a7 ae f4 /m.............
0177 - d3 57 47 37 d7 c4 dc 1e-93 77 0d 8f 4f 22 de .WG7.....w..O".
0186 - a6 1d 73 08 3c 32 c4 03-8c 1e b3 dd 33 83 a8 ..s.<2......3..
0195 - 9a 87 95 e2 41 c2 ed 7c-b6 80 75 8c 04 10 69 ....A..|..u...i
01a4 - 48 98 60 fc 9f 49 0e 85-23 60 72 54 8b 32 49 H....I..#.rT.2I
01b3 - 69 8f 99 95 3a cf 1e c6-58 b7 aa 85 e5 54 c4 i...:...X....T.
01c2 - 49 70 1a 6d 4b 03 9e d1-03 dc 45 8d f4 b2 9c Ip.mK.....E....
01d1 - b0 4b 8c ed d5 40 c8 43-48 da 79 c1 86 56 d5 .K...@.CH.y..V.
01e0 - 18 8f 9f 3a 9e 4b 9b 84-0c 70 66 4b 90 29 6c ...:.K...pfK.)l
01ef - 60 b7 ac 98 4e 91 8d 48-a0 9d bd df b2 81 fc ....N..H.......
01fe - 86 25 10 db 59 d9 fa 9d-c9 3f 10 f9 c6 d7 be .%..Y....?.....
020d - f7 29 31 d1 84 ca d7 ac-13 c1 a5 29 5f c8 9f .)1........)_..
021c - e3 bb 7e b8 e0 20 85 a8-28 c5 a1 38 78 6e 60 ..~.....(..8xn.
022b - 7a de 4f 5e 8d 41 15 90-92 09 ba 87 8a 79 30 z.O^.A.......y0
023a - 5a 53 16 c2 22 29 e4 2b-88 6d 06 48 1c 84 73 ZS..").+.m.H..s
0249 - f9 d5 12 69 e2 af 63 41-bc e2 0f 76 8e 86 0d ...i..cA...v...
0258 - 77 84 ed 46 15 0e 04 ff-50 cd 20 9c 5b 12 75 w..F....P...[.u
0267 - 11 36 9f e0 6b c4 aa 9a-72 d8 f1 fe 4f cf 08 .6..k...r...O..
0276 - 66 d6 64 b3 65 ff a8 6e-8c 1b 43 e7 a9 21 2a f.d.e..n..C..!*
0285 - ec c1 6c a3 50 a2 8e fa-e2 5f ac 05 4d d9 34 ..l.P...._..M.4
0294 - bf e7 e5 fa 4f 75 3a a4-15 96 8c 7e be c4 39 ....Ou:....~..9
02a3 - e0 ac 02 70 b4 87 4a 06-8d 22 48 4c 09 d9 e8 ...p..J.."HL...
02b2 - ab e1 7f 13 72 b4 b2 f6-5f 11 48 e8 93 3e da ....r..._.H..>.
02c1 - 92 e5 d1 77 45 64 96 3b-39 1c 3b bd 9f 1c 27 ...wEd..9......
02d0 - ff e3 6f 83 2e 05 15 5f-c3 9e e6 65 2f a7 b4 ..o...._...e/..
02df - 18 89 75 ec 5c 67 b3 2c-9f 21 3c 8a c6 b8 e1 ..u.\g.,.!<....
02ee - 32 a5 a7 c3 bf 74 f0 16-40 5c d8 c2 01 d1 05 2....t..@\.....
02fd - 21 93 e1 86 d4 43 58 de-38 8d 73 21 1b a2 f1 !....CX.8.s!...
030c - 79 2f 3c fe b9 bb de 72-11 d2 6f 56 ab 06 e1 y/<....r..oV...
031b - 1c cc 9c cd e2 b8 8c d8-37 37 73 ea fc 37 fd ........77s..7.
032a - 85 b7 a7 a2 bc ae c7 52-e6 17 d6 e0 1c 02 b8 .......R.......
0339 - 6e 9d 9a 40 f3 20 46 2c-5d 66 f8 35 17 16 dc n..@..F,]f.5...
0348 - d6 01 4b df 30 a6 0f 75-fc 06 31 c9 20 84 5e ..K.0..u..1...^
0357 - d8 c0 ba d3 5d df 19 84-f2 24 1c d3 b5 29 dc ....]....$...).
0366 - 10 28 84 5f 80 89 54 3d-f4 f1 44 1e de 36 b1 .(._..T=..D..6.
0375 - bf 31 af 5a fc 8c 2b 70-8d 50 b6 45 d4 e7 db .1.Z..+p.P.E...
0384 - 88 64 8c 3e ef e1 47 65-15 8f b0 e8 d3 bb 53 .d.>..Ge......S
0393 - dd cb e2 6d 71 24 c6 e1-d9 92 f8 32 30 aa 95 ...mq$.....20..
03a2 - 33 76 ee 8c 68 10 95 68-e8 57 1f 0c 9b bd a4 3v..h..h.W.....
03b1 - 8f 4d f3 06 fe 74 7f 37-11 75 14 8f 31 83 27 .M...t.7.u..1..
03c0 - 67 cd 76 6c f0 7b 45 0c-bf 62 ca d2 a7 bd 71 g.vl.{E..b....q
03cf - f1 f8 82 33 f1 16 a1 a7-f3 ca f1 2f 34 bc f4 ...3......./4..
03de - 0d 21 e7 9f fc 98 27 22-1b 68 b0 80 ff 03 ad .!.....".h.....
03ed - 78 2d 6d 6d 07 87 16 76-f7 98 94 3e 54 f1 3f x-mm...v...>T.?
03fc - d7 5c 89 c0 b4 26 3b f1-0f 56 24 3f 9e 72 ef .\...&...V$?.r.
040b - 3b 38 99 a5 39 d9 a3 ac-5b e2 b6 94 00 a3 cf .8..9...[......
041a - 8d 19 6c 5c ed 69 7b 2e-d8 03 b9 87 a5 ee 85 ..l\.i{........
0429 - c5 09 5b 48 da 7a 5b 03-b4 7e 2b 9f e4 cd 4b ..[H.z[..~+...K
0438 - c3 09 8e 86 4e 0c e7 d4-67 da 99 cd 7f 3a 9e ....N...g....:.
0447 - 94 7b 5e ea 77 f7 a6 be-16 c8 c7 e9 e0 de cc .{^.w..........
0456 - 1f f1 32 55 9c 23 43 21-7b 9c 29 50 38 6e 85 ..2U.#C!{.)P8n.
0465 - d2 94 21 21 08 6c df a1-96 58 19 5b e6 d7 f8 ..!!.l...X.[...
0474 - 6b ca 98 81 b6 95 08 29-64 f1 2e 7c f8 01 02 k......)d..|...
0483 - 5d 67 92 c6 88 24 09 41-4d 70 33 21 ec 83 ab ]g...$.AMp3!...
0492 - d6 98 d6 89 56 11 87 13-a0 ff 12 72 ac bc 9a ....V......r...
04a1 - 6d 14 89 00 c7 4c 16 92-1d f9 b3 8f 29 ec 46 m....L......).F
04b0 - d4 f1 00 60 ff fe 5e 36-bb ba ca f2 d1 ba d7 ......^6.......
04bf - dd 05 7e d3 e3 0e bc d6-90 83 f9 d3 a2 a2 6e ..~...........n
04ce - f9 0b 75 1d 6a 1a df a0-59 0d b1 9d a1 07 cf ..u.j...Y......
04dd - 3e a8 db >..
authAttrs:
<EMPTY>
mac:
0000 - f6 ff c6 e1 ae f1 9c d2-3d 98 5a 92 19 76 35 ........=.Z..v5
000f - 2d -
unauthAttrs:
<EMPTY>
Figure 8: Message Encrypted by Bob for Alice
図8：ボブがアリスのために暗号化したメッセージ
Authors' Addresses
著者のアドレス
Ben Campbell Standard Velocity, LLC
ベンキャンベルスタンダードベロシティLLC
Email: ben@nostrum.com
Russ Housley Vigil Security, LLC
Russ Housley Vigil Security、LLC
Email: housley@vigilsec.com