Aug. 28, 2006

Lowering launching costs and reducing ongoing troubleshooting expenses are vital to boosting the efficiency and overall ROI for supply chain users in the B2B segment.

Additionally, various software certification testing enables companies to accurately test their products under real-world conditions and close supervision of quality assurance engineers.

Addressing and diagnosing problems before products are introduced into production environments greatly improves the efficiency of supply chains by reducing setup and deployment delays and their inherent costs. In the end, supply chain users benefit of a win-win situation.

For most companies involved in the B2B segment, during interoperability testing of secure transports, Drummond Group Inc. (DGI) has found that, most of the time, a significant percentage of the errors can be traced back to their underlying technologies.

Secure technologies such as AS1, AS2, AS3 and ebMS build upon core underlying technologies such as certificates and security toolkits. Of course, not all errors found are related to these technologies. Other types of errors can also occur as a result of misinterpreting specifications for these transports or from incompatibility in other key technologies such as HTTP, FTP and SMTP in many mail servers.

In this commentary, we will focus our attention on interoperability issues revolving around certificates and security toolkits, which are at the core of secure transport technologies. Increasing the interoperability of these core technologies can deliver a positive impact on supply chains and the overall B2B sector.

Before any interoperability testing can begin, B2B participants must configure their systems with trading partner profiles. One essential piece of information to exchange is certificates and there are as many as four categories: SSL certificates, encryption and digital signature certificates, and certification authority (CA) trusted certificates.

In general, we have seen that all products can handle all categories of certificates and even the simplest case where just one self-signed certificate is used for all purposes. However, it is still worth noting that individual partners must agree how many certificates are to be used and what types of certificates are to be used for each purpose. Once they do agree, the following types of errors can sometimes occur:

*Issues with generating certificates and extensions
*Issues with expiration of certificates

When generating certificates, there are many options which may be selected during the generation process. Innocuous as it may seem, this actually has a dramatic effect on interoperability. Setting just one attribute may cause the security toolkits to reject the certificate and may take weeks to debug. Currently, there are no "certificate profiles" or a listing of certificate attributes that are acceptable or not acceptable by each participating product.

The generation of certificates by many different toolkits can often lead to interoperability issues. For example, some toolkits may generate certificates and use extension keys to store information which other toolkits do not like or understand. These kinds of issues can take weeks to resolve.

There is an initiative currently underway to solve this problem which is known as Certificate Exchange Management (CEM). Once implemented, problems associated with managing multiple deployed certificates with different expiration dates (updating certificates that will expire soon, for instance) will be solved. CEM provides a way for exchanging, updating and importing certificates in an automated manner.

Security toolkits provide a way to save development time and effort in building your own security processing logic. Building your own security toolkit is a big investment and has many risks. That is why many B2B server vendors buy third-party security toolkits. Vendors that provide security toolkits have expertise in cryptography and focus on this facet as their core business. This allows B2B vendors to focus on implementing standards into their applications.

For example, in an AS2 server, the AS2 engine will interface to the HTTP server, certificate store and use a security toolkit for the encryption/decryption, and signature validation of the AS2 message.

Security toolkits provide a lot of functionality. For example:

* Asymmetric cryptographic functions like RSA, DSA, DSS
* Symmetric cryptographic functions like DES, Triple DES, IDEA
* Various hash functions like MD2, MD4, MD5, SHA
* X.509 key certification functions, cross-certification & certificate revocation
* Utilities to sign, verify, encrypt and decrypt files
* Utilities and library functions for the operation of certification authorities
* Utilities and library functions for S/MIME processing

Thus, a large core of the processing logic around a B2B secure message resides in the functionality that security toolkits provide. It should be no surprise that the source of interoperability errors between B2B servers may sometimes be the result of incompatibility between the security toolkits themselves. For example, some toolkits add their own extensions or provide some level of added functionality that does not quite conform to the specifications. This functionality is needed, but can be the source of interoperability errors when developing applications.

Security toolkits also are undergoing upgrades and revisions and the introduction of a new version may cause an incompatibility with a current version of a different security toolkit. DGI has observed this to be the case in several AS2 interoperability tests. Security standards evolve, as does programming architecture and technology. Security toolkits need to be upgraded, but this may bring its own interoperability risk.

A security toolkit is another additional software layer that comes into play that can introduce interoperability issues. For instance, some toolkits seem to use slightly different fields or tags for the fields inside X509 common names.

Security specifications are sometimes difficult to interpret. Also, not all security toolkits follow them to the letter, or code incorrectly around the specification or misinterpret the specifications altogether. All can cause interoperability errors between security toolkits.

A critical reason to use a toolkit is to increase cryptography interoperability and thus reduce application interoperability issues. However, security toolkits do not always adhere to standards and can be the cause of secure transport interoperability issues.

Security toolkits can be compliant with standards and yet still be incompatible with each other. Why? The reason is that not all of the specification was implemented or improperly implemented. Or, it could have been "broken" during a security toolkit version upgrade.

DGI facilitates interoperability testing of B2B standards, including AS1, AS2, AS3 and ebMS. Although DGI test plans are based on the respective technical specifications for these standards, it is becoming clear that the scope of issues found during interoperability testing goes beyond these B2B standards.

Since B2B applications are built around third-party technologies, which must adhere to standards, a complete and comprehensive B2B interoperability test must take into account these third-party technologies. These technologies are critical in building B2B secure transport applications.

During DGI interoperability testing, participants work with their security toolkit vendors to resolve security-related interoperability issues. Issues are identified based on the B2B standard test plan and is not a comprehensive security toolkit interoperability test.

Even though DGI-certified B2B applications have resolved security toolkit issues as it pertains to the respective B2B standard involved, this may represent only a portion of the security toolkit interoperability issues.

To fully identify and resolve the greatest portion of security toolkit interoperability issues, the ideal testing scenario would include interoperability testing the security toolkits first, using more detailed cryptographic test plans and test cases from various industries where they are used.

This would provide more reliability and robustness to the B2B applications, as well as all other applications in various industries using these security toolkits.

Accomplishing this would benefit supply chains and end users alike.

Source: Line 56