doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc7912.txt b/doc/rfc/rfc7912.txt
new file mode 100644
index 0000000..67284ef
--- /dev/null
+++ b/doc/rfc/rfc7912.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Independent Submission                                       A. Melnikov
+Request for Comments: 7912                                     Isode Ltd
+Category: Informational                                        June 2016
+ISSN: 2070-1721
+
+
+       Message Authorizing Email Header Field and Its Use for the
+                      Draft and Release Procedure
+
+Abstract
+
+   This document describes a procedure for when a Military Message
+   Handling System (MMHS) message is composed by one user and is only
+   released to the mail transfer system when one or more Authorizing
+   Users authorize release of the message by adding the
+   MMHS-Authorizing-Users header field.  The resulting message can be
+   optionally signed by the sender and/or reviewer, allowing recipients
+   to verify both the original signature (if any) and the review
+   signatures.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   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 7841.
+
+   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/rfc7912.
+
+Copyright Notice
+
+   Copyright (c) 2016 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
+   (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.
+
+
+
+
+Melnikov                      Informational                     [Page 1]
+
+RFC 7912            Message Authorizing Header Field           June 2016
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Conventions Used in This Document . . . . . . . . . . . . . .   3
+   3.  Draft and Release Procedure . . . . . . . . . . . . . . . . .   3
+     3.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
+     3.2.  Handling of Initial Message Submission by the MSA . . . .   3
+     3.3.  Review by Authorizing User(s) . . . . . . . . . . . . . .   4
+       3.3.1.  Processing of Encrypted Messages  . . . . . . . . . .   5
+       3.3.2.  Authorizing S/MIME Signatures . . . . . . . . . . . .   5
+     3.4.  Role of Other Messaging Agents at the Sender's Domain . .   6
+       3.4.1.  MDA at the Sender's Domain  . . . . . . . . . . . . .   6
+       3.4.2.  Border MTA at the Sender's Domain . . . . . . . . . .   6
+   4.  MMHS-Authorizing-Users Header Field . . . . . . . . . . . . .   6
+   5.  Updated MIXER Mapping . . . . . . . . . . . . . . . . . . . .   7
+     5.1.  Mapping from RFC 5322/MIME to X.400 . . . . . . . . . . .   7
+     5.2.  Mapping from X.400 to RFC 5322/MIME . . . . . . . . . . .   7
+   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
+     7.1.  Forged Header Fields  . . . . . . . . . . . . . . . . . .   9
+     7.2.  Intentionally Malformed Header Fields . . . . . . . . . .   9
+   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
+     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
+     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  11
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11
+
+1.  Introduction
+
+   In some secure environments, email messages can't be released to the
+   Message Transfer System (MTS); thus, they can't be delivered to
+   recipients unless they are authorized by one or more Authorizing
+   Users (e.g., Releasing Officers or Release Authorities).  This
+   document describes how this mechanism can be realized by an
+   additional Internet Email [RFC5322] header field and optionally
+   protected using S/MIME [RFC5750] [RFC5751] or DomainKeys Identified
+   Mail (DKIM) [RFC6376].
+
+   This document describes a procedure for how an email message composed
+   by one user can be released to the MTS when one or more Authorizing
+   Users authorize and optionally countersign the message.  The MMHS-
+   Authorizing-Users header field (see Section 4) communicates which
+   user(s) authorized the message.  If S/MIME signed, the resulting
+   message allows recipients to verify both the original (if any) and
+   counter signatures.  The original S/MIME signature generated by the
+   sender (if any) is unaffected by additional S/MIME review signatures.
+
+
+
+
+
+Melnikov                      Informational                     [Page 2]
+
+RFC 7912            Message Authorizing Header Field           June 2016
+
+
+2.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+   The formal syntax uses the Augmented Backus-Naur Form (ABNF)
+   [RFC5234] notation, including the core rules defined in Appendix B of
+   RFC 5234 [RFC5234].  Terms not defined in this document are taken
+   from [RFC5322].
+
+3.  Draft and Release Procedure
+
+3.1.  Terminology
+
+   Drafter: Any email user that composes a message (Draft Message)
+   needing authorization before it is released to its intended
+   recipients.
+
+   Authorizing User (also Releaser or Authorizer): The mailbox of a user
+   or a group of users that must inspect and authorize the release of a
+   Draft Message before it can be sent.  An organization may require
+   more than one Authorizing User to authorize the release of a Draft
+   Message.
+
+3.2.  Handling of Initial Message Submission by the MSA
+
+   The original email message to be sent doesn't include the MMHS-
+   Authorizing-Users header field.  It may or may not include the
+   sender's S/MIME signature.
+
+   The message to be sent is first submitted over SMTP [RFC6409].  The
+   specific mechanism for how it arrives to the Authorizing User(s) is
+   not specified in this document.  One possibility is for the Message
+   Submission Agent (MSA) to redirect all email messages not addressed
+   to Authorizing Users and not submitted by Authorizing Users to a
+   preconfigured mailbox(es) that can be accessed by Authorizing
+   User(s).  Another possibility is for the MSA to redirect all email
+   messages without the MMHS-Authorizing-Users header field and/or
+   corresponding S/MIME review signatures to a preconfigured mailbox(es)
+   that can be accessed by Authorizing User(s).
+
+   In order to prevent a malicious sender from bypassing or altering the
+   Draft and Release procedure, the MSA MUST check that the MMHS-
+   Authorizing-Users header field (if present) is syntactically valid,
+   contains the email addresses of entities authorized to act as
+   Authorizing Users, and, when review signatures are used, that every
+
+
+
+
+Melnikov                      Informational                     [Page 3]
+
+RFC 7912            Message Authorizing Header Field           June 2016
+
+
+   entity listed has one or more matching review signature (or
+   signature) that is valid.
+
+3.3.  Review by Authorizing User(s)
+
+   Each user agent (UA) that is used by an authorized user MUST perform
+   the following steps (if there are multiple Authorizing Users, the
+   whole sequence of steps below is repeated for each Authorizing User):
+
+   1.  Verify the origination of the message (From/Sender header
+       fields).  The exact mechanism to do that is out of scope for this
+       document, but one example is by verifying the S/MIME signature,
+       making sure that the signature protects all header fields (i.e.,
+       wrapped by message/rfc822, as described in Section 3.1 of
+       [RFC5751]) and that it matches the sender of the message, as
+       described in [RFC5750].  Another example is by verifying a DKIM
+       signature [RFC6376] (added by the Drafter's Mail User Agent (MUA)
+       or MSA) that covers the From/Sender header fields.
+
+   2.  Check if the message already contains the MMHS-Authorizing-Users
+       header field with the email address of the Authorizing User.
+       (This can happen, for example, if the email system is
+       misconfigured and thus contains a loop, or if a malicious sender
+       or attacker is trying to affect the authorization procedure.)  If
+       the message doesn't contain the email address of the Authorizing
+       User in the MMHS-Authorizing-Users header field, then go to the
+       next step.  If the MMHS-Authorizing-Users header field contains
+       the email address of the Authorizing User, verify the validity of
+       the header field (for example, by checking for the S/MIME
+       signature/review signature or for the DKIM signature) and also
+       verify that the email address associated with the signature
+       matches the email address of the Authorizing User.  If the
+       validity of the MMHS-Authorizing-Users header field can be
+       verified, go to step 5 below.  Otherwise, return the message to
+       the sender (bounce) or redirect the message to a designated abuse
+       mailbox.
+
+   3.  Allow the Authorizing User to review the content of the message.
+       Some of the checks can be automated (for example, search for
+       keywords).  (See Section 3.3.1 for additional considerations.)
+       If, based on the check, the Authorizing User is happy to release
+       the message to the MTS (or to the next Authorizing User, if
+       multiple authorizations are required), the UA SHOULD enable the
+       Authorizing User to protect additions to the MMHS-Authorizing-
+       Users header field, for example, by allowing the addition of the
+       S/MIME review signature (if S/MIME is used for protecting the
+       MMHS-Authorizing-Users header field.  See Section 3.3.2 for more
+       details).  If the Authorizing User wants to reject the message,
+
+
+
+Melnikov                      Informational                     [Page 4]
+
+RFC 7912            Message Authorizing Header Field           June 2016
+
+
+       it SHOULD be returned to the Drafter with an explanatory note or
+       it MAY be discarded.  The Authorizing User can also choose to
+       forward the message to another Authorizing User for additional
+       approval or become a new Drafter of the message.  If the
+       Authorizing User becomes the new Drafter, its UA MUST strip any
+       existing email addresses from the MMHS-Authorizing-Users header
+       field.
+
+   4.  If there is an existing MMHS-Authorizing-Users header field
+       containing the email address of the Authorizing User, skip this
+       step.  Otherwise, insert a new MMHS-Authorizing-Users header
+       field (if absent) containing the email address of the Authorizing
+       User or append the email address of the Authorizing User to the
+       end of the existing MMHS-Authorizing-Users header field.
+
+   5.  The (possibly) updated email message is either released to the
+       MTS or to the next Authorizing User, as per email system
+       configuration.  Note that if the Authorizing User updates the
+       message in a manner that invalidates existing S/MIME or DKIM
+       signature(s), the Authorizing User becomes the Drafter and needs
+       to reapply any protections.
+
+3.3.1.  Processing of Encrypted Messages
+
+   Any encrypted message sent in an environment where the Draft and
+   Release procedure is in force also needs to be encrypted to all
+   Authorizing Users, so that they can perform review of the message.
+   If a User Agent used by an Authorizing User can't decrypt the
+   message, it SHOULD notify the sender (which can be the Drafter or a
+   previous Authorizing User) about the problem using a non-delivery
+   Delivery Status Notification (DSN) or through some other means.  The
+   ciphertext that cannot be decrypted by the Authorizing User MAY be
+   included in the notification to aid debugging.  A possible reason not
+   to notify the sender is to avoid Denial-of-Service attacks, for
+   example, if an attacker discovers a way to inject fake messages with
+   encryption that doesn't validate in order to overflow the sender's
+   INBOX.
+
+3.3.2.  Authorizing S/MIME Signatures
+
+   If S/MIME were not used, the Authorizing User can become the original
+   signer of the message.
+
+   If a message is signed with multiple signatures (for example, using
+   different cryptographic algorithms, as described in [RFC5752]), all
+   of the signatures that can be verified by an Authorizing User SHOULD
+   be signed with a review signature (authorizing signatures).  A
+   recipient of the message can consider any chain of review signatures
+
+
+
+Melnikov                      Informational                     [Page 5]
+
+RFC 7912            Message Authorizing Header Field           June 2016
+
+
+   that matches MMHS-Authorizing-Users header field values as valid,
+   only if all signatures in the chain are verified.  All of the
+   signatures that cannot be verified MUST be stripped by the
+   Authorizing User Agent.
+
+   When triple wrapping [RFC2634] is used, authorizing signatures are
+   applied to the outer level, so that it can be verified by Message
+   Transfer Agents (MTAs) without the need to decrypt content.
+
+3.4.  Role of Other Messaging Agents at the Sender's Domain
+
+3.4.1.  MDA at the Sender's Domain
+
+   If a message being sent is to be delivered within the sender's
+   domain, Message Delivery Agents (MDAs) are responsible for ensuring
+   that the message was properly authorized by Authorizing User(s), as
+   determined by the sender's domain email system configuration.  They
+   verify the presence and validity of the MMHS-Authorizing-Users header
+   field in the message, as well as the validity of associated
+   signatures on the message.
+
+   Note that the above requirements don't apply to direct delivery to
+   any user designated as an Authorizing User.
+
+3.4.2.  Border MTA at the Sender's Domain
+
+   The sender's domain border MTAs are responsible for ensuring that all
+   messages that leave the sender's domain were properly authorized by
+   the Authorizing User(s), as determined by the sender's domain email
+   system configuration.  They verify the presence and validity of the
+   MMHS-Authorizing-Users header field in outgoing messages, as well as
+   the validity of associated signatures on the message.
+
+4.  MMHS-Authorizing-Users Header Field
+
+   The MMHS-Authorizing-Users header field specifies the list of
+   Authorizing Users (or entities(*)) that countersigned this email
+   message (for example, using S/MIME) before it was authorized for
+   release to the MTS.  Each user/entity is described by the email
+   address.
+
+   (*) Note that in some environments, identities of Authorizing Users
+   are required to be hidden from recipients of email messages; so, upon
+   receipt, MMHS-Authorizing-Users might contain an email address
+   associated with a group of possible users.  Such email addresses need
+   to have signatures that don't disclose group membership.
+
+
+
+
+
+Melnikov                      Informational                     [Page 6]
+
+RFC 7912            Message Authorizing Header Field           June 2016
+
+
+   The MMHS-Authorizing-Users header field specified in this document
+   MUST NOT appear more than once in message headers.  An email message
+   that contains multiple MMHS-Authorizing-Users is malformed.  An agent
+   processing such a malformed message SHOULD either return it to the
+   sender (if possible) or fix the message so that it contains only one
+   copy of the header field.
+
+       MMHS-Authorizing-Users = "MMHS-Authorizing-Users:"
+                          mailbox-list CRLF
+
+       mailbox-list = <Defined in RFC 5322>
+
+5.  Updated MIXER Mapping
+
+   This section provides an updated version of the MIXER mapping
+   specified in [RFC2156] for MMHS applications.
+
+5.1.  Mapping from RFC 5322/MIME to X.400
+
+   In the absence of the MMHS-Authorizing-Users header field, the From
+   and Sender header fields are mapped to their X.400 equivalents as
+   specified in [RFC2156].
+
+   If the MMHS-Authorizing-Users header field is present:
+
+   1.  If the Sender header field is present, it is mapped to
+       IPMS.Heading.originator; otherwise, the first From header field
+       address is mapped to IPMS.Heading.originator.
+
+   2.  Map the From header field address(es) and the MMHS-Authorizing-
+       Users header field address(es) to IPMS.Heading.authorizing-users,
+       skipping the first From header field address if it was mapped to
+       IPMS.Heading.originator.
+
+5.2.  Mapping from X.400 to RFC 5322/MIME
+
+   Mapping from X.400 to the Internet is controlled by whether or not a
+   particular message is considered a military message.  A message is
+   considered a military message (as defined by ACP 123 [ACP123] and
+   also specified in STANAG 4406 [STANAG-4406]) if there are any MMHS
+   heading extensions present.  Alternatively, this MAY be done by
+   configuration (i.e., all messages can be considered military
+   messages).
+
+   For non-military messages, mapping from X.400 as specified in
+   [RFC2156] is used.
+
+
+
+
+
+Melnikov                      Informational                     [Page 7]
+
+RFC 7912            Message Authorizing Header Field           June 2016
+
+
+   For military messages, the following mapping is used:
+
+   1.  IPMS.Heading.originator is mapped to the From header field.
+
+   2.  The IPMS.Heading.authorizing-users is mapped to the MMHS-
+       Authorizing-Users header field.
+
+6.  IANA Considerations
+
+   IANA has added the MMHS-Authorizing-Users header field specified in
+   Section 4 to the "Provisional Message Header Field Names" registry,
+   defined by "Registration Procedures for Message Header Fields"
+   [RFC3864].  The registration template is as follows:
+
+   Header field name: MMHS-Authorizing-Users
+
+   Applicable protocol: mail ([RFC5322])
+
+   Status: provisional
+
+   Author/Change controller: Alexey Melnikov <alexey.melnikov@isode.com>
+
+   Specification document(s): RFC 7912
+
+   Related information:
+
+7.  Security Considerations
+
+   In some military environments, the identities of Authorizing Users
+   are required to be hidden from recipients of email messages.  This
+   can be accomplished by using a group address for the MMHS-
+   Authorizing-Users.  In this way, the recipient will know that it was
+   released by an Authorizing User in that group, but the recipient will
+   not know which one of them took the action.
+
+   For those organizations that do not wish to disclose the Authorizing
+   Users' group membership, care must also be taken to ensure that the
+   information included in the certificate used for signing email
+   messages does not disclose individuals in the group.
+
+   Further security considerations are described in subsections of this
+   section.
+
+
+
+
+
+
+
+
+
+Melnikov                      Informational                     [Page 8]
+
+RFC 7912            Message Authorizing Header Field           June 2016
+
+
+7.1.  Forged Header Fields
+
+   A malicious sender may add/change an MMHS-Authorizing-Users header
+   field to bypass or alter the message authorization procedure invoked
+   for messages with no MMHS-Authorizing-Users header field.  For this
+   reason, it is important for agents and clients that rely on the
+   validity of the MMHS-Authorizing-Users header field to also verify
+   the review signature (or a similar protection mechanism) that
+   confirms that a particular person or entity authorized release of a
+   message.
+
+7.2.  Intentionally Malformed Header Fields
+
+   It is possible for an attacker to add an MMHS-Authorizing-Users
+   header field that is extraordinarily large or otherwise malformed in
+   an attempt to discover or exploit weaknesses in the header field
+   parsing code.  Implementations MUST thoroughly verify all such header
+   fields received from MTAs and be robust against intentionally as well
+   as unintentionally malformed header fields.
+
+8.  References
+
+8.1.  Normative References
+
+   [ACP123]   CCEB, "Common Messaging strategy and procedures", ACP 123
+              (B), May 2009.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2156]  Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
+              Mapping between X.400 and RFC 822/MIME", RFC 2156,
+              DOI 10.17487/RFC2156, January 1998,
+              <http://www.rfc-editor.org/info/rfc2156>.
+
+   [RFC2634]  Hoffman, P., Ed., "Enhanced Security Services for S/MIME",
+              RFC 2634, DOI 10.17487/RFC2634, June 1999,
+              <http://www.rfc-editor.org/info/rfc2634>.
+
+   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234,
+              DOI 10.17487/RFC5234, January 2008,
+              <http://www.rfc-editor.org/info/rfc5234>.
+
+
+
+
+
+
+Melnikov                      Informational                     [Page 9]
+
+RFC 7912            Message Authorizing Header Field           June 2016
+
+
+   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
+              DOI 10.17487/RFC5322, October 2008,
+              <http://www.rfc-editor.org/info/rfc5322>.
+
+   [RFC5750]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
+              Mail Extensions (S/MIME) Version 3.2 Certificate
+              Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010,
+              <http://www.rfc-editor.org/info/rfc5750>.
+
+   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
+              Mail Extensions (S/MIME) Version 3.2 Message
+              Specification", RFC 5751, DOI 10.17487/RFC5751, January
+              2010, <http://www.rfc-editor.org/info/rfc5751>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc6376>.
+
+   [RFC6409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
+              STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
+              <http://www.rfc-editor.org/info/rfc6409>.
+
+8.2.  Informative References
+
+   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
+              Procedures for Message Header Fields", BCP 90, RFC 3864,
+              DOI 10.17487/RFC3864, September 2004,
+              <http://www.rfc-editor.org/info/rfc3864>.
+
+   [RFC5752]  Turner, S. and J. Schaad, "Multiple Signatures in
+              Cryptographic Message Syntax (CMS)", RFC 5752,
+              DOI 10.17487/RFC5752, January 2010,
+              <http://www.rfc-editor.org/info/rfc5752>.
+
+   [STANAG-4406]
+              NATO, "STANAG 4406 Edition 2: Military Message Handling
+              System", STANAG 4406 Ed. 2, March 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov                      Informational                    [Page 10]
+
+RFC 7912            Message Authorizing Header Field           June 2016
+
+
+Acknowledgements
+
+   Many thanks for reviews and text provided by Steve Kille, Jim Schaad,
+   Russ Housley, David Wilson, Chris Bonatti, and Sean Turner.
+
+   Some text in this document was copied from RFC 7001.
+
+Author's Address
+
+   Alexey Melnikov
+   Isode Ltd
+   14 Castle Mews
+   Hampton, Middlesex  TW12 2NP
+   United Kingdom
+
+   Email: Alexey.Melnikov@isode.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov                      Informational                    [Page 11]
+