加密 Headers S/MIME message/rfc822
Encrypting Headers S/MIME message/rfc822
我希望加密某些邮件 headers（Subject 和 Reply-To），这些邮件以加密邮件的形式发送。
我正在使用整个 MIME（包括 Headers）并成功加密它。
我可以将此 S/MIME 加密邮件成功发送到我的邮件客户端 (Thunderbird)。它将被成功解密并验证为已签名。
但是，任何以内部加密 MIME 发送的 headers 都没有被我的邮件客户端使用。
根据 RFC-5751 我应该将我的邮件包装在 message/rfc822 邮件中，但我不知道如何实现这一点。
以下是我正在创建的消息示例。
我的第一个问题是，我创建的最后一个 MIME message/rfc822 结构是否正确？
这可能是邮件客户端的问题吗？
我可以事件加密 Reply-To Header 吗？
如果我能得到一个 mesage/rfc822 封装消息的示例，那将非常有帮助。
要加密的邮件
这将成功收到一封已签名的邮件，并且 Subject / Reply-To headers 会被邮件客户端正确解释。
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
micalg=sha256; boundary="--_NmP-d017e0e3556f7bbc-Part_1"
From: sender@domain.com
Sender: senderdomain.com
To: recipient@domain.com
Reply-To: keepsecret@domain.com
Subject: A Secret Subject
Message-ID: <400b1383-362b-eed7-0719-6b2a2e231143>
Date: Mon, 24 Feb 2020 15:59:19 +0000
MIME-Version: 1.0
----_NmP-d017e0e3556f7bbc-Part_1
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
My Message that will be encrypted
----_NmP-d017e0e3556f7bbc-Part_1
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
MIIOCAYJKoZIhvcNAQcCoIIN+TCCDfUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
gguTMIIFCDCCA/CgAwIBAgIQVz2HAGYJcTJNsPiWLx1f/TANBgkqhkiG9w0BAQsFADCBjTELMAkG
.
.
.
17p13e02JxfyCqltdb6lkOdpRZ6ZlHHuQZyBCuRtJhRN83gvcJ4d7WCxKI349NEa2/tOb8ziFGat
gzvgu+o=
----_NmP-d017e0e3556f7bbc-Part_1--
我的加密邮件
我的邮件客户端将接收并成功解密和验证（签名验证）此加密邮件。 Reply-To 和 Subject 仍在按预期工作，因为它们仍然可见。注意：未加密邮件中的所有 headers 都仍然存在于此邮件的加密 body 中。
Sender: sender@domain.com
From: sender@domain.com
To: recipient@domain.com
Subject: A Secret Subject
Reply-To: keepsecret@domain.com
Message-ID: <400b1383-362b-eed7-0719-6b2a2e231143>
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Date: Mon, 24 Feb 2020 16:03:38 +0000
MIME-Version: 1.0
MIIYbwYJKoZIhvcNAQcDoIIYYDCCGFwCAQAxggG/MIIBuwIBADCBojCBjTELMAkG
.
.
.
O+EPVCh1fGDFwiFpDtY/z1Lv8g==
我的封装message/rfc822
此消息将被正确解密，但我的客户无法识别它是加密消息或验证它是否已签名（对此不太担心）。解密的邮件被解释为转发并附加为 .eml 文件。但是，没有找到 Subject 或 Reply-To headers（它们在加密邮件中）。如果我按照 RFC 的建议添加虚拟值，我的邮件客户端将使用这些虚拟值，而不是加密的值。
Content-Type: message/rfc822; forwarded=false; boundary="--_NmP-07c15c542cedfe74-Part_1"
From: sender@domain.com
Sender: sender@domain.com
To: recipient@domain.com
Date: Mon, 24 Feb 2020 15:28:07 +0000
Message-ID: <400b1383-362b-eed7-0719-6b2a2e231143>
MIME-Version: 1.0
----_NmP-07c15c542cedfe74-Part_1
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
MIIYbwYJKoZIhvcNAQcDoIIYYDCCGFwCAQAxggG/MIIBuwIBADCBojCBjTELMAkG
.
.
.
fYU1LuhSBEyymSVRzwWr2T3lrhUe5BZBoY996epZtOPdIYrz2jqUglii1+AUBpUP
UUnpr8+cHTMk/50LHdy3MqMeYA==
----_NmP-07c15c542cedfe74-Part_1
编辑：添加来自 RFC 的摘录
在 RFC-8551 中声明如下
In order to protect outer, non-content-related message header fields (for instance, the "Subject", "To", "From", and "Cc" fields), the
sending client MAY wrap a full MIME message in a message/rfc822
wrapper in order to apply S/MIME security services to these header
fields. It is up to the receiving client to decide how to present
this "inner" header along with the unprotected "outer" header. Given
the security difference between headers, it is RECOMMENDED that the
receiving client provide a distinction between header fields,
depending on where they are located.
When an S/MIME message is received, if the top-level protected MIME
entity has a Content-Type of message/rfc822, it can be assumed that
the intent was to provide header protection. This entity SHOULD be
presented as the top-level message, taking into account
header-merging issues as previously discussed.
RFC 822 provides a generalized description of how message headers of an email are composed and should be treated by systems they are transmitted through. RFC 5751 S/MIME 3.2 (btw, obsoleted by it successor RFC 8551 S/MIME 4.0) 描述了如何使用该标准创建加密电子邮件的详细信息。
因此，您在我的加密邮件 中描述的加密电子邮件的方法是有效且正确的。
但是，您在 My Encapsulated message/rfc822 下描述的方法并不完全正确。关于如何应用 rfc822 包装器，您显然误解了 RFC。包装器需要在您的消息周围 在 它被加密之前，因此它将位于加密部分内。
在您的示例中，未加密的邮件（稍微修改过的版本 要加密的邮件）必须如下所示：
MIME-Version: 1.0
Content-type: message/rfc822
From: sender@domain.com
Sender: senderdomain.com
To: recipient@domain.com
Reply-To: keepsecret@domain.com
Subject: A Secret Subject
Message-ID: <400b1383-362b-eed7-0719-6b2a2e231143>
Date: Mon, 24 Feb 2020 15:59:19 +0000
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="--_NmP-d017e0e3556f7bbc-Part_1"
----_NmP-d017e0e3556f7bbc-Part_1
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
My Message that will be encrypted
[...]
所以你基本上在加密之前将message/rfc822添加到消息中。
我已经能够验证这种方法并在两个不同结果的接收邮件客户端中测试了生成的消息。对于 macOS 邮件应用程序，加密的主题并没有用来替换未受保护的“外部”主题，但至少，它显着显示在原始 header 的下方。这符合 RFC，该 RFC 对演示文稿不是很具体：
It is up to the receiving client to decide how to present this "inner" header along with the unprotected "outer" header. Given the security difference between headers, it is RECOMMENDED that the receiving client provide a distinction between header fields, depending on where they are located.
加密的 Reply-To header 显示类似，但回复该电子邮件时不接受其电子邮件地址。
客户支持
客户端对加密 header 的支持介于弱和 non-existent 之间。部分测试结果：
- 没有客户端支持用“内部”加密的替换“外部”header
- Apple Mail (macOS) 在邮件中突出显示内部 headers
- Thunderbird 将包括其 header 在内的加密部分显示为转发的消息
- Outlook 不显示加密部分，而是令人困惑地仅显示带有附件的空邮件（即加密邮件）
替代方法
在此 draft for Protected Headers for Cryptographic E-mail 中提出了一种看似很有前途的方法（进行中）。这个想法是将受保护的 header 作为一个单独的部分包含在多部分消息中。这部分将由不可知的客户端内联呈现，同时，它可以由支持客户端正确处理。
我希望加密某些邮件 headers（Subject 和 Reply-To），这些邮件以加密邮件的形式发送。
我正在使用整个 MIME（包括 Headers）并成功加密它。
我可以将此 S/MIME 加密邮件成功发送到我的邮件客户端 (Thunderbird)。它将被成功解密并验证为已签名。
但是，任何以内部加密 MIME 发送的 headers 都没有被我的邮件客户端使用。
根据 RFC-5751 我应该将我的邮件包装在 message/rfc822 邮件中，但我不知道如何实现这一点。
以下是我正在创建的消息示例。
我的第一个问题是，我创建的最后一个 MIME message/rfc822 结构是否正确？
这可能是邮件客户端的问题吗？
我可以事件加密 Reply-To Header 吗？
如果我能得到一个 mesage/rfc822 封装消息的示例，那将非常有帮助。
要加密的邮件
这将成功收到一封已签名的邮件，并且 Subject / Reply-To headers 会被邮件客户端正确解释。
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
micalg=sha256; boundary="--_NmP-d017e0e3556f7bbc-Part_1"
From: sender@domain.com
Sender: senderdomain.com
To: recipient@domain.com
Reply-To: keepsecret@domain.com
Subject: A Secret Subject
Message-ID: <400b1383-362b-eed7-0719-6b2a2e231143>
Date: Mon, 24 Feb 2020 15:59:19 +0000
MIME-Version: 1.0
----_NmP-d017e0e3556f7bbc-Part_1
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
My Message that will be encrypted
----_NmP-d017e0e3556f7bbc-Part_1
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
MIIOCAYJKoZIhvcNAQcCoIIN+TCCDfUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
gguTMIIFCDCCA/CgAwIBAgIQVz2HAGYJcTJNsPiWLx1f/TANBgkqhkiG9w0BAQsFADCBjTELMAkG
.
.
.
17p13e02JxfyCqltdb6lkOdpRZ6ZlHHuQZyBCuRtJhRN83gvcJ4d7WCxKI349NEa2/tOb8ziFGat
gzvgu+o=
----_NmP-d017e0e3556f7bbc-Part_1--
我的加密邮件
我的邮件客户端将接收并成功解密和验证（签名验证）此加密邮件。 Reply-To 和 Subject 仍在按预期工作，因为它们仍然可见。注意：未加密邮件中的所有 headers 都仍然存在于此邮件的加密 body 中。
Sender: sender@domain.com
From: sender@domain.com
To: recipient@domain.com
Subject: A Secret Subject
Reply-To: keepsecret@domain.com
Message-ID: <400b1383-362b-eed7-0719-6b2a2e231143>
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
Date: Mon, 24 Feb 2020 16:03:38 +0000
MIME-Version: 1.0
MIIYbwYJKoZIhvcNAQcDoIIYYDCCGFwCAQAxggG/MIIBuwIBADCBojCBjTELMAkG
.
.
.
O+EPVCh1fGDFwiFpDtY/z1Lv8g==
我的封装message/rfc822
此消息将被正确解密，但我的客户无法识别它是加密消息或验证它是否已签名（对此不太担心）。解密的邮件被解释为转发并附加为 .eml 文件。但是，没有找到 Subject 或 Reply-To headers（它们在加密邮件中）。如果我按照 RFC 的建议添加虚拟值，我的邮件客户端将使用这些虚拟值，而不是加密的值。
Content-Type: message/rfc822; forwarded=false; boundary="--_NmP-07c15c542cedfe74-Part_1"
From: sender@domain.com
Sender: sender@domain.com
To: recipient@domain.com
Date: Mon, 24 Feb 2020 15:28:07 +0000
Message-ID: <400b1383-362b-eed7-0719-6b2a2e231143>
MIME-Version: 1.0
----_NmP-07c15c542cedfe74-Part_1
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m
Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
name=smime.p7m
MIIYbwYJKoZIhvcNAQcDoIIYYDCCGFwCAQAxggG/MIIBuwIBADCBojCBjTELMAkG
.
.
.
fYU1LuhSBEyymSVRzwWr2T3lrhUe5BZBoY996epZtOPdIYrz2jqUglii1+AUBpUP
UUnpr8+cHTMk/50LHdy3MqMeYA==
----_NmP-07c15c542cedfe74-Part_1
编辑：添加来自 RFC 的摘录
在 RFC-8551 中声明如下
In order to protect outer, non-content-related message header fields (for instance, the "Subject", "To", "From", and "Cc" fields), the
sending client MAY wrap a full MIME message in a message/rfc822
wrapper in order to apply S/MIME security services to these header
fields. It is up to the receiving client to decide how to present
this "inner" header along with the unprotected "outer" header. Given
the security difference between headers, it is RECOMMENDED that the
receiving client provide a distinction between header fields,
depending on where they are located.
When an S/MIME message is received, if the top-level protected MIME
entity has a Content-Type of message/rfc822, it can be assumed that
the intent was to provide header protection. This entity SHOULD be
presented as the top-level message, taking into account
header-merging issues as previously discussed.
RFC 822 provides a generalized description of how message headers of an email are composed and should be treated by systems they are transmitted through. RFC 5751 S/MIME 3.2 (btw, obsoleted by it successor RFC 8551 S/MIME 4.0) 描述了如何使用该标准创建加密电子邮件的详细信息。
因此，您在我的加密邮件 中描述的加密电子邮件的方法是有效且正确的。
但是，您在 My Encapsulated message/rfc822 下描述的方法并不完全正确。关于如何应用 rfc822 包装器，您显然误解了 RFC。包装器需要在您的消息周围 在 它被加密之前，因此它将位于加密部分内。
在您的示例中，未加密的邮件（稍微修改过的版本 要加密的邮件）必须如下所示：
MIME-Version: 1.0
Content-type: message/rfc822
From: sender@domain.com
Sender: senderdomain.com
To: recipient@domain.com
Reply-To: keepsecret@domain.com
Subject: A Secret Subject
Message-ID: <400b1383-362b-eed7-0719-6b2a2e231143>
Date: Mon, 24 Feb 2020 15:59:19 +0000
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="--_NmP-d017e0e3556f7bbc-Part_1"
----_NmP-d017e0e3556f7bbc-Part_1
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
My Message that will be encrypted
[...]
所以你基本上在加密之前将message/rfc822添加到消息中。
我已经能够验证这种方法并在两个不同结果的接收邮件客户端中测试了生成的消息。对于 macOS 邮件应用程序，加密的主题并没有用来替换未受保护的“外部”主题，但至少，它显着显示在原始 header 的下方。这符合 RFC，该 RFC 对演示文稿不是很具体：
It is up to the receiving client to decide how to present this "inner" header along with the unprotected "outer" header. Given the security difference between headers, it is RECOMMENDED that the receiving client provide a distinction between header fields, depending on where they are located.
加密的 Reply-To header 显示类似，但回复该电子邮件时不接受其电子邮件地址。
客户支持
客户端对加密 header 的支持介于弱和 non-existent 之间。部分测试结果：
- 没有客户端支持用“内部”加密的替换“外部”header
- Apple Mail (macOS) 在邮件中突出显示内部 headers
- Thunderbird 将包括其 header 在内的加密部分显示为转发的消息
- Outlook 不显示加密部分，而是令人困惑地仅显示带有附件的空邮件（即加密邮件）
替代方法
在此 draft for Protected Headers for Cryptographic E-mail 中提出了一种看似很有前途的方法（进行中）。这个想法是将受保护的 header 作为一个单独的部分包含在多部分消息中。这部分将由不可知的客户端内联呈现，同时，它可以由支持客户端正确处理。