[ebxml-msg-comment] Comments on Message Service Specification V2

["Michael C. Rawlins" <mike@rawlinsecconsulting.com>]

Though I can't find the e-mail anywhere, I recall seeing a message that 
said this specification was open for comment until June 30.  Please find 
attached a couple of comments on the specification.

Regards,



---------------------------------------------------------------
Michael C. Rawlins, Rawlins EC Consulting
www.rawlinsecconsulting.com
Comments on Message Service Specification Version 2.0

Mike Rawlins, Rawlins EC Consulting
mike@rawlinsecconsulting.com

Line range:
311-314

Comment type:
Technical

Rationale:
These statements seem to be a very liberal reading of the ebXML TA, and are at odds with the 
ebXML Requirements Specification 1.0.  In section 2.5.1 it clearly states that the ebXML 
architecture, in order to maximize the key objective of interoperability, will support a "common 
data transfer protocol" and "common network layer".

This level of choice in the messaging service does make a good tradeoff between interoperability, 
a key ebXML goal, and other requirements.

Suggested change:
I suggest this change as a pragmatic approach to enabling interoperability, requiring that 
implementations support a least common denominator while allowing them to support other 
options.   This is similar to the way that encryption algorithms are specified in S/MIME; an 
implementation may support several algorithms but it must at least support one specified 
algorithm.

Revise lines 311-314 to recognize requirements for "common data transfer protocol" and 
"common network layer" as mandated by the Requirements Specification, and note that these will 
be specified in section 1.3 on conformance.

Add to 1.3 Minimal Requirements for Conformance, starting at line 428, two new bullets:
"While not being prohibited from supporting other networking protocols, it must support IP Version 
4 [insert references to the appropriate RFCs] as a networking protocol.".

"While not being prohibiting from supporting other methods of data transfer, It must support HTTP 
and SMTP [insert references to the appropriate RFCs.]"

Line range:
1183-1187

Comment type:
Technical

Rationale:
The statements in this section may seem reasonable for the MSS, but leave a troubling hole in 
the ebXML architecture regarding encryption of the payload.  The net effect is that there is no 
minimal, required method specified in the totality of the ebXML specifications for encrypting the 
message payload.  The requirements for common security implementations, persistent 
confidentiality, and secure sending and receiving are therefore not satisfied.

Suggested change:
Line 1183 - change "Confidentiality ... MAY be provided" to "Confidentiality ... SHALL be 
provided".
As clarification, amend line 1187 to read:  " The XML Encryption standard MUST be supported 
and SHALL be the default ..."
Append after line 1187:  "Until XML Encryption achieves Recommendation status, S/MIME 
SHALL be supported."