[要約] RFC 7281は、S/MIME署名の検証結果を示すためのAuthentication-Resultsレジストリの登録に関するものです。その目的は、S/MIMEメッセージの署名検証結果を一貫した形式で報告するための標準化を提供することです。
Independent Submission A. Melnikov
Request for Comments: 7281 Isode Ltd
Category: Informational June 2014
ISSN: 2070-1721
Authentication-Results Registration for S/MIME Signature Verification
S / MIME署名検証のための認証結果の登録
Abstract
概要
RFC 7001 specifies the Authentication-Results header field for conveying results of message authentication checks. This document defines a new authentication method to be used in the Authentication-Results header field for S/MIME-related signature checks.
RFC 7001は、メッセージ認証チェックの結果を伝えるためのAuthentication-Resultsヘッダーフィールドを指定しています。このドキュメントでは、S / MIME関連の署名チェックのAuthentication-Resultsヘッダーフィールドで使用される新しい認証方法を定義します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7281.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7281で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. "smime" Authentication Method ...................................2
3.1. S/MIME Results .............................................3
3.2. Email Authentication Parameters for S/MIME .................4
3.2.1. body.smime-part .....................................4
3.2.2. body.smime-identifier ...............................4
3.2.3. body.smime-serial and body.smime-issuer .............5
3.3. Examples ...................................................5
4. IANA Considerations .............................................7
5. Security Considerations .........................................9
6. References .....................................................10
6.1. Normative References ......................................10
6.2. Informative References ....................................10
Appendix A. Acknowledgements ......................................11
[RFC7001] specifies the Authentication-Results header field for conveying results of message authentication checks. As S/MIME signature verification (and alteration) is sometimes implemented in border message transfer agents, guards, and gateways (for example, see [RFC3183]), there is a need to convey signature verification status to Mail User Agents (MUAs) and downstream filters. This document defines a new authentication method to be used in the Authentication-Results header field for S/MIME-related signature checks.
[RFC7001]は、メッセージ認証チェックの結果を伝えるためのAuthentication-Resultsヘッダーフィールドを指定します。 S / MIME署名検証（および変更）は、ボーダーメッセージ転送エージェント、ガード、およびゲートウェイ（たとえば、[RFC3183]を参照）に実装されることがあるので、署名検証ステータスをメールユーザーエージェント（MUA）に伝える必要があります。下流フィルター。このドキュメントでは、S / MIME関連の署名チェックのAuthentication-Resultsヘッダーフィールドで使用される新しい認証方法を定義します。
The formal syntax uses the Augmented Backus-Naur Form (ABNF) [RFC5234] notation, including the core rules defined in Appendix B of [RFC5234].
正式な構文は、[RFC5234]の付録Bで定義されているコアルールを含むAugmented Backus-Naur Form（ABNF）[RFC5234]表記を使用しています。
S/MIME signature and countersignature verification is represented by the "smime" method and is defined in [RFC5751].
S / MIME署名と副署名の検証は「smime」メソッドで表され、[RFC5751]で定義されています。
The result values used by S/MIME [RFC5751] are as follows:
S / MIME [RFC5751]で使用される結果値は次のとおりです。
+-----------+-------------------------------------------------------+
| Result | Meaning |
| code | |
+-----------+-------------------------------------------------------+
| none | The message was not signed. |
| | |
| pass | The message was signed, the signature or signatures |
| | were acceptable to the verifier, and the signature(s) |
| | passed verification tests. |
| | |
| fail | The message was signed and the signature or |
| | signatures were acceptable to the verifier, but they |
| | failed the verification test(s). |
| | |
| policy | The message was signed and signature(s) passed |
| | verification tests, but the signature or signatures |
| | were not acceptable to the verifier. |
| | |
| neutral | The message was signed but the signature or |
| | signatures contained syntax errors or were not |
| | otherwise able to be processed. This result is also |
| | used for other failures not covered elsewhere in this |
| | list. |
| | |
| temperror | The message could not be verified due to some error |
| | that is likely transient in nature, such as a |
| | temporary inability to retrieve a certificate or |
| | Certificate Revocation List (CRL). A later attempt |
| | may produce a final result. |
| | |
| permerror | The message could not be verified due to some error |
| | that is unrecoverable, such as a required header |
| | field being absent or the signer's certificate not |
| | being available. A later attempt is unlikely to |
| | produce a final result. |
+-----------+-------------------------------------------------------+
A signature is "acceptable to the verifier" if it passes local policy checks (or there are no specific local policy checks). For example, a verifier might require that the domain in the rfc822Name subjectAltName in the signing certificate matches the domain in the address of the sender of the message (value of the Sender header field, if present; value of the From header field otherwise), thus making third-party signatures unacceptable. [RFC5751] advises that if a message fails verification, it should be treated as an unsigned message. A report of "fail" here permits the receiver of the report to decide how to handle the failure. A report of "neutral" or "none" preempts that choice, ensuring that the message will be treated as if it had not been signed.
ローカルポリシーチェックに合格した場合（または特定のローカルポリシーチェックがない場合）、署名は「検証者に受け入れられます」。たとえば、検証者は、署名証明書のrfc822Name subjectAltNameのドメインがメッセージの送信者のアドレスのドメインと一致することを要求する場合があります（存在する場合はSenderヘッダーフィールドの値、それ以外の場合はFromヘッダーフィールドの値）。したがって、サードパーティの署名が受け入れられなくなります。 [RFC5751]は、メッセージが検証に失敗した場合、署名されていないメッセージとして扱われるべきであるとアドバイスしています。ここでの「失敗」のレポートにより、レポートの受信者は失敗の処理方法を決定できます。 「中立」または「なし」のレポートはその選択よりも優先され、メッセージが署名されていないかのように扱われることを保証します。
This document defines several new authentication parameters for conveying S/MIME-related information, such as the location of an S/MIME signature and the identity associated with the entity that signed the message or one of its body parts.
このドキュメントでは、S / MIME署名の場所や、メッセージに署名したエンティティまたはその本文部分の1つに関連付けられたIDなど、S / MIME関連情報を伝達するためのいくつかの新しい認証パラメーターを定義します。
body.smime-part contains the MIME body part reference that contains the S/MIME signature. The syntax of this property is described by the smime-part ABNF production below. application/pkcs7-signature or application/pkcs7-mime (containing SignedData) media type body parts are referenced using the <section> syntax (see Section 6.4.5 of [RFC3501]). If the signature being verified is encapsulated by another Cryptographic Message Syntax (CMS) content type (e.g., application/pkcs7-mime containing EnvelopedData, which contains SignedData), such an inner signature body part can be referenced using "section[/section..." syntax.
body.smime-partには、S / MIME署名を含むMIMEボディパーツ参照が含まれています。このプロパティの構文は、以下のsmime-part ABNFプロダクションで説明されています。 application / pkcs7-signatureまたはapplication / pkcs7-mime（SignedDataを含む）メディアタイプボディパーツは、<section>構文を使用して参照されます（[RFC3501]のセクション6.4.5を参照）。検証中の署名が別の暗号メッセージ構文（CMS）コンテンツタイプ（たとえば、SignedDataを含むEnvelopedDataを含むapplication / pkcs7-mime）によってカプセル化されている場合、このような内部署名の本文部分は「section [/ section .. 。 "構文。
smime-part = section ["/" smime-subpart]
smime-subpart = smime-part
section = <Defined in Section 6.4.5 of [RFC3501]>
body.smime-identifier contains the email address [RFC5322] associated with the S/MIME signature referenced in the corresponding body.smime-part. The email address can be specified explicitly in the signer's X.509 certificate or derived from the identity of the signer. Note that this email address can correspond to a countersignature.
body.smime-identifierには、対応するbody.smime-partで参照されるS / MIME署名に関連付けられた電子メールアドレス[RFC5322]が含まれています。電子メールアドレスは、署名者のX.509証明書で明示的に指定するか、署名者のIDから取得できます。このメールアドレスは副署に対応している場合があります。
body.smime-serial contains the serialNumber of the X.509 certificate associated with the S/MIME signature (see Section 4.1.2.2 of [RFC5280]) referenced in the corresponding body.smime-part.
body.smime-serialには、対応するbody.smime-partで参照されるS / MIME署名（[RFC5280]のセクション4.1.2.2を参照）に関連付けられたX.509証明書のserialNumberが含まれます。
body.smime-issuer contains the issuer name DN (distinguished name) (e.g., "CN=CA1,ST=BC,c=CA") of the X.509 certificate associated with the S/MIME signature (see Section 4.1.2.4 of [RFC5280]) referenced in the corresponding body.smime-part.
body.smime-issuerには、S / MIME署名に関連付けられたX.509証明書の発行者名DN（識別名）（たとえば、「CN = CA1、ST = BC、c = CA」）が含まれています（セクション4.1.2.4を参照） [RFC5280]の）対応するbody.smime-partで参照されます。
Either both or neither of body.smime-serial and body.smime-issuer should be present in an Authentication-Results header field.
body.smime-serialとbody.smime-issuerの両方またはどちらも、Authentication-Resultsヘッダーフィールドに存在する必要があります。
body.smime-serial and body.smime-issuer are used for cases when body.smime-identifier (email address) can't be derived by the entity adding the corresponding Authentication-Results header field. For example, this can be used when gatewaying from X.400.
body.smime-serialとbody.smime-issuerは、対応するAuthentication-Resultsヘッダーフィールドを追加するエンティティによってbody.smime-identifier（メールアドレス）を取得できない場合に使用されます。たとえば、これはX.400からゲートウェイ処理するときに使用できます。
Return-Path: <aliceDss@example.com>
Authentication-Results: example.net;
smime=fail (certificate is revoked by CRL)
body.smime-identifier=aliceDss@example.com
body.smime-part=2
Received: from ietfa.example.com (localhost [IPv6:::1])
by ietfa.example.com (Postfix) with ESMTP id 2875111E81A0;
Fri, 06 Sep 2002 00:35:14 -0700 (PDT)
MIME-Version: 1.0
To: User2@example.com
From: aliceDss@example.com
Subject: Example 4.8
Message-Id: <020906002550300.249@example.com>
Date: Fri, 06 Sep 2002 00:25:21 -0700
Content-Type: multipart/signed;
micalg=SHA1;
boundary="----=_NextBoundary____Fri,_06_Sep_2002_00:25:21";
protocol="application/pkcs7-signature"
This is a multi-part message in MIME format.
これはMIME形式のマルチパートメッセージです。
------=_NextBoundary____Fri,_06_Sep_2002_00:25:21
This is some sample content.
------=_NextBoundary____Fri,_06_Sep_2002_00:25:21
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
MIIDdwYJKoZIhvcNAQcCoIIDaDCCA2QCAQExCTAHBgUrDgMCGjALBgkqhkiG9w0BBwGgggL
gMIIC3DCCApugAwIBAgICAMgwCQYHKoZIzjgEAzASMRAwDgYDVQQDEwdDYXJsRFNTMB4XDT
k5MDgxNzAxMTA0OVoXDTM5MTIzMTIzNTk1OVowEzERMA8GA1UEAxMIQWxpY2VEU1MwggG2M
IIBKwYHKoZIzjgEATCCAR4CgYEAgY3N7YPqCp45PsJIKKPkR5PdDteoDuxTxauECE//lOFz
SH4M1vNESNH+n6+koYkv4dkwyDbeP5u/t0zcX2mK5HXQNwyRCJWb3qde+fz0ny/dQ6iLVPE
/sAcIR01diMPDtbPjVQh11Tl2EMR4vf+dsISXN/LkURu15AmWXPN+W9sCFQDiR6YaRWa4E8
baj7g3IStii/eTzQKBgCY40BSJMqo5+z5t2UtZakx2IzkEAjVc8ssaMMMeUF3dm1nizaoFP
VjAe6I2uG4Hr32KQiWn9HXPSgheSz6Q+G3qnMkhijt2FOnOLl2jB80jhbgvMAF8bUmJEYk2
RL34yJVKU1a14vlz7BphNh8Rf8K97dFQ/5h0wtGBSmA5ujY5A4GEAAKBgFzjuVp1FJYLqXr
d4z+p7Kxe3L23ExE0phaJKBEj2TSGZ3V1ExI9Q1tv5VG/+onyohs+JH09B41bY8i7RaWgSu
OF1s4GgD/oI34a8iSrUxq4Jw0e7wi/ZhSAXGKsZfoVi/G7NNTSljf2YUeyxDKE8H5BQP1Gp
2NOM/Kl4vTyg+W4o4GBMH8wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0j
BBgwFoAUcEQ+gi5vh95K03XjPSC8QyuT8R8wHQYDVR0OBBYEFL5sobPjwfftQ3CkzhMB4v3
jl/7NMB8GA1UdEQQYMBaBFEFsaWNlRFNTQGV4YW1wbGUuY29tMAkGByqGSM44BAMDMAAwLQ
IUVQykGR9CK4lxIjONg2q1PWdrv0UCFQCfYVNSVAtcst3a53Yd4hBSW0NevTFjMGECAQEwG
DASMRAwDgYDVQQDEwdDYXJsRFNTAgIAyDAHBgUrDgMCGjAJBgcqhkjOOAQDBC4wLAIUM/mG
f6gkgp9Z0XtRdGimJeB/BxUCFGFFJqwYRt1WYcIOQoGiaowqGzVI
------=_NextBoundary____Fri,_06_Sep_2002_00:25:21--
IANA has added the following entries to the "Email Authentication Methods" sub-registry of the "Email Authentication Parameters" registry:
IANAは、「Email Authentication Parameters」レジストリの「Email Authentication Methods」サブレジストリに次のエントリを追加しました。
+------+----------+-------+------------+----------------+-------+------+
|Method| Defined | ptype | Property | Value |Status | Ver- |
| | in | | | | | sion |
+------+----------+-------+------------+----------------+-------+------+
| smime| [RFC5751]| body | smime-part | A reference to |active | 1 |
| | | | | the MIME body | | |
| | | | | part that | | |
| | | | | contains the | | |
| | | | | signature, as | | |
| | | | | defined in | | |
| | | | | Section 3.2.1 | | |
| | | | | of [RFC7281]. | | |
| | | | | | | |
| smime| [RFC5751]| body | smime- | The email |active | 1 |
| | | | identifier | address | | |
| | | | | [RFC5322] | | |
| | | | | associated | | |
| | | | | with the | | |
| | | | | S/MIME | | |
| | | | | signature. | | |
| | | | | The email | | |
| | | | | address can be | | |
| | | | | specified | | |
| | | | | explicitly or | | |
| | | | | derived from | | |
| | | | | the identity | | |
| | | | | of the signer. | | |
| | | | | Note that this | | |
| | | | | email address | | |
| | | | | can correspond | | |
| | | | | to a counter- | | |
| | | | | signature. | | |
| | | | | | | |
| smime| [RFC5751]| body | smime- | serialNumber |active | 1 |
| | | | serial | of the | | |
| | | | | certificate | | |
| | | | | associated | | |
| | | | | with the | | |
| | | | | S/MIME | | |
| | | | | signature (see | | |
| | | | | Section | | |
| | | | | 4.1.2.2 of | | |
| | | | | [RFC5280]. | | |
| | | | | | | |
| smime| [RFC5751]| body | smime- | Issuer name DN |active | 1 |
| | | | issuer | (e.g., "CN=CA1,| | |
| | | | | ST=BC,c=CA") | | |
| | | | | of the | | |
| | | | | certificate | | |
| | | | | associated | | |
| | | | | with the | | |
| | | | | S/MIME | | |
| | | | | signature (see | | |
| | | | | Section | | |
| | | | | 4.1.2.4 of | | |
| | | | | [RFC5280]. | | |
+------+----------+-------+------------+----------------+-------+------+
IANA has added the following entries to the "Email Authentication Result Names" sub-registry of the "Email Authentication Parameters" registry:
IANAは、「Email Authentication Parameters」レジストリの「Email Authentication Result Names」サブレジストリに次のエントリを追加しました。
+-----------+-----------+----------+-----------------------+--------+
| Code | Defined | Auth | Meaning | Status |
| | | Method | | |
+-----------+-----------+----------+-----------------------+--------+
| none | [RFC7281] | smime | [RFC7281] Section 3.1 | active |
| | | | | |
| pass | [RFC7281] | smime | [RFC7281] Section 3.1 | active |
| | | | | |
| fail | [RFC7281] | smime | [RFC7281] Section 3.1 | active |
| | | | | |
| policy | [RFC7281] | smime | [RFC7281] Section 3.1 | active |
| | | | | |
| neutral | [RFC7281] | smime | [RFC7281] Section 3.1 | active |
| | | | | |
| temperror | [RFC7281] | smime | [RFC7281] Section 3.1 | active |
| | | | | |
| permerror | [RFC7281] | smime | [RFC7281] Section 3.1 | active |
+-----------+-----------+----------+-----------------------+--------+
This document doesn't add new security considerations not already covered by [RFC7001] and [RFC5751]. In particular, security considerations related to the use of weak cryptography over plaintext, weakening and breaking of cryptographic algorithms over time, and changing the behavior of message processing based on presence of a signature specified in [RFC5751] are relevant to this document. Similarly, the following security considerations specified in [RFC7001] are particularly relevant to this document: Forged Header Fields, Misleading Results, Internal Mail Transfer Agent (MTA) Lists, and Compromised Internal Hosts.
このドキュメントは、[RFC7001]と[RFC5751]でまだカバーされていない新しいセキュリティの考慮事項を追加しません。特に、平文での弱い暗号の使用、時間の経過に伴う暗号アルゴリズムの弱体化と破壊、および[RFC5751]で指定された署名の存在に基づくメッセージ処理の動作の変更に関するセキュリティの考慮事項は、このドキュメントに関連します。同様に、[RFC7001]で指定されている次のセキュリティに関する考慮事項は、このドキュメントに特に関連しています。偽造されたヘッダーフィールド、誤解を招く結果、内部メール転送エージェント（MTA）リスト、および侵害された内部ホスト。
To repeat something already mentioned in RFC 7001, Section 7.1:
RFC 7001のセクション7.1ですでに言及されていることを繰り返すには：
An MUA or filter that accesses a mailbox whose messages are handled by a non-conformant MTA, and understands Authentication-Results header fields, could potentially make false conclusions based on forged header fields. A malicious user or agent could forge a header field using the DNS domain of a receiving ADMD as the authserv-id token in the value of the header field and, with the rest of the value, claim that the message was properly authenticated. The non-conformant MTA would fail to strip the forged header field, and the MUA could inappropriately trust it.
非準拠のMTAによってメッセージが処理されるメールボックスにアクセスし、Authentication-Resultsヘッダーフィールドを理解するMUAまたはフィルターは、偽造されたヘッダーフィールドに基づいて誤った結論を下す可能性があります。悪意のあるユーザーまたはエージェントは、受信ADMDのDNSドメインをヘッダーフィールドの値のauthserv-idトークンとして使用してヘッダーフィールドを偽造し、残りの値とともに、メッセージが適切に認証されたと主張する可能性があります。非準拠のMTAは偽造されたヘッダーフィールドの削除に失敗し、MUAが不適切にそれを信頼する可能性があります。
For this reason, it is best not to have processing of the Authentication-Results header field enabled by default; instead, it should be ignored, at least for the purposes of enacting filtering decisions, unless specifically enabled by the user or administrator after verifying that the border MTA is compliant. It is acceptable to have an MUA aware of this specification but have an explicit list of hostnames whose Authentication-Results header fields are trustworthy; however, this list should initially be empty.
このため、Authentication-Resultsヘッダーフィールドの処理をデフォルトで有効にしないことをお勧めします。代わりに、境界のMTAが準拠していることを確認した後、ユーザーまたは管理者が特に有効にしない限り、少なくともフィルタリングの決定を行う目的で、これは無視されます。 MUAにこの仕様を認識させることは許容されますが、Authentication-Resultsヘッダーフィールドが信頼できるホスト名の明示的なリストがあります。ただし、このリストは最初は空である必要があります。
So, to emphasize this point: whenever possible, MUAs should implement their own S/MIME signature verification instead of implementing this specification.
したがって、この点を強調するために、MUAは可能な限り、この仕様を実装する代わりに、独自のS / MIME署名検証を実装する必要があります。
Note that agents adding Authentication-Results header fields containing S/MIME authentication method might be unable to verify S/MIME signatures inside encrypted CMS content types such as EnvelopedData [RFC5652]. So, agents processing Authentication-Results header fields can't treat the lack of an Authentication-Results header field with S/MIME authentication method as an indication that the corresponding S/MIME signature is missing, invalid, or valid.
S / MIME認証方式を含むAuthentication-Resultsヘッダーフィールドを追加するエージェントは、EnvelopedData [RFC5652]などの暗号化されたCMSコンテンツタイプ内のS / MIME署名を検証できない場合があることに注意してください。そのため、Authentication-Resultsヘッダーフィールドを処理するエージェントは、S / MIME認証方法でのAuthentication-Resultsヘッダーフィールドの欠如を、対応するS / MIME署名がない、無効、または有効であることを示すものとして扱うことができません。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501] Crispin、M。、「インターネットメッセージアクセスプロトコル-バージョン4rev1」、RFC 3501、2003年3月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[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, May 2008.
[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、2008年5月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、2010年1月。
[RFC7001] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7001, September 2013.
[RFC7001] Kucherawy、M。、「メッセージ認証ステータスを示すためのメッセージヘッダーフィールド」、RFC 7001、2013年9月。
[RFC3183] Dean, T. and W. Ottaway, "Domain Security Services using S/MIME", RFC 3183, October 2001.
[RFC3183] Dean、T。およびW. Ottaway、「S / MIMEを使用したドメインセキュリティサービス」、RFC 3183、2001年10月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、2009年9月。
Thank you to Murray S. Kucherawy, David Wilson, Jim Schaad, SM, and Steve Kille for comments and corrections on this document.
このドキュメントに関するコメントと修正については、マレーS.クチェラウィ、デビッドウィルソン、ジムシャード、SM、およびスティーブキレに感謝します。
Author's Address
著者のアドレス
Alexey Melnikov Isode Ltd 14 Castle Mews Hampton, Middlesex TW12 2NP United Kingdom
Alexey Melnikov Isode Ltd 14 Castle Mewsハンプトン、ミドルセックスTW12 2NPイギリス
EMail: Alexey.Melnikov@isode.com