To:
owner-ietf-ediint@mail.imc.org, Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
CC:
ietf-provreg@cafax.se
From:
Dave Crocker <dhc2@dcrocker.net>
Date:
Fri, 11 Oct 2002 12:14:48 -0700
In-Reply-To:
<200210111713.g9BHDlpt002645@nic-naa.net>
Reply-To:
Dave Crocker <dhc2@dcrocker.net>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: how to exchange EPP content using SMTP transport
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/