MSA-to-MDA S/MIME signing & encryption
draft-melnikov-smime-msa-to-mda-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Alexey Melnikov | ||
| Last updated | 2013-10-14 | ||
| Stream | (None) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Reviews |
GENART Last Call review
(of
-03)
Ready with Nits
SECDIR Last Call review
(of
-02)
Has Issues
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-melnikov-smime-msa-to-mda-00
Network Working Group A. Melnikov
Internet-Draft Isode Ltd
Intended status: Standards Track October 14, 2013
Expires: April 17, 2014
MSA-to-MDA S/MIME signing & encryption
draft-melnikov-smime-msa-to-mda-00
Abstract
This document specifies how S/MIME signing and encryption can be
applied between a Message Submission Agent (MSA) and a Message
Delivery Agent (MDA) or between 2 Message Transfer Agents (MTA).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 http://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 April 17, 2014.
Copyright Notice
Copyright (c) 2013 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. 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.
Melnikov Expires April 17, 2014 [Page 1]
Internet-Draft MSA-to-MDA S/MIME October 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 2
3. MSA-to-MDA S/MIME signing & encryption . . . . . . . . . . . 2
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 2
5. Security Considerations . . . . . . . . . . . . . . . . . . . 3
6. Normative References . . . . . . . . . . . . . . . . . . . . 3
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 3
1. Introduction
[RFC3183] specifies Domain Security Services using S/MIME. The
motivation provided there remains largely the same. This document
specifies a simplified variant of Domain Security Services to be used
between an MSA/MTA and an MTA/MDA.
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].
3. MSA-to-MDA S/MIME signing & encryption
An MSA/MTA wishing to sign or encrypt an email message on bahalf of a
domain ("originating S/MIME MSA" or "originating S/MIME MTA") follows
rules specified in [RFC3183], except as specified in this document.
Originating S/MIME MSA/MTA uses a domain signature as specified in
[RFC3183]. However the rules below replace naming rules specified in
Sections 3.1.1 and 4.1 of that document.
The subject name of the Originating S/MIME MSA/MTA's X.509
certificate is not restricted as specified in RFC 3183. In order for
a verifier to recognize a signing/encrypting certificate as the
Originating S/MIME MSA/MTA's certificate, it MUST contain
uniformResourceIdentifier GeneralName of the format "smtp://<fully-
qualified-domain>" in its SubjectAltName. (Here <fully-qualified-
domain> is the domain that is being served by the signing/encrypting
MSA/MTA.) An rfc822Name GeneralName as specified in RFC 3183 MAY
optionally be included in the SubjectAltName.
[[Do we need to distinguish signing versa encryption in certificate's
SubjectAltName?]]
4. IANA Considerations
Melnikov Expires April 17, 2014 [Page 2]
Internet-Draft MSA-to-MDA S/MIME October 2013
This document doesn't require any action from IANA.
5. Security Considerations
TBD
6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3183] Dean, T. and W. Ottaway, "Domain Security Services using S
/MIME", RFC 3183, October 2001.
[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.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
Appendix A. Acknowledgements
TBD
Author's Address
Alexey Melnikov
Isode Ltd
5 Castle Business Village
36 Station Road
Hampton, Middlesex TW12 2BX
UK
EMail: Alexey.Melnikov@isode.com
Melnikov Expires April 17, 2014 [Page 3]