Individual Contribution E. Brunner-Williams Internet-Draft Wampumpeag Expires: April 21, 2003 October 21, 2002 EPP transport mapping for SMTP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. (If this document becomes part of an IETF working group activity, then it will be brought into full compliance with Section 10 of RFC2026.) Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 21, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes how to exchange EPP content using SMTP transport. The data is packaged using standard MIME content-types. Authentication and data security are obtained by using OpenPGP security body parts or Cryptographic Message Syntax (S/MIME). Authenticated acknowledgements make use of multipart/signed replies to the original SMTP message. Distribution of this document is unlimited. Brunner-Williams Expires April 21, 2003 [Page 1] Internet-Draft EPP SMTP Transport October 2002 Dedication This draft is dedicated to Robert C. Byrd, Senator from West Virginia. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background Summary . . . . . . . . . . . . . . . . . . . . . . 4 3. References Overview . . . . . . . . . . . . . . . . . . . . . 5 4. MIME Fields . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Sender Message Structures . . . . . . . . . . . . . . . . . . 7 6. Example: Unsigned, Unencrypted, No Receipt Requested . . . . . 9 7. Example: Signed, Unencrypted, No Receipt Requested . . . . . . 11 8. Example: Unsigned, Encrypted, No Receipt Requested . . . . . . 13 9. Example: Signed, Encrypted, No Receipt Requested . . . . . . . 15 10. Example: Signed, Unencrypted, No Receipt Requested . . . . . . 17 11. Example: Unsigned, Encrypted, No Receipt Requested . . . . . . 19 12. Example: Signed, Encrypted, No Receipt Requested . . . . . . . 21 13. Receiver Message Structures . . . . . . . . . . . . . . . . . 23 14. Bulk Transport . . . . . . . . . . . . . . . . . . . . . . . . 24 15. Security Considerations . . . . . . . . . . . . . . . . . . . 26 16. Internationalization Considerations . . . . . . . . . . . . . 27 References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 29 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 31 Brunner-Williams Expires April 21, 2003 [Page 2] Internet-Draft EPP SMTP Transport October 2002 1. Introduction Previous work on provisioning shared registries focused on specifying XML schema for data exchange and the application/epp+xml MIME media type for identifying EPP content [EPP-P]. This memo expands on this prior work to specify transport over SMTP, and a comprehensive set of mechanisms for MIME-based EPP transport which provide data security features. This memo defines mechanisms to encapsulate a single EPP message within a single SMTP message, encapsulate multiple EPP messages within a single SMTP message, fragment and reassemble one or more EPP messages within one or more SMTP messages, or reference an EPP message within an SMTP message. This memo defines mechanisms to secure (sign or encrypt or sign and encrypt) one or more EPP messages in any SMTP message. This memo does not define mechanism to secure (sign or encrypt or sign and encrypt) individual XML elements within an EPP message. This memo defines mechanisms to request signed or unsigned replies for SMTP messages, allowing the same synchronous blocking semantics of a EPP streams over a single, persistent TCP connection, albeit at a possibly slower pace. Every example in this document has NOT been checked by two different implementors. This strongly indicates (but does not assure) that the examples are incorrect. All implementors must read the relevant document carefully before implementing from it. No one should use the examples in this document as stand-alone explanations of how to create MIME message bodies, or MIME message bodies to which security has been applied. Brunner-Williams Expires April 21, 2003 [Page 3] Internet-Draft EPP SMTP Transport October 2002 2. Background Summary [Some language about these three registry protocols, and the applicability of SMTP as a transport protocol. Dave asked what purpose this serves. Answer TBD.] This table compares the salient characteristics of EPP, RRP and SRS. EPP RRP SRS ----------+------------------------+------------------------+ syntax: syntax: syntax: XML ABNF keyword-value encoding: encoding: encoding: 8-bit 7-bit 7-bit MIME type: MIME type: MIME type: app/epp+xml n/a mp/mixed transport: transport: transport: TCP TCP SMTP, TCP OBJECTS: OBJECTS: OBJECTS: domain domain domain host nameserver host contact n/a contact OBJECTS: OBJECTS: OBJECTS: check check inquire info status status create add create update mod modify delete del remove transfer transfer transfer renew renew renew To Do: Update SRS from Crispin's 11/98 I-D. Some things never really expire. Indicate 2832bis extensions. Brunner-Williams Expires April 21, 2003 [Page 4] Internet-Draft EPP SMTP Transport October 2002 3. References Overview MIME-based EPP transport over SMTP can be implemented by using specifications provided in the following RFCs: -RFC 2821 SMTP -RFC 2822 Text Message Formats -RFC 2045 to 2049 MIME RFCs MIME-based Secure EPP transport over SMTP can be implemented by using specifications provided in the following additional RFCs: -RFC 1847 Security Multiparts for MIME -RFC 2015, 3156, 2440 MIME/PGP -RFC 2630, 2633 S/MIME v3 Specification MIME-based Reliable EPP transport over SMTP can be implemented by using specifications provided in the following additional RFCs: -RFC 1892 Multipart/Report -RFC 2298 Message Disposition Notification MIME-based Bulk EPP transport over SMTP can be implemented by by the specification provided in RFC 2046 for the following: - message/partial subtype - message/external-body subtype Brunner-Williams Expires April 21, 2003 [Page 5] Internet-Draft EPP SMTP Transport October 2002 4. MIME Fields Content-Type == application/epp+xml Content-Transfer-Encoding 1. 7bit -- this is the default, as is "us-ascii" for the charset parameter. This value is NOT RECOMMENDED if the encoding declaration of the XML document is NOT "us-ascii". Note that a line length limit and NUL and CRLF sequence semantics are absent in XML. 2. 8bit -- same as 7bit, with values above 127 allowed. This value is NOT RECOMMENDED if the participating MTAs are not known to support 8bit data. 3. binary -- same as 8bit. 4. quoted-printable -- This value is RECOMMENDED if the encoding declaration of the XML document is NOT "us-ascii". This value (or base64) is REQUIRED if data is signed, or encrypted. 5. base64 -- This value is RECOMMENDED if the encoding declaration of the XML document is NOT "us-ascii". This value (or quoted-printable) is REQUIRED if data is signed, or encrypted. charset -- Processors generating XML MIME entities MUST NOT label conflicting charset information between the MIME Content-Type and the XML declaration. [This list is incomplete.] Brunner-Williams Expires April 21, 2003 [Page 6] Internet-Draft EPP SMTP Transport October 2002 5. Sender Message Structures The message structures in this section are presented hierarchically in terms of which RFC's and Internet-Drafts are applied to form the specific structure. Common Structure No Encryption, No Signature -RFC822/2045 -EPP-P (application/epp+xml) PGP/MIME Structure No Encryption, Signature -RFC822/2045 -RFC1847 (multipart/signed) -EPP-P (application/epp+xml) -RFC2015/2440/3156 (application/pgp-signature) Encryption, No Signature -RFC822/2045 -RFC1847 (multipart/encrypted) -RFC2015/2440/3156 (application/pgp-encrypted) -"Version: 1" -RFC2015/2440/3156 (application/octet-stream) -EPP-P (application/epp+xml) (encrypted) Encryption, Signature -RFC822/2045 -RFC1847 (multipart/encrypted) -RFC2015/2440/3156 (application/pgp-encrypted) -"Version: 1" -RFC2015/2440/3156 (application/octet-stream) -RFC1847 (multipart/signed)(encrypted) -EPP-P (application/epp+xml) (encrypted) -RFC2015/2440/3156 (application/pgp-signature)(encrypted) S/MIME Structure No Encryption, Signature -RFC822/2045 -RFC1847 (multipart/signed) -EPP-P (application/epp+xml) -RFC2633 (application/pkcs7-signature) Brunner-Williams Expires April 21, 2003 [Page 7] Internet-Draft EPP SMTP Transport October 2002 Encryption, No Signature -RFC822/2045 -RFC2633 (application/pkcs7-mime) -EPP-P (application/epp+xml) (encrypted) Encryption, Signature -RFC822/2045 -RFC2633 (application/pkcs7-mime) -RFC1847 (multipart/signed) (encrypted) -EPP-P (application/epp+xml) (encrypted) -RFC2633 (application/pkcs7-signature) (encrypted) Brunner-Williams Expires April 21, 2003 [Page 8] Internet-Draft EPP SMTP Transport October 2002 6. Example: Unsigned, Unencrypted, No Receipt Requested Sender sends unencrypted data, does NOT request a receipt. The MIME fields of interest are: 1. Mime-Version: 1.0 REQUIRED 2. Content-Type: application/epp+xml REQUIRED 3. Content-Transfer-Encoding: OPTIONAL In this example, the encoding declaration of both the XML document and MIME entity is "us-ascii", and the Content-Transfer-Encoding is 7bit. From: epp+smtp@utterly-bogus.nld To: epp+smtp@pseudo-random.nld Date: whenever Subject: test 1: domain-create unsigned, unencrypted, no receipt requested Message-Id: <200210081114.HAA06361@utterly-bogus.nld> Mime-Version: 1.0 Content-Type: application/epp+xml; charset="us-ascii" Content-Transfer-Encoding: 7bit example.tld 2 ns1.example.tld ns1.example2.tld jd1234 sh8013 sh8013 2fooBAR ABC-12345 Brunner-Williams Expires April 21, 2003 [Page 9] Internet-Draft EPP SMTP Transport October 2002 Brunner-Williams Expires April 21, 2003 [Page 10] Internet-Draft EPP SMTP Transport October 2002 7. Example: Signed, Unencrypted, No Receipt Requested Sender sends signed unencrypted data, does NOT request a receipt. The MIME fields of interest are: 1. Mime-Version: 1.0 REQUIRED 2. Content-Type: multipart/signed 3. Content-Type: application/epp+xml REQUIRED 4. Content-Transfer-Encoding: quoted-printable RECOMMENDED In this example, the encoding declaration of both the XML document and MIME entity is "sjis", and the Content-Transfer-Encoding is quoted-printable. From: epp+smtp@utterly-bogus.nld To: epp+smtp@pseudo-random.nld Date: whenever Subject: test 2: domain-create signed, unencrypted, no receipt requested Message-Id: <200210081114.HAA06362@utterly-bogus.nld> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="42" Content-Disposition: inline --42 & Content-Type: application/epp+xml; charset="sjis" & Content-Transfer-Encoding: quoted-printable & & & & & & & example.tld & 2 & ns1.example.tld & ns1.example2.tld & jd1234 Brunner-Williams Expires April 21, 2003 [Page 11] Internet-Draft EPP SMTP Transport October 2002 & sh8013 & sh8013 & 2fooBAR & & & ABC-12345 & & --42 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8CBQE85tUtWry0BWjoQKURAtV1AJoC7/RCMhS86o2RS53zcx2gdZroYACg0xj6 VPugCOXxguA/yd9VF6qoNsM= =ApJ4 -----END PGP SIGNATURE----- --42 The signature is calculated over lines beginning with a "&". Brunner-Williams Expires April 21, 2003 [Page 12] Internet-Draft EPP SMTP Transport October 2002 8. Example: Unsigned, Encrypted, No Receipt Requested Sender sends unsigned encrypted data, does NOT request a receipt. The MIME fields of interest are: 1. Mime-Version: 1.0 REQUIRED 2. Content-Type: multipart/encrypted 3. Content-Transfer-Encoding: quoted-printable RECOMMENDED 4. Content-Type: application/epp+xml REQUIRED In this example, the encoding declaration of both the XML document and MIME entity is "iso-8859-1", and the Content-Transfer-Encoding is quoted-printable. From: epp+smtp@utterly-bogus.nld To: epp+smtp@pseudo-random.nld Date: whenever Subject: test 3: domain-create signed, unencrypted, no receipt requested Message-Id: <200210081114.HAA06363@utterly-bogus.nld> Mime-Version: 1.0 Content-Type: multipart/encrypted; protocol="application/pgp-encrypted"; boundary="42" --42 Content-Type: application/pgp-encrypted Version: 1 --42 Content-Type: application/octet-stream -----BEGIN PGP MESSAGE----- E Content-Type: application/epp+xml; charset="iso-8859-1" E Content-Transfer-Encoding: quoted-printable E E E E E E E example.tld E 2 E ns1.example.tld E ns1.example2.tld E jd1234 E sh8013 E sh8013 E 2fooBAR E E E ABC-12345 E E -----END PGP MEESAGE----- --42 Lines beginning with a "E" are Encrypted. Decryption is left as an exercise for the reader. Brunner-Williams Expires April 21, 2003 [Page 14] Internet-Draft EPP SMTP Transport October 2002 9. Example: Signed, Encrypted, No Receipt Requested Sender sends signed encrypted data, does NOT request a receipt. The MIME fields of interest are: 1. Mime-Version: 1.0 REQUIRED 2. Content-Type: multipart/encrypted 3. Content-Transfer-Encoding: quoted-printable RECOMMENDED 4. Content-Type: application/epp+xml REQUIRED In this example, the encoding declaration of both the XML document and MIME entity is "ibm037" (EBCDIC), and the Content-Transfer- Encoding is quoted-printable. From: epp+smtp@utterly-bogus.nld To: epp+smtp@pseudo-random.nld Date: whenever Subject: test 4: domain-create signed, unencrypted, no receipt requested Message-Id: <200210081114.HAA06364@utterly-bogus.nld> Mime-Version: 1.0 Content-Type: multipart/encrypted; protocol="application/pgp-encrypted"; boundary="42" --42 Content-Type: application/pgp-encrypted Version: 1 --42 Content-Type: application/octet-stream -----BEGIN PGP MESSAGE----- E Content-Type: multipart/signed; E protocol="application/pgp-signature"; boundary="24" E Content-Disposition: inline E E --24 E & Content-Type: application/epp+xml; charset="ibm037" E & Content-Transfer-Encoding: quoted-printable E & E & E & E & E & E & E & example.tld E & 2 E & ns1.example.tld E & ns1.example2.tld E & jd1234 E & sh8013 E & sh8013 E & 2fooBAR E & E & E & ABC-12345 E & E & E & --24 E E Content-Type: application/pgp-signature E Content-Disposition: inline E E -----BEGIN PGP SIGNATURE----- E Version: GnuPG v1.0.7 (FreeBSD) E E iD8CBQE85tUtWry0BWjoQKURAtV1AJoC7/RCMhS86o2RS53zcx2gdZroYACg0xj6 E VPugCOXxguA/yd9VF6qoNsM= E =ApJ4 E -----END PGP SIGNATURE----- E E --24 -----END PGP MESSAGE----- --42 The signature is calculated over lines beginning with a "&". Lines begining with a "E" are Encrypted. Decryption is left as an exercise for the reader. Brunner-Williams Expires April 21, 2003 [Page 16] Internet-Draft EPP SMTP Transport October 2002 10. Example: Signed, Unencrypted, No Receipt Requested Sender sends signed unencrypted data, does NOT request a receipt. The MIME fields of interest are: 1. Mime-Version: 1.0 REQUIRED 2. Content-Type: multipart/signed 3. Content-Type: application/epp+xml REQUIRED 4. Content-Transfer-Encoding: base64 RECOMMENDED In this example, the encoding declaration of both the XML document and MIME entity is "big5", and the Content-Transfer-Encoding is base64. From: epp+smtp@utterly-bogus.nld To: epp+smtp@pseudo-random.nld Date: whenever Subject: test 5: domain-create signed, unencrypted, no receipt requested Message-Id: <200210081114.HAA06365@utterly-bogus.nld> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="42" Content-Disposition: inline --42 & Content-Type: application/epp+xml; charset="big5" & Content-Transfer-Encoding: base64 & & & & & & & example.tld & 2 & ns1.example.tld & ns1.example2.tld & jd1234 Brunner-Williams Expires April 21, 2003 [Page 17] Internet-Draft EPP SMTP Transport October 2002 & sh8013 & sh8013 & 2fooBAR & & & ABC-12345 & & --42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VCpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --42 The signature is calculated over lines beginning with a "&". Brunner-Williams Expires April 21, 2003 [Page 18] Internet-Draft EPP SMTP Transport October 2002 11. Example: Unsigned, Encrypted, No Receipt Requested Sender sends unsigned encrypted data, does NOT request a receipt. The MIME fields of interest are: 1. Mime-Version: 1.0 REQUIRED 2. Content-Type: application/pkcs7-mime 3. Content-Type: application/epp+xml REQUIRED 4. Content-Transfer-Encoding: base64 RECOMMENDED In this example, the encoding declaration of both the XML document and MIME entity is "euc-jp", and the Content-Transfer-Encoding is base64. From: epp+smtp@utterly-bogus.nld To: epp+smtp@pseudo-random.nld Date: whenever Subject: test 6: domain-create signed, unencrypted, no receipt requested Message-Id: <200210081114.HAA06367@utterly-bogus.nld> Mime-Version: 1.0 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m E Content-Type: application/epp+xml; charset="euc-jp" E Content-Transfer-Encoding: base64 E E E E E E E example.tld E 2 E ns1.example.tld E ns1.example2.tld Brunner-Williams Expires April 21, 2003 [Page 19] Internet-Draft EPP SMTP Transport October 2002 E jd1234 E sh8013 E sh8013 E 2fooBAR E E E ABC-12345 E E Lines beginning with a "E" are Encrypted. Decryption is left as an exercise for the reader. Brunner-Williams Expires April 21, 2003 [Page 20] Internet-Draft EPP SMTP Transport October 2002 12. Example: Signed, Encrypted, No Receipt Requested Sender sends signed encrypted data, does NOT request a receipt. The MIME fields of interest are: 1. Mime-Version: 1.0 REQUIRED 2. Content-Type: multipart/signed 3. Content-Type: application/epp+xml REQUIRED 4. Content-Transfer-Encoding: base64 RECOMMENDED In this example, the encoding declaration of both the XML document and MIME entity is "bjecree", and the Content-Transfer-Encoding is base64. From: epp+smtp@utterly-bogus.nld To: epp+smtp@pseudo-random.nld Date: whenever Subject: test 8: domain-create signed, encrypted, no receipt requested Message-Id: <200210081114.HAA06368@utterly-bogus.nld> Mime-Version: 1.0 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m boundary="42" --42 E Content-Type: multipart/signed; micalg=sha1; E protocol="application/pkcs7-signature"; boundary="42" E Content-Disposition: inline E E & Content-Type: application/epp+xml; charset="bjecree" E & Content-Transfer-Encoding: base64 E & E & E & E & E & E & E & example.tld E & 2 E & ns1.example.tld E & ns1.example2.tld E & jd1234 E & sh8013 E & sh8013 E & 2fooBAR E & E & E & ABC-12345 E & E & E --42 E Content-Type: application/pkcs7-signature; name=smime.p7s E Content-Transfer-Encoding: base64 E Content-Disposition: attachment; filename=smime.p7s E E ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 E 4VCpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj E n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 E 7GhIGfHfYT64VQbnj756 E --42 Brunner-Williams Expires April 21, 2003 [Page 22] Internet-Draft EPP SMTP Transport October 2002 13. Receiver Message Structures This section is intentionally blank, pending implementation. Brunner-Williams Expires April 21, 2003 [Page 23] Internet-Draft EPP SMTP Transport October 2002 14. Bulk Transport Large EPP message bodies may be fragmented by message transfer agents. A subtype of message/partial is defined in [RFC2046] to allow large objects to be delivered as fragments in separate pieces of mail and to be reassembled by the receiving user agent. If the message/partial subtype is used, three parameters must be specified in the Content-Type field: a unique identifier, a sequence identifier, and a sequence terminator. Note that sequence identifiers begin with 1, not 0. Content-Type: Message/Partial; number=2; total=3; id="200210081114.HAA06360@utterly-bogus.nld" Content-Type: Message/Partial; id="200210081114.HAA06360@utterly-bogus.nld"; number=2 But the third piece MUST specify the total number of fragments: Content-Type: Message/Partial; number=3; total=3; id="200210081114.HAA06360@utterly-bogus.nld" It is possible that a piece of a partial message, upon re-assembly, contains a partial message as well. Large EPP message body transport may also be accomplished without fragmentation. A subtype of external-body is defined in [RFC2046] to indicate that the actual body data are referenced by the message, but not included in the message. The access-type parameter values for the external-body subtype includes FTP, to indicate that the message body is accessible as a file using the FTP [RFC959] protocol. For this access-type, the following additional parameters are mandatory: NAME -- The name of the file that contains the actual body data, SITE -- A machine from which the file may be obtained, MODE -- MUST be IMAGE if the encoding declaration of MIME entity (and presumably the XML document) is NOT us-ascii, otherwise this parameter is optional Note: A login id and password for the machine named by the SITE parameter are not specified as content-type parameters, and must be obtained from the user. The use of the external-body subtype and an access-type of FTP are RECOMMENDED for large messages between limited size sets of EPP peers, for which the EPP authentication mechanism is Brunner-Williams Expires April 21, 2003 [Page 24] Internet-Draft EPP SMTP Transport October 2002 adequate, e.g., escrow messaging, and inter-registry messaging. The use of the external-body subtype and an access-type of ANON-FTP are RECOMMENDED for messages which do not require authentication, e.g., public escrow messaging. In this example, the encoding declaration of both the XML document and MIME entity is "gb2312", and the MODE is IMAGE. From: epp+smtp@utterly-bogus.nld To: epp+smtp@pseudo-random.nld Date: whenever Subject: test bulk B: external body reference Message-Id: <200210101118.HAA2853@utterly-bogus.nld> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="42" --42 [This is an optional inline summary of the referenced body.] --42 Content-Type: Message/External-body; name="sufficiently-useful-identifier.xml"; site="ftp.utterly-bogus.nld"; access-type="ftp"; directory="registry-Y/posted" mode="image" Content-Type: application/epp+xml; charset="gb2312" Content-ID: <2002-10-9150009@utterly-bogus.nld> --42 Brunner-Williams Expires April 21, 2003 [Page 25] Internet-Draft EPP SMTP Transport October 2002 15. Security Considerations Most of this memo is concerned with secure transport of EPP data, and considers endpoint authentication, data security, data integrity and [in its next revision] non-repudiation of origin and non-repudiation of receipt. Early reviewer's comments and author's nigglings: 1. are there EPP-unique bits not MIME-generic? (Dave), 2. "man-in-the-middle" attacks (Dave), 3. denial-of-service" attacks (Dave), 4. the locus of authority for EPP data is variable, see "thick" vs "thin" registry design considerations, elsewhere (Eric), 5. extending message-level mechanisms to message fragments (Eric), 6. other [More closing mumble.] Brunner-Williams Expires April 21, 2003 [Page 26] Internet-Draft EPP SMTP Transport October 2002 16. Internationalization Considerations Since the publication of [RFC1766], now [RFC3066][BCP47], meta-data taging, restricted to the repitoires defined in [ISO639] and [ISO3166], have been widely (mis)understood to exhaust this subject. With the publication of [RFC2130] and its sequela [RFC2277][BCP18] and [RFC2279], universal code-set dependency, restricted to the repitoires defined in [UNICODE], have also been widely (mis)understood to exhaust this subject. The astute reader of this memo will have observed that neither of these classes of restrictions has been observed here. Encoding has been signaled between the EPP peers, consistent with the normative texts defining TCP, SMTP, MIME, XML, and EPP, using meta-data, without dependency upon [ISO639], [ISO3166], or an IETF-defined post- hoc repository of meta-data [RFC2978], nor upon [UNICODE], or any encoding strictly-extending ASCII. The encodings used outside the limits imposed by [RFC1766] et seq., and by [UNICODE] are: 1. ibm037 (aka "EBCDIC"), first implemented in OS/360, April 1964 2. big5, first defined in 1984 by the Taipei Computer Association 3. euc-jp, first defined in 1987 by XPG/3, see also: euc-cn, euc-kr, euc-tw. Note Bene: EUC has no requirement that code set 0 be ASCII. 4. sjis, see also JIS X 0208:1997 5. bjecree, first defined by Bill Jancewicz (SIL), and adopted by the Naskapi Cree First Nation, and other Cree First Nations Other POSIX Locale Condisderations This memo introduces no string collation, character case mapping or equivalence classing, message cataloging, monetary, numeric, or date/time formatting considerations beyond those introduced in [EPP-P]. Brunner-Williams Expires April 21, 2003 [Page 27] Internet-Draft EPP SMTP Transport October 2002 References [1] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, BCP 9, October 1996. [2] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [3] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [4] Freed, N., "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [5] Freed, N., "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [6] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [7] Freed, N., "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996. [8] Freed, N., "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996. [9] Galvin, J., "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995. [10] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996. [11] Elkins, M., "MIME Security with OpenPGP", RFC 3156, August 2001. [12] Callas, J., "OpenPGP Message Format", RFC 2440, November 1998. [13] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. [14] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [15] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 1892, January 1996. Brunner-Williams Expires April 21, 2003 [Page 28] Internet-Draft EPP SMTP Transport October 2002 [16] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998. [17] Hollenbeck, S., "Extensible Provisioning Protocol", , August 2002. [18] Hollenbeck, S., "Extensible Provisioning Protocol Contact Mapping", , August 2002. [19] Hollenbeck, S., "Extensible Provisioning Protocol Domain Name Mapping", , August 2002. [20] Hollenbeck, S., "Extensible Provisioning Protocol Host Mapping", , August 2002. Author's Address Eric Brunner-Williams Wampumpeag, LLC 1415 Forest Avenue Portland, Maine 04103 United States EMail: brunner@nic-naa.net Brunner-Williams Expires April 21, 2003 [Page 29] Internet-Draft EPP SMTP Transport October 2002 Appendix A. Acknowledgements Many thanks go to the authors of MIME-based Secure EDI IETF Draft, who's work is shamelessly expropriated, and to many of the contributors to the IETF EPP drafts. In addition the author thanks Marshall Rose who provided the extremely useful [RFC2629] document type description and xml2rfc tool used to edit this specification. The author may yet learn how to use this tool. The author especially thanks the National Cooperative Business Association, and the Swiss Education and Research Network, without who's generous funding this work would not have been possible. Brunner-Williams Expires April 21, 2003 [Page 30] Internet-Draft EPP SMTP Transport October 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Brunner-Williams Expires April 21, 2003 [Page 31]