Individual Contribution E. Brunner-Williams
Internet-Draft Wampumpeag
Expires: April 21, 2003 October 21, 2002
EPP transport mapping for SMTP
<draft-brunner-epp-smtp-00.txt>
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
<?xml version="1.0" encoding="us-ascii" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
epp-1.0.xsd">
<command>
<create>
<domain:create
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
domain-1.0.xsd">
<domain:name>example.tld</domain:name>
<domain:period unit="y">2</domain:period>
<domain:ns>ns1.example.tld</domain:ns>
<domain:ns>ns1.example2.tld</domain:ns>
<domain:registrant>jd1234</domain:registrant>
<domain:contact type="admin">sh8013</domain:contact>
<domain:contact type="tech">sh8013</domain:contact>
<domain:authInfo type="pw">2fooBAR</domain:authInfo>
</domain:create>
</create>
<clTRID>ABC-12345</clTRID>
Brunner-Williams Expires April 21, 2003 [Page 9]
Internet-Draft EPP SMTP Transport October 2002
</command>
</epp>
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
&
& <?xml version="1.0" encoding="sjis" standalone="no"?>
& <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
& xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
& xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
& epp-1.0.xsd">
& <command>
& <create>
& <domain:create
& xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
& xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
& domain-1.0.xsd">
& <domain:name>example.tld</domain:name>
& <domain:period unit="y">2</domain:period>
& <domain:ns>ns1.example.tld</domain:ns>
& <domain:ns>ns1.example2.tld</domain:ns>
& <domain:registrant>jd1234</domain:registrant>
Brunner-Williams Expires April 21, 2003 [Page 11]
Internet-Draft EPP SMTP Transport October 2002
& <domain:contact type="admin">sh8013</domain:contact>
& <domain:contact type="tech">sh8013</domain:contact>
& <domain:authInfo type="pw">2fooBAR</domain:authInfo>
& </domain:create>
& </create>
& <clTRID>ABC-12345</clTRID>
& </command>
& </epp>
--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 <?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
E <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
E xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
E xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
E epp-1.0.xsd">
E <command>
E <create>
E <domain:create
Brunner-Williams Expires April 21, 2003 [Page 13]
Internet-Draft EPP SMTP Transport October 2002
E xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
E xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
E domain-1.0.xsd">
E <domain:name>example.tld</domain:name>
E <domain:period unit="y">2</domain:period>
E <domain:ns>ns1.example.tld</domain:ns>
E <domain:ns>ns1.example2.tld</domain:ns>
E <domain:registrant>jd1234</domain:registrant>
E <domain:contact type="admin">sh8013</domain:contact>
E <domain:contact type="tech">sh8013</domain:contact>
E <domain:authInfo type="pw">2fooBAR</domain:authInfo>
E </domain:create>
E </create>
E <clTRID>ABC-12345</clTRID>
E </command>
E </epp>
-----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 & <?xml version="1.0" encoding="ibm037" standalone="no"?>
E & <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
E & xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
Brunner-Williams Expires April 21, 2003 [Page 15]
Internet-Draft EPP SMTP Transport October 2002
E & xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
E & epp-1.0.xsd">
E & <command>
E & <create>
E & <domain:create
E & xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
E & xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
E & domain-1.0.xsd">
E & <domain:name>example.tld</domain:name>
E & <domain:period unit="y">2</domain:period>
E & <domain:ns>ns1.example.tld</domain:ns>
E & <domain:ns>ns1.example2.tld</domain:ns>
E & <domain:registrant>jd1234</domain:registrant>
E & <domain:contact type="admin">sh8013</domain:contact>
E & <domain:contact type="tech">sh8013</domain:contact>
E & <domain:authInfo type="pw">2fooBAR</domain:authInfo>
E & </domain:create>
E & </create>
E & <clTRID>ABC-12345</clTRID>
E & </command>
E & </epp>
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
&
& <?xml version="1.0" encoding="big5" standalone="no"?>
& <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
& xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
& xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
& epp-1.0.xsd">
& <command>
& <create>
& <domain:create
& xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
& xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
& domain-1.0.xsd">
& <domain:name>example.tld</domain:name>
& <domain:period unit="y">2</domain:period>
& <domain:ns>ns1.example.tld</domain:ns>
& <domain:ns>ns1.example2.tld</domain:ns>
& <domain:registrant>jd1234</domain:registrant>
Brunner-Williams Expires April 21, 2003 [Page 17]
Internet-Draft EPP SMTP Transport October 2002
& <domain:contact type="admin">sh8013</domain:contact>
& <domain:contact type="tech">sh8013</domain:contact>
& <domain:authInfo type="pw">2fooBAR</domain:authInfo>
& </domain:create>
& </create>
& <clTRID>ABC-12345</clTRID>
& </command>
& </epp>
--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 <?xml version="1.0" encoding="euc-jp" standalone="no"?>
E <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
E xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
E xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
E epp-1.0.xsd">
E <command>
E <create>
E <domain:create
E xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
E xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
E domain-1.0.xsd">
E <domain:name>example.tld</domain:name>
E <domain:period unit="y">2</domain:period>
E <domain:ns>ns1.example.tld</domain:ns>
E <domain:ns>ns1.example2.tld</domain:ns>
Brunner-Williams Expires April 21, 2003 [Page 19]
Internet-Draft EPP SMTP Transport October 2002
E <domain:registrant>jd1234</domain:registrant>
E <domain:contact type="admin">sh8013</domain:contact>
E <domain:contact type="tech">sh8013</domain:contact>
E <domain:authInfo type="pw">2fooBAR</domain:authInfo>
E </domain:create>
E </create>
E <clTRID>ABC-12345</clTRID>
E </command>
E </epp>
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 & <?xml version="1.0" encoding="bjecree" standalone="no"?>
E & <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
E & xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
E & xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
E & epp-1.0.xsd">
E & <command>
E & <create>
E & <domain:create
Brunner-Williams Expires April 21, 2003 [Page 21]
Internet-Draft EPP SMTP Transport October 2002
E & xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
E & xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0
E & domain-1.0.xsd">
E & <domain:name>example.tld</domain:name>
E & <domain:period unit="y">2</domain:period>
E & <domain:ns>ns1.example.tld</domain:ns>
E & <domain:ns>ns1.example2.tld</domain:ns>
E & <domain:registrant>jd1234</domain:registrant>
E & <domain:contact type="admin">sh8013</domain:contact>
E & <domain:contact type="tech">sh8013</domain:contact>
E & <domain:authInfo type="pw">2fooBAR</domain:authInfo>
E & </domain:create>
E & </create>
E & <clTRID>ABC-12345</clTRID>
E & </command>
E & </epp>
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]