Corporate.Net
Feature Article

Signed, Sealed & Delivered: CommerceNet Test Results

The components of the signed-receipt mechanism are many. The key elements are: The initial message can request that a receipt or signed receipt be returned to the message originator; the original message is signed, so the recipient can verify the sender and the integrity of the message; and the recipient of the original messages signs the signed receipt. The middle part of the signed receipt contains status fields and a copy of the original messages' MIC (integrity check value), among other components.

Possible errors included incorrect status codes, incorrect signed-receipt request strings, incorrect signed-receipt structures returned and failure of integrity, decryption and signature. We checked for all of these in tests No. 9 through No. 14.

When the Ink Dries Two main problems surfaced during testing. For one, interoperability in the PKI space is going to be much harder than many people currently believe. A ubiquitous, interoperable and worldwide PKI infrastructure probably won't be i n place for years. Also, some SMTP-X.400 gateways make the digital signature unusable and will cause problems for general-purpose electronic commerce. When all is said and done, several vendors have products that are on the right track. In addition to the products already on the market, two or three more should become available later this year.

Rik Drummond is president of the Drummond Group, a consultancy in electronic commerce and electronic messaging strategies, implementations and product selections. He chairs the IETF workgroup for EDI over the Internet (EDIINT) and is executive director of CommerceNet's EDI and Network Services Portfolio. He can be reached at drummond@onramp.net.

Lincoln Yarbrough worked with Rik to produce the individual tests and testing procedures used in the CommerceNet EDI Interoperability Test. Chuck Shih and Mats Jansson edited the IETF workgroup's EDIINT recommendations.


EDIINT Interoperability Test Phases
Phase I: MIME-Based EDI Exchanges

1. Test set recording

2. SMTP, MIME, single EDI-MIME (RFC1767) bodypart

3. SMTP, MIME, single EDI-MIME with tilde (~) for segment terminators

4. SMTP, MIME, 1,000-KB EDI in an EDI-MIME (RFC1767) bodypart

Phase II: Secure EDI Exchanges

5. SMTP, MIME, 20-KB binary and an EDI-MIME (RFC1767) bodypart

6. MIME, SMTP signed using multipart/signed MIME bodypart

7. MIME, SMTP encrypted using PKCS within a MIME bodypart

8. MIME, SMTP signed-then-encrypted within MIME bodypart

Phase III: Signed Receipt Exchanges

9. Unsigned receipt request with an unsigned receipt returned

10. Signed receipt request with a signed receipt returned

11. Signed request with a receipt dispos ition return code of

"authentication-failed"

12. Signed request with a receipt disposition return code of

"decryption-failed"

13. Signed request with a receipt disposition return code of "autoprocessed"

14. Signed request with an invalid signed receipt

Sample EDIINT Interoperability Test
An example of a short test description follows. (Some of the other test descriptions are several pages long.)

Test Name: MIME, SMTP Signed-then-Enveloped (Encrypted)

Test No.: 8

Test Description: The data from Test No. 4 is encrypted for confidentiality and signed per the draft-ietf-as1-03.txt specification.

Test Setup: Test No. 4, < < 512-bit>> key length for signature, < < 40-bit RC2>> for encryption, and MD5 message digest.

Initial State: Test No. 4

Expected Results: The data is the same as that sent, the signature is appropriate and the message digest is correct.



Internet Rx
By Todd Tannenbaum


Updated September 8, 1997

Valley View, Live!

Research and Reports

Storage Virtualization Guide
May 2012

Network Computing: May 2012

TechWeb Careers