ebXML Registry Security

We will now discuss the security considerations and factors inherent in using the ebXML Registry.

Overview

The importance of ensuring the authenticity, validity, and integrity of information stored in an ebXML registry is obvious. Remember, the registry contains collaboration protocol profiles, message formats, and business processes. If a malicious attacker were to infiltrate spurious instances of these entities into an ebXML registry, the results could at best be described as chaotic.

Standards Requirements

It would be helpful at this stage to review what the ebXML standards say about security.

Standards Overview

The ebXML standards document for registry services has a full and comprehensive set of security requirements. A number of general points are worth making about these requirements before we proceed to a more detailed examination of them.

The XML Signature standard is used to sign various entities. ebXML allows, but does not require, the embedding of certificates within these signatures. If a party decides not to embed the certificate, ebXML is agnostic as to how to validate the signature.

The confidentiality of messages in transit is suggested, but not required or specified. If HTTP is the deployed transport mechanism, then HTTPS is an obvious mechanism to add an encryption layer. Note, however, that an encryption layer would require prior agreement between the parties, because it’s not part of the standard—and in any event would only ensure confidentiality of the communications layer.

In the current version of the specification (ebXML Registry Services Specification v2.0, available online at http://www.ebxml.org/specs/), if you publish information in a registry, it’s public and the world can read it. There is no facility to restrict read access to registry contents. Organizations therefore need to be vigilant in considering both the overt and implied information content of what they’re publishing to ebXML registries. The overt information, for example, could simply be that a company is now registering as a trading partner in a new sector. The information could connote that a company is trying to establish itself in a market sector currently occupied by a major customer. The decision to publish this is obviously sensitive.

We will now discuss in detail the specific requirements and security mechanisms in the ebXML registry services specification.

Access Control

ebXML registries are required to implement an access control policy that recognizes the following three classes of users:

• ContentOwner The entity that submitted the content originally. It has read-write access to its own content.

• RegistryAdministrator Has read-write access to all objects in the registry.

• RegistryGuest Has read-only access to the registry. The specification notes that a RegistryGuest need not present an authenticating certificate.

Registry Content Security

These parts of the specification describe the mechanisms and techniques used to determine that the information contained in a registry is trustworthy.

The first step in achieving this is to require that all content submitted to the registry must be digitally signed with an XML Signature signature (see Chapter 4). The registry standard, at least in this revision, is lax about identifying who can submit content. Any “known entity” is allowed to submit data, with the identity of known entities presumably being verified by some out-of-band means, such as the manual exchange of certificates.

The originating entity is required to sign the message payload, specifically, as against the message headers. This signature is stored with the content and will be distributed to clients who request this information, so that the content and authenticity of the information can be verified.

ebXML also requires that when a registry distributes information to clients, the registry itself signs the message headers, with this signature including the digests of the payloads. The purpose of this is to ensure the integrity of data in transit. When ebXML Messaging Service is used, this imposes no further requirements because this inherently specifies XML Signature signatures in the SOAP header. When only SOAP With Attachments is in use, however, the requirements for a message header signature must be implemented explicitly.

Registry Security Conclusions

It must be acknowledged that the ebXML registry security requirements are at a fairly early stage of evolution, and operate at a very broad-brush level. They leave much detail to individual implementers. The decision not to require that certificates be embedded in XML Signature signatures, for example, leaves a broad panoply of trust and authentication issues squarely in the hands of those developing and deploying ebXML systems.