Subject: how to exchange EPP content using SMTP transport

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 11 Oct 2002 13:13:47 -0400

Appologies for the cross-posting.

As Jon Crowcroft wrote to the ed2end list Monday, this is somewhat 1/2
baked, but comments are welcome.

Available via ftp from [216.220.241.233]
	user=anonymous
	pswd=guest (or whatever)
	file=pub/draft-brunner-epp-smtp-00.txt,html

Comments to me please, I like writing acknowledgements.

Eric

---

From: Dave Crocker <[email-masked]>
Date: Fri, 11 Oct 2002 12:14:48 -0700

Eric,

(ediint and 822 bcc'd to target discussion on the host list, provreg.)

MANY thanks for doing this.

Comments inline.

Friday, October 11, 2002, 10:13:47 AM, you wrote:
EBWiPM>    This memo defines mechanisms to secure (sign or encrypt or sign and
EBWiPM>    encrypt) one or more EPP messages in any SMTP message.  This memo
EBWiPM>    does not define mechanism to secure (sign or encrypt or sign and
EBWiPM>    encrypt) individual XML elements within an EPP message.

Are there any requirements for epp/smtp security that are distinctive?  My
guess is that the requirements for epp/smtp are the same as for any MIME
object needing the same security services.

That is, if we say that these objects may need privacy, authentication and
signed receipt, then it should the security-related work of this specification
should be done... as long as we can cite an external reference that defines
the common way(s) to achieve those services.

From work in IMPP I've come to believe that we need a MIMEsec specification
that is common to all MIME objects, for these common services.  (Well, ok,
signed receipt is not yet common.)

Such a document should, essentially, take existing text from various special
efforts, like ediint and impp, as you have noted.  Would this be reasonable?

If yes, then the current specification should be able to cite a MIMEsec
document, for security basic security issues.  Given that it is a transaction
service, perhaps it needs to mention something about man-in-the-middle and DOS
attacks?

Otherwise, the normative (specification) portion could then focus on
definition of the MIME type and, perhaps, profile the bulk carriage details.

Having all those examples is really excellent.

EBWiPM> 2. Background Summary
EBWiPM> 
EBWiPM>    Some language about these three registry protocols, and the
EBWiPM>    applicability of SMTP as a transport protocol.  TBD.
EBWiPM> 
EBWiPM>    This table compares the salient characteristics of EPP, RRP and SRS.

The table is interesting, but I am not clear what purpose it servces in the
current specification.  Please clarify.

EBWiPM> 
EBWiPM> 13. Receiver Message Structures
EBWiPM> 
EBWiPM>    This section is intentionally blank, pending implementation.

what does "receiver message structures" mean?  are these the replies?

EBWiPM>    [3]   Crocker, D., "Simple Mail Transfer Protocol", RFC 822, STD 11,
EBWiPM>          August 1982.

"Standard for the Format of ARPA Internet Text Messages"

probably should also cite rfc2822, resnick, "Internet Message Format" and
rfc2821, klensin, "Simple Mail Transfer Protocol".

d/