--- 1/draft-ietf-lamps-e2e-mail-guidance-00.txt 2022-01-24 17:13:48.905580004 -0800 +++ 2/draft-ietf-lamps-e2e-mail-guidance-01.txt 2022-01-24 17:13:48.957581322 -0800 @@ -1,18 +1,18 @@ lamps D.K. Gillmor, Ed. Internet-Draft ACLU -Intended status: Informational 26 July 2021 -Expires: 27 January 2022 +Intended status: Informational 24 January 2022 +Expires: 28 July 2022 Guidance on End-to-End E-mail Security - draft-ietf-lamps-e2e-mail-guidance-00 + draft-ietf-lamps-e2e-mail-guidance-01 Abstract End-to-end cryptographic protections for e-mail messages can provide useful security. However, the standards for providing cryptographic protection are extremely flexible. That flexibility can trap users and cause surprising failures. This document offers guidance for mail user agent implementers that need to compose or interpret e-mail messages with end-to-end cryptographic protection. It provides a useful set of vocabulary as well as suggestions to avoid common @@ -26,35 +26,35 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 27 January 2022. + This Internet-Draft will expire on 28 July 2022. Copyright Notice - Copyright (c) 2021 IETF Trust and the persons identified as the + Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. 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. + extracted from this document must include Revised BSD License text as + described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.1. Structural Headers . . . . . . . . . . . . . . . . . 4 2. Usability . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. E-mail Users Want a Familiar Experience . . . . . . . . . 5 @@ -77,46 +77,53 @@ 5.2. Encryption Outside, Signature Inside . . . . . . . . . . 13 5.3. Avoid Offering Encrypted-only Messages . . . . . . . . . 13 5.4. Composing a Reply Message . . . . . . . . . . . . . . . . 14 6. Message Interpretation . . . . . . . . . . . . . . . . . . . 15 6.1. Rendering Well-formed Messages . . . . . . . . . . . . . 15 6.2. Errant Cryptographic Layers . . . . . . . . . . . . . . . 15 6.2.1. Errant Signing Layer . . . . . . . . . . . . . . . . 15 6.2.2. Errant Encryption Layer . . . . . . . . . . . . . . . 17 6.3. Forwarded Messages with Cryptographic Protection . . . . 18 6.4. Signature failures . . . . . . . . . . . . . . . . . . . 18 - 7. Certificate Management . . . . . . . . . . . . . . . . . . . 19 - 7.1. Peer Certificates . . . . . . . . . . . . . . . . . . . . 19 - 7.1.1. Cert Discovery from Incoming Messages . . . . . . . . 19 - 7.1.2. Certificate Directories . . . . . . . . . . . . . . . 20 - 7.1.3. Peer Certificate Selection . . . . . . . . . . . . . 20 - 7.1.4. Checking for Revocation . . . . . . . . . . . . . . . 20 - 7.2. Local Certificates . . . . . . . . . . . . . . . . . . . 21 - 7.2.1. Getting a Certificate for the User . . . . . . . . . 21 - 7.2.2. Local Certificate Maintenance . . . . . . . . . . . . 21 - 7.2.3. Shipping Certificates in Outbound Messages . . . . . 22 - 7.3. Certificate Authorities . . . . . . . . . . . . . . . . . 22 - 8. Common Pitfalls and Guidelines . . . . . . . . . . . . . . . 22 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 - 12.2. Informative References . . . . . . . . . . . . . . . . . 24 - Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 25 - Appendix B. Document Considerations . . . . . . . . . . . . . . 25 - B.1. Document History . . . . . . . . . . . . . . . . . . . . 25 - B.1.1. Substantive changes from draft-dkg-...-01 to - draft-ietf-...-00 . . . . . . . . . . . . . . . . . . 25 - B.1.2. Substantive changes from draft-dkg-...-00 to - draft-dkg-...-01 . . . . . . . . . . . . . . . . . . 25 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 + 7. Reasoning about Message Parts . . . . . . . . . . . . . . . . 19 + 7.1. Main Body Part . . . . . . . . . . . . . . . . . . . . . 19 + 7.2. Attachments . . . . . . . . . . . . . . . . . . . . . . . 20 + 7.3. MIME Part Examples . . . . . . . . . . . . . . . . . . . 21 + + 8. Certificate Management . . . . . . . . . . . . . . . . . . . 22 + 8.1. Peer Certificates . . . . . . . . . . . . . . . . . . . . 22 + 8.1.1. Cert Discovery from Incoming Messages . . . . . . . . 22 + 8.1.2. Certificate Directories . . . . . . . . . . . . . . . 22 + 8.1.3. Peer Certificate Selection . . . . . . . . . . . . . 22 + 8.1.4. Checking for Revocation . . . . . . . . . . . . . . . 23 + 8.2. Local Certificates . . . . . . . . . . . . . . . . . . . 23 + 8.2.1. Getting a Certificate for the User . . . . . . . . . 23 + 8.2.2. Local Certificate Maintenance . . . . . . . . . . . . 24 + 8.2.3. Shipping Certificates in Outbound Messages . . . . . 24 + 8.3. Certificate Authorities . . . . . . . . . . . . . . . . . 25 + 9. Common Pitfalls and Guidelines . . . . . . . . . . . . . . . 25 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 26 + 13.2. Informative References . . . . . . . . . . . . . . . . . 26 + Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 27 + Appendix B. Document Considerations . . . . . . . . . . . . . . 28 + B.1. Document History . . . . . . . . . . . . . . . . . . . . 28 + B.1.1. Substantive changes from draft-ietf-...-00 to + draft-ietf-...-01 . . . . . . . . . . . . . . . . . . 28 + B.1.2. Substantive changes from draft-dkg-...-01 to + draft-ietf-...-00 . . . . . . . . . . . . . . . . . . 28 + B.1.3. Substantive changes from draft-dkg-...-00 to + draft-dkg-...-01 . . . . . . . . . . . . . . . . . . 28 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction E-mail end-to-end security using S/MIME ([RFC8551]) and PGP/MIME ([RFC3156]) cryptographic standards can provide integrity, authentication and confidentiality to MIME ([RFC4289]) e-mail messages. However, there are many ways that a receiving mail user agent can misinterpret or accidentally break these security guarantees (e.g., @@ -152,38 +159,41 @@ * _Cryptographic Layer_, _Cryptographic Envelope_, _Cryptographic Payload_, and _Errant Cryptographic Layer_ are defined in Section 4 * A _well-formed_ e-mail message with cryptographic protection has both a _Cryptographic Envelope_ and a _Cryptographic Payload_. * _Structural Headers_ are documented in Section 1.2.1. + * _Main Body Part_ is the part (or parts) that are typically + rendered to the user as the message itself (not "as an + attachment). See Section 7.1. + 1.2.1. Structural Headers - A message header whose name begins with "Content-" is referred to in + A message header whose name begins with Content- is referred to in this document as a "structural" header. These headers indicate something about the specific MIME part they are attached to, and cannot be transferred or copied to other parts without endangering the readability of the message. This includes (but is not limited to): - * "Content-Type" - - * "Content-Transfer-Encoding" + * Content-Type + * Content-Transfer-Encoding - * "Content-Disposition" + * Content-Disposition - FIXME: are there any non-"Content-*" headers we should consider as + FIXME: are there any non-Content-* headers we should consider as structural? 2. Usability Any MUA that enables its user to transition from unprotected messages to messages with end-to-end cryptographic protection needs to consider how the user understands this transition. That said, the primary goal of the user of an MUA is communication -- so interface elements that get in the way of communication should be avoided where possible. @@ -351,32 +361,32 @@ This MIME layer offers confidentiality. 4.1.1.4. S/MIME PKCS7 authEnveloped-data Cryptographic Layer └─╴application/pkcs7-mime; smime-type="authEnveloped-data" ↧ (decrypts to) └─╴[protected part] This MIME layer offers confidentiality and integrity. - Note that "enveloped-data" (Section 4.1.1.3) and "authEnveloped-data" + Note that enveloped-data (Section 4.1.1.3) and authEnveloped-data (Section 4.1.1.4) have identical message structure and semantics. The only difference between the two is ciphertext malleability. - The examples in this document only include "enveloped-data", but the - implications for that layer apply to "authEnveloped-data" as well. + The examples in this document only include enveloped-data, but the + implications for that layer apply to authEnveloped-data as well. 4.1.1.5. PKCS7 Compression is NOT a Cryptographic Layer The Cryptographic Message Syntax (CMS) provides a MIME compression - layer ("smime-type="compressed-data""), as defined in [RFC3274]. - While the compression layer is technically a part of CMS, it is not + layer (smime-type="compressed-data"), as defined in [RFC3274]. While + the compression layer is technically a part of CMS, it is not considered a Cryptographic Layer for the purposes of this document. 4.1.2. PGP/MIME Cryptographic Layers For PGP/MIME [RFC3156] there are two forms of Cryptographic Layers, signing and encryption. 4.1.2.1. PGP/MIME Signing Cryptographic Layer (multipart/signed) └┬╴multipart/signed; protocol="application/pgp-signature" @@ -437,36 +447,36 @@ 4.4.1. Simple Cryptographic Envelopes As described above, if the "protected part" identified in the sction above is not itself a Cryptographic Layer, that part _is_ the Cryptographic Payload. If the application wants to generate a message that is both encrypted and signed, it MAY use the simple MIME structure from Section 4.1.2.2 by ensuring that the [RFC4880] Encrypted Message within the - "application/octet-stream" part contains an [RFC4880] Signed Message + application/octet-stream part contains an [RFC4880] Signed Message (the final option described in Section 4.1.2.2. 4.4.2. Multilayer Cryptographic Envelopes It is possible to construct a Cryptographic Envelope consisting of multiple layers with either S/MIME or PGP/MIME , for example using the following structure: A └─╴application/pkcs7-mime; smime-type="enveloped-data" B ↧ (decrypts to) C └─╴application/pkcs7-mime; smime-type="signed-data" D ⇩ (unwraps to) E └─╴[protected part] When handling such a message, the properties of the Cryptographic - Envelope are derived from the series "A", "C". + Envelope are derived from the series A, C. As noted in Section 4.4.1, PGP/MIME applications also have a simpler MIME construction available with the same cryptographic properties. 4.5. Errant Crytptographic Layers Due to confusion, malice, or well-intentioned tampering, a message may contain a Cryptographic Layer that is not part of the Cryptographic Envelope. Such a layer is an Errant Cryptographic Layer. @@ -482,104 +492,104 @@ Some mailing list software will re-wrap a well-formed signed message before re-sending to add a footer, resulting in the following structure seen by recipients of the e-mail: H └┬╴multipart/mixed I ├┬╴multipart/signed J │├─╴text/plain K │└─╴application/pgp-signature L └─╴text/plain - In this message, "L" is the footer added by the mailing list. "I" is - now an Errant Cryptographic Layer. + In this message, L is the footer added by the mailing list. I is now + an Errant Cryptographic Layer. Note that this message has no Cryptographic Envelope at all. It is NOT RECOMMENDED to produce e-mail messages with this structure, - because the data in part "L" may appear to the user as though it were - part of "J", though they have different cryptographic properties. In + because the data in part L may appear to the user as though it were + part of J, though they have different cryptographic properties. In particular, if the user believes that the message is signed, but - cannot distinguish "L" from "J" then the author of "L" can - effectively tamper with content of the signed message, breaking the - user's expectation of integrity and authenticity. + cannot distinguish L from J then the author of L can effectively + tamper with content of the signed message, breaking the user's + expectation of integrity and authenticity. 4.5.2. A Baroque Example Consider a message with the following overcomplicated structure: M └┬╴multipart/encrypted N ├─╴application/pgp-encrypted O └─╴application/octet-stream P ↧ (decrypts to) Q └┬╴multipart/signed R ├┬╴multipart/mixed S │├┬╴multipart/signed T ││├─╴text/plain U ││└─╴application/pgp-signature V │└─╴text/plain W └─╴application/pgp-signature - The 3 Cryptographic Layers in such a message are rooted in parts "M", - "Q", and "S". But the Cryptographic Envelope of the message consists - only of the properties derived from the series "M", "Q". The - Cryptographic Payload of the message is part "R". Part "S" is an - Errant Cryptographic Layer. + The 3 Cryptographic Layers in such a message are rooted in parts M, + Q, and S. But the Cryptographic Envelope of the message consists + only of the properties derived from the series M, Q. The + Cryptographic Payload of the message is part R. Part S is an Errant + Cryptographic Layer. Note that this message has both a Cryptographic Envelope _and_ an Errant Cryptographic Layer. It is NOT RECOMMENDED to generate messages with such complicated structures. Even if a receiving MUA can parse this structure properly, it is nearly impossible to render in a way that the user - can reason about the cryptographic properties of part "T" compared to - part "V". + can reason about the cryptographic properties of part T compared to + part V. 5. Message Composition This section describes the ideal composition of an e-mail message with end-to-end cryptographic protection. A message composed with this form is most likely to achieve its end-to-end security goals. 5.1. Message Composition Algorithm This section roughly describes the steps that a MUA should use to compose a cryptographically-protected message that has a proper cryptographic envelope and payload. The message composition algorithm takes three parameters: - * "origbody": the traditional unprotected message body as a well- + * origbody: the traditional unprotected message body as a well- formed MIME tree (possibly just a single MIME leaf part). As a - well-formed MIME tree, "origbody" already has structural headers + well-formed MIME tree, origbody already has structural headers present (see Section 1.2.1). - * "origheaders": the intended non-structural headers for the - message, represented here as a list of "(h,v)" pairs, where "h" is - a header field name and "v" is the associated value. + * origheaders: the intended non-structural headers for the message, + represented here as a list of (h,v) pairs, where h is a header + field name and v is the associated value. - * "crypto": The series of cryptographic protections to apply (for + * crypto: The series of cryptographic protections to apply (for example, "sign with the secret key corresponding to X.509 certificate X, then encrypt to X.509 certificates X and Y"). This is a routine that accepts a MIME tree as input (the Cryptographic Payload), wraps the input in the appropriate Cryptographic Envelope, and returns the resultant MIME tree as output. The algorithm returns a MIME object that is ready to be injected into the mail system: - * Apply "crypto" to "origbody", yielding MIME tree "output" + * Apply crypto to origbody, yielding MIME tree output - * For each header name and value "(h,v)" in "origheaders": + * For each header name and value (h,v) in origheaders: - - Add header "h" of "output" with value "v" + - Add header h of output with value v - * Return "output" + * Return output 5.2. Encryption Outside, Signature Inside Users expect any message that is both signed and encrypted to be signed _inside_ the encryption, and not the other way around. Putting the signature inside the encryption has two advantages: * The details of the signature remain confidential, visible only to the parties capable of decryption. @@ -710,43 +720,43 @@ In such a situation, an MUA SHOULD NOT indicate in the cryptographic summary that the message is signed. 6.2.1.1. Exception: Mailing List Footers The use case described in Section 4.5.1 is common enough in some contexts, that a MUA MAY decide to handle it as a special exception. If the MUA determines that the message comes from a mailing list (it - has a "List-ID" header), and it has a structure that appends a footer + has a List-ID header), and it has a structure that appends a footer to a signing-only Cryptographic Layer with a valid signature, such as: H └┬╴multipart/mixed I ├┬╴multipart/signed J │├─╴[protected part, may be arbitrary MIME subtree] K │└─╴application/{pgp,pkcs7}-signature L └─╴[footer, typically text/plain] or: H └┬╴multipart/mixed I ├─╴application/pkcs7-mime; smime-type="signed-data" │⇩ (unwraps to) J │└─╴[protected part, may be an arbitrary MIME subtree] L └─╴[footer, typically text/plain] Then, the MUA MAY indicate to the user that this is a signed message that has been wrapped by the mailing list. - In this case, the MUA MUST distinguish the footer (part "L") from the - protected part (part "J") when rendering any information about the + In this case, the MUA MUST distinguish the footer (part L) from the + protected part (part J) when rendering any information about the signature. One way to do this is to offer the user two different views of the message: the "mailing list" view, which hides any cryptographic summary but shows the footer: Cryptographic Protections: none H └┬╴multipart/mixed J ├─╴[protected part, may be arbitrary MIME subtree] L └─╴[footer, typically text/plain] @@ -783,22 +793,22 @@ decrypted subpart, the reply message SHOULD be marked for encryption, as noted in {#composing-reply}. Alternately, if the reply message cannot be encrypted (or if the user elects to not encrypt the reply), the composed reply MUST NOT include any material from the decrypted subpart. 6.3. Forwarded Messages with Cryptographic Protection An incoming e-mail message may include an attached forwarded message, - typically as a MIME subpart with "Content-Type: message/rfc822" - ([RFC5322]) or "Content-Type: message/global" ([RFC5355]). + typically as a MIME subpart with Content-Type: message/rfc822 + ([RFC5322]) or Content-Type: message/global ([RFC5355]). Regardless of the cryptographic protections and structure of the incoming message, the internal forwarded message may have its own Cryptographic Envelope. The Cryptographic Layers that are part of the Cryptographic Envelope of the forwarded message are not Errant Cryptographic Layers of the surrounding message -- they are simply layers that apply to the forwarded message itself. @@ -840,69 +850,192 @@ does not have access to. * the certificate that made the signature was revoked. * the certificate that made the signature was expired at the time that the signature was made. * the certificate that made the signature does not correspond to the author of the message. (for X.509, there is no subjectAltName of type RFC822Name whose value matches an e-mail address found in - "From:" or "Sender:") + From: or Sender:) * the certificate that made the signature was not issued by an authority that the MUA user is willing to rely on for certifying the sender's e-mail address. * the signature indicates that it was made at a time much before or much after from the date of the message itself. A valid signature must pass all these tests, but of course invalid signatures may be invalid in more than one of the ways listed above. -7. Certificate Management +7. Reasoning about Message Parts + + When generating or rendering messages, it is useful to know what + parts of the message are likely to be displayed, and how. This + section introduces some common terms that can be applied to parts + within the Cryptographic Payload. + +7.1. Main Body Part + + When an e-mail message is composed or rendered to the user there is + typically one main view that presents a (mostly textual) part of the + message. + + While the message itself may be constructed of several distinct MIME + parts in a tree, but the part that is rendered to the user is the + "Main Body Part". + + When rendering a message, one of the primary jobs of the recieving + MUA is identifying which part (or parts) is the Main Body Part. + Typically, this is found by traversing the MIME tree of the message + looking for a leaf node that has a primary content type of text (e.g. + text/plain or text/html) and is not Content-Disposition: attachment. + MIME tree traversal follows the first child of every multipart node, + with the exception of multipart/alternative. When traversing a + multipart/alternative node, all children should be scanned, with + preference given to the last child node with a MIME type that the MUA + is capable of rendering directly. A MUA MAY offer the user a + mechanism to prefer a particular MIME type within multipart/ + alternative instead of the last renderable child. For example, a + user may explicitly prefer a text/plain alternative part over text/ + html. + + Note that due to uncertainty about the capabilities and configuration + of the receiving MUA, the composing MUA SHOULD consider that multiple + parts might be rendered as the Main Body Part when the message is + ultimately viewed. + + When composing a message, an originating MUA operating on behalf of + an active user can identify which part (or parts) are the "main" + parts: these are the parts the MUA generates from the user's editor. + Tooling that automatically generates e-mail messages should also have + a reasonable estimate of which part (or parts) are the "main" parts, + as they can be programmatically identified by the message author. + + For a filtering program that attempts to transform an outbound + message without any special knowledge about which parts are Main Body + Parts, it can identify the likely parts by following the same routine + as a receiving MUA. + +7.2. Attachments + + A message may contain one or more separated MIME parts that are + intended for download or extraction. Such a part is commonly called + an "attachment", and is commonly identified by having Content- + Disposition: attachment, and is a subpart of a multipart/mixed or + multipart/related container. + + An MUA MAY identify a subpart as an attachment, or permit extraction + of a subpart even when the subpart does not have Content-Disposition: + attachment. + + For end-to-end encrypted messages, attachments _MUST_ be included + within the Cryptographic Payload. If an attachment is found outside + the Cryptographic Payload, then the message is not well-formed (see + Section 6.1). + + Some MUAs have tried to compose messages where each attachment is + placed in its own cryptographic envelope. Such a message is + problematic for several reasons: + + * The attachments can be stripped, replaced, or reordered without + breaking any cryptographic integrity mechanism. + + * The resulting message may have a mix of cryptographic statuses + (e.g. if a signature on one part fails but another succeeds, or if + one part is encrypted and another is not). This mix of statuses + is difficult to represent to the user in a comprehensible way. + +7.3. MIME Part Examples + + Consider a common message with the folloiwing MIME structure: + + M └─╴application/pkcs7-mime + ↧ (decrypts to) + N └─╴application/pkcs7-mime + ⇩ (unwraps to) + O └┬╴multipart/mixed + P ├┬╴multipart/alternative + Q │├─╴text/plain + R │└─╴text/html + S └─╴image/png + + Parts M and N comprise the Cryptographic Envelope. + + Parts Q and R are both Main Body Parts. + + If part S is Content-Disposition: attachment, then it is an + attachment. If part S has no Content-Disposition header, it is + potentially ambiguous whether it is an attachment or not. + + Consider also this alternate structure: + + M └─╴application/pkcs7-mime + ↧ (decrypts to) + N └─╴application/pkcs7-mime + ⇩ (unwraps to) + O └┬╴multipart/alternative + P ├─╴text/plain + Q └┬╴multipart/related + R ├─╴text/html + S └─╴image/png + + In this case, parts M and N are still the Cryptographic Envelope. + + Parts P and R (the first two leaf nodes within each subtree of part + O) are the Main Body Parts. + + Part S is more likely not to be an attachment, as the subtree layout + suggests that it is only relevant for the HTML version of the + message. For example, it might be rendered as an image within the + HTML alternative. + +8. Certificate Management A cryptographically-capable MUA typically maintains knowledge about certificates for the user's own account(s), as well as certificates for the peers that it communicates with. -7.1. Peer Certificates +8.1. Peer Certificates Most certificates that a cryptographically-capable MUA will use will be certificates belonging to the parties that the user communicates with through the MUA. This section discusses how to manage the certificates that belong to such a peer. The MUA will need to be able to discover X.509 certificates for each peer, cache them, and select among them when composing an encrypted message. -7.1.1. Cert Discovery from Incoming Messages +8.1.1. Cert Discovery from Incoming Messages TODO: incoming PKCS#7 messages tend to have a bundle of certificates in them. How should these certs be handled? TODO: point to Autocrypt certificate discovery mechanism TODO: point to OpenPGP embedded certificate subpacket proposal + TODO: compare mechanisms, explain where each case is useful. -7.1.2. Certificate Directories +8.1.2. Certificate Directories Some MUAs may have the capability to look up peer certificates in a directory. TODO: more information here about X.509 directories -- LDAP? TODO: mention WKD for OpenPGP certificates? -7.1.3. Peer Certificate Selection +8.1.3. Peer Certificate Selection When composing an encrypted message, the MUA needs to select a certificate for each recipient that is capable of encryption. To select such a certificate for a given destination e-mail address, the MUA should look through all of its known certificates and verify that _all_ of the conditions below are met: * The certificate must be valid, not expired or revoked. @@ -921,44 +1054,45 @@ * If extendedKeyUsage is present, it contains at least one of the following OIDs: e-mail protection, anyExtendedKeyUsage. TODO: If OID is EC Public Key and keyUsage is absent, what should happen? TODO: what if multiple certificates meet all of these criteria for a given recipient? -7.1.4. Checking for Revocation +8.1.4. Checking for Revocation TODO: discuss how/when to check for peer certificate revocation + TODO: privacy concerns: what information leaks to whom when checking peer cert revocations? -7.2. Local Certificates +8.2. Local Certificates The MUA also needs to know about one or more certificates associated with the user's e-mail account. It is typically expected to have access to the secret key material associated with the public keys in those certificates. -7.2.1. Getting a Certificate for the User +8.2.1. Getting a Certificate for the User TODO: mention ACME SMIME? TODO: mention automatic self-signed certs e.g. OpenPGP? TODO: SHOULD generate secret key material locally, and MUST NOT accept secret key material from an untrusted third party as the basis for the user's certificate. -7.2.2. Local Certificate Maintenance +8.2.2. Local Certificate Maintenance The MUA should warn the user when/if: * The user's own certificate set does not include a valid, unexpired encryption-capable X.509 certificate, and a valid, unexpired signature-capable X.509 certificate. * Any of the user's own certificates is due to expire soon (TODO: what is "soon"?) @@ -972,48 +1106,48 @@ extendedKeyUsage extension TODO: how does the MUA do better than warning in the cases above? What can the MUA actually _do_ here to fix problems before they happen? TODO: discuss how/when to check for own certificate revocation, and what to do if it (or any intermediate certificate authority) is found to be revoked. -7.2.3. Shipping Certificates in Outbound Messages +8.2.3. Shipping Certificates in Outbound Messages TODO: What certificates should the MUA include in an outbound message so that peers can discover them? * local signing certificate so that signature can be validated * local encryption-capable certificate(s) so that incoming messages can be encypted. * On an encrypted message to multiple recipients, the encryption- capable peer certs of the other recipients (to enable "reply all")? * intermediate certificates to chain all of the above to some set of root authorities? -7.3. Certificate Authorities +8.3. Certificate Authorities TODO: how should the MUA select root certificate authorities? TODO: should the MUA cache intermediate CAs? TODO: should the MUA share such a cache with other PKI clients (e.g., web browsers)? Are there distinctions between a CA for S/MIME and for the web? -8. Common Pitfalls and Guidelines +9. Common Pitfalls and Guidelines This section highlights a few "pitfalls" and guidelines based on these discussions and lessons learned. FIXME: some possible additional commentary on: * indexing and search of encrypted messages * managing access to cryptographic secret keys that require user interaction @@ -1020,50 +1154,51 @@ * secure deletion * inline PGP, ugh * storage of composed/sent messages * encrypt-to-self during composition * cached signature validation + * interaction between encryption and Bcc * aggregated cryptographic status of threads/conversations ? * Draft messages * copies to the Sent folder -9. IANA Considerations +10. IANA Considerations MAYBE: provide an indicator in the IANA header registry for which headers are "structural" ? This is probably unnecessary. -10. Security Considerations +11. Security Considerations This entire document addresses security considerations about end-to- end cryptographic protections for e-mail messages. -11. Acknowledgements +12. Acknowledgements The set of constructs and recommendations in this document are derived from discussions with many different implementers, including Alexey Melnikov, Bernie Hoeneisen, Bjarni Runar Einarsson, David Bremner, Deb Cooley, Holger Krekel, Jameson Rollins, Jonathan Hammell, juga, Patrick Brunschwig, Santosh Chokhani, and Vincent Breitmoser. -12. References +13. References -12.1. Normative References +13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, DOI 10.17487/RFC3156, August 2001, . @@ -1075,41 +1210,42 @@ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . -12.2. Informative References +13.2. Informative References [chrome-indicators] Schechter, E., "Evolving Chrome's security indicators", May 2018, . [EFAIL] "EFAIL", n.d., . [I-D.draft-bre-openpgp-samples-01] Einarsson, B. R., "juga", and D. K. Gillmor, "OpenPGP Example Keys and Certificates", Work in Progress, Internet-Draft, draft-bre-openpgp-samples-01, 20 December 2019, . - [I-D.draft-dkg-lamps-samples-05] + [I-D.draft-ietf-lamps-samples-05] Gillmor, D. K., "S/MIME Example Keys and Certificates", - Work in Progress, Internet-Draft, draft-dkg-lamps-samples- - 05, 18 February 2021, . + Work in Progress, Internet-Draft, draft-ietf-lamps- + samples-05, 5 August 2021, + . [RFC3274] Gutmann, P., "Compressed Data Content Type for Cryptographic Message Syntax (CMS)", RFC 3274, DOI 10.17487/RFC3274, June 2002, . [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007, . @@ -1127,44 +1263,60 @@ [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, . Appendix A. Test Vectors FIXME: This document should contain examples of well-formed and malformed messages using cryptographic key material and certificates from [I-D.draft-bre-openpgp-samples-01] and - [I-D.draft-dkg-lamps-samples-05]. + [I-D.draft-ietf-lamps-samples-05]. It may also include example renderings of these messages. Appendix B. Document Considerations [ RFC Editor: please remove this section before publication ] - This document is currently edited as markdown. Minor editorial - changes can be suggested via merge requests at + This document is built from markdown using ruby-kramdown-rfc2629 + (https://rubygems.org/gems/kramdown-rfc2629), and tracked using git + (https://git-scm.com/). The markdown source under development can be + found in the file e2e-mail-guidance.md in the main branch of the git + repository (https://gitlab.com/dkg/e2e-mail-guidance). + + You may also be interested in the latest editor's copy + (https://dkg.gitlab.io/e2e-mail-guidance/). + + Minor editorial changes can be suggested via merge requests at https://gitlab.com/dkg/e2e-mail-guidance or by e-mail to the editor. Please direct all significant commentary to the public IETF LAMPS - mailing list: spasm@ietf.org + mailing list, spasm@ietf.org (https://www.ietf.org/mailman/listinfo/ + spasm). B.1. Document History -B.1.1. Substantive changes from draft-dkg-...-01 to draft-ietf-...-00 +B.1.1. Substantive changes from draft-ietf-...-00 to draft-ietf-...-01 + + * Added section about distinguishing Main Body Parts and Attachments + + * Updated document considerations section, including reference to + auto-built editor's copy + +B.1.2. Substantive changes from draft-dkg-...-01 to draft-ietf-...-00 * WG adopted draft * moved Document History and Document Considerations sections to end of appendix, to avoid section renumbering when removed -B.1.2. Substantive changes from draft-dkg-...-00 to draft-dkg-...-01 +B.1.3. Substantive changes from draft-dkg-...-00 to draft-dkg-...-01 * consideration of success/failure indicators for usability * clarify extendedKeyUsage and keyUsage algorithm-specific details * initial section on certificate management * added more TODO items Author's Address