3 Mar 2004 22:04
25 Mar 2004 20:12
Comments on RFC 3335
Sean P. Turner <turners <at> ieca.com>
2004-03-25 19:12:32 GMT
2004-03-25 19:12:32 GMT
All, This is my first post to this list so please take all my comments as constructive. And I apologize for this being so long. A recent message by Alberti on the S/MIME WG list compelled me to go off and read RFC3335. I ended up with some major and minor concerns on RFC 3335. The major ones deal with: - processing requirements for signed receipt requester (#28). I may have missed this (I thought I did a pretty good job of scouring the documents for MUSTs), but I can't seem to find where requirements for signed receipt requester to process the returned signed receipt. - processing requirements for errors (#31 and 32). Again I may have missed it or misunderstood it, but I think the requirements for the error processing could result in a recipient having an error, generating a signed receipt, but not supporting the fields necessary to indicate that processing failed in the signed receipt that is returned. - defining "signed receipts" differently that S/MIME ESS. Since S/MIME has a specific service called "signed receipts" I think it is really confusing to say that a signed MDN is also a "signed receipt" - without at least saying somewhere in the document that the service provided by RFC 3335 is not the same as in ESS. - retaining copies of original message/signed receipt. There are lots of places where it says what's needed to get the NRR service but they never say that the originator has to retain a copy of the original signed message or that the recipient has to retain a copy of the signed receipt. I had 38 comments (attached below) most were editorial, but the major(Continue reading)
26 Mar 2004 21:50
I-D ACTION:draft-ietf-ediint-as3-02.txt
<Internet-Drafts <at> ietf.org>
2004-03-26 20:50:00 GMT
2004-03-26 20:50:00 GMT
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Electronic Data Interchange-Internet Integration Working Group of the IETF. Title : FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet Author(s) : T. Harding, R. Scott Filename : draft-ietf-ediint-as3-02.txt Pages : 30 Date : 2004-3-26 This Applicability Statement (AS) describes how to exchange structured business data securely using the File Transfer Protocol (FTP) for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 or UN/EDIFACT), or other data used for business-to-business data interchange for which MIME packaging can be accomplished using standard MIME content-types. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements employ multipart/signed replies to the original message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ediint-as3-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ediint-as3-02.txt".(Continue reading)
29 Mar 2004 16:43
RE: I-D ACTION:draft-ietf-ediint-as3-02.txt
Alberti Antoine <aalberti <at> axway.com>
2004-03-29 14:43:08 GMT
2004-03-29 14:43:08 GMT
I have a few comments about this draft: Globally: Why did you skip 2 lines after each line? 2.1: Why is it that a trading application must not embed an FTP server to work without an external one? 4.2: Once again, this chapter is essential, but does not state anything. This bullet representation is not standardized, and does not clarify things. On the other hand, RFC 2119 defines how things should be litteraly described without ambiguity. EDI-INT uses subsets of RFCs. For example, this draft only uses multipart-signed for signing using S/MIME, and RFC 2634 defines a behavior about "triple wrapping". So what is an application supposed to do with the other cases that are technically valid? What does a sender MUST/MAY do, and what does a receiver MUST/MUST NOT support? To be a bit more technical, this draft is based on many other high-level standards, so how can a developper do to integrate existing libraries that have complete support of the underlying standards, and which functions does he have to restrict? When you add "(encrypted)", does this mean that the corresponding layer encrypts, or that it may be indirectly encrypted by an outermost layer? 6.1: This is a detail, and the choice of using this word is not technically illegal, but SFTP is an existing and totally different protocol. While talking about authentication, is there any link between FTP authentication, AS3-To, AS3-From, and certificates? 6.2: "Large files are handled correctly by the TCP layer". I agree (actually the TCP layer does not handle files, so this does not sound false), but why is this sentence here? This section looks more like a discussion about compression than about large files, doesn't it? 7.2 paragraph 2: I don't really get the diagram. What is the "[FTP Server]", for instance? From 2.1, we can guess that trading applications only embed FTP clients, using an intermediate server. So why is it that this diagram does not represent it? By the way, the FTP cinematic is not described: how do partners "send" a message or an MDN? Which upload(Continue reading)
RSS Feed