So
far we have had a very lively discussion regarding satisfaction of the
security requirements for the Message Servicing Specification. Based on the discussions the
following items were agreed.
1.
Payload
security is not the responsibility of the MSH. The function may be performed on a
B2B server that also hosts the MSH; however the MSH does not own the
operations. There was agreement
that the MSH would not alter the
payload.
2.
Applications
should be able to sign payloads using S/MIME, PGP/MIME, or XML-DSig. The POC will be asked to ensure that
signed payloads can be reliably communicated between MSH
agents.
3.
Applications
should provide confidentiality using S/MIME or PGP/MIME. The POC will be asked to ensure that
encrypted payloads can be reliably communicated between MSH
agents.
4.
The
MSH must support the signing of an entire ebXML document. There are two alternatives on the
table—one using XML/DSig another using S/MIME. These two proposals impact the
current version of the MSH specification (0.8). The XML/DSig solution will allow us
to use the ebXML header, as it is currently defined. The S/MIME signing does inject
difficulties, especially where they involve multiple signatures or message
routing.
5.
The
MSH must support selective encryption of data within the ebXML header. It was agreed that this requirement
could not be satisfied in phase 1,2, or 3. It was suggested that S/MIME be used
to satisfy this requirement—that will require significant restructuring of
the ebXML Header. It was also
suggested that we wait and employ XML-encryption once that standard becomes
available. Assuming that the
XML-encryption work takes a form similar to the XML/DSig product, we should
be able to use the XML-encryption standard with the current structure of the
ebXML header.
Chris
and Maryann are pleading for a teleconference to discuss points 4 and 5. The
major question is whether the group is prepared to restructure the ebXML
document header to support the broad security requirement (as they apply to
the entire ebXML document). It
is important that TRP think about the proposals that are going to come from
the security group and that they are prepared to discuss them during the
face-to-face scheduled for January (London). Formal notification of this
request will be coming directly from Maryann, the chairperson of the
Security Work Group.