ebXML Standards Overview

The standard suggests a variety of measures to ameliorate these risks, and we will now discuss these measures in detail. Before proceeding to these measures, a summary of the specification’s requirements and suggestions for generating an XML Signature signature would be helpful.

The first thing to note is that the suggested, but not required, signature algorithm for generating signatures is DSA-SHA1. ebXML implementations must be able to verify signatures using this algorithm.

The signature is required to cover at least the SOAP envelope, but payload signing is at the discretion of the implementation. The SignedInfo element is required to have a Canonicalization element, a SignatureMethod element, and at least one Reference element.

A KeyInfo element is suggested, but not required. The completed namespace- qualified Signature element must be placed in the SOAP envelope element it signs.

It is required that the XML Signature Reference element for the SOAP envelope have a URI attribute value of “”, denoting that the signature is intended to apply to the document that contains the signature element. The SOAP envelope reference element is also required to have a Transforms element, whose children must conform to the following requirements.

The first transform must have an algorithm attribute denoting the XML Signature enveloped signature algorithm. The effect of this is to exclude the parent signature element and its descendents.

The second transform must have a child XPath element consisting of the following:

<XPath> not (ancestor-or-self::node()[@SOAP:actor="urn:oasis:names:tc:ebxml-msg:actor:nextMSH"] ancestor-or-self::node()[@SOAP:actor="http://schemas.xmlsoap.org/soap/actor/next"]  ) </XPath>

The purpose of this XPath transform is to exclude from the signature material any elements with SOAP actor attributes targeted for the next ebXML message service handler and their descendents, and also to exclude any elements with actor attributes that target the element at the next node (which may change en route).

It is suggested, but not required, that the last transform specify the XML Signature C14N transform, which will canonicalize the SOAP envelope without comments.

Note the required and suggested transforms apply only to the SOAP envelope and its contents. Suitable transforms for message payload nodes are at the discretion of the application.

We will now proceed to examine how ebXML suggests the various risks and dangers previously outlined can be guarded against.

Persistent Digital Signature

The standard requires that the only mechanism used to sign ebXML messages will be the XML Signature standard. This is considered persistent because the validity of the signature can be maintained under this standard even if new element content is added to the message, assuming suitable transforms are specified.

Persistent Signed Receipt

Any ebXML message that has itself been digitally signed may be acknowledged with an XML Signature signed message. The signed receipt must contain an XML Signature Reference element consistent with the message it’s acknowledging.

Nonpersistent Authentication/Integrity

The underlying communications protocol could be used to provide a layer of assurance of physical data integrity, and also to provide a level of mutual authentication. TLS, for example, can be used to ensure that messages have not been tampered with in transit, and to confirm that the two parties to an exchange have mutually satisfactory and trustworthy X.509 certificates.

Confidentiality

The standards envisage that the XML Encryption standard, when available, will be used to provide encryption services. Again, this would have the advantage that element content could be added to the document without breaking the encryption. In the absence of XML Encryption, implementations may choose to deploy an encrypting network protocol such as TLS to protect the confidentiality of messages while they’re in transit.

Authorization

Authorization services will ultimately be provided for ebXML using SAML. Until SAML is widely deployed and available, authentication can be provided by the underlying communication protocol. For example, mutually authenticated SSL could be deployed to establish the identity of sender and receiver to a reasonable degree of assurance. Once identities have been satisfactorily established, the implementation then could ensure that the entity involved is indeed entitled to access the resource in question, whatever it may be.

Trusted Time Stamps

The standard notes that various efforts are under development to develop standards for services offering trusted time-stamping services, and that ebXML will consider using these as they reach fruition.