Eva,
You raise a good point about compatibility w/ X.435 being a major goal of
any Internet EDI effort. By this I assume you mean functional compatibility;
there is no chance for *cryptographic* compatibility for the same reason
that PEM can't interwork w/ secure X.400: different bit strings being input
to the actual encryption and signature processes. Perhaps a useful start
for the effort would be to categorize all of the X.435 protocol elements as
to function (extracted X12 header fields, security, notification, forwarding,
etc.) and the "equivalent" X12/EDIFACT, PEM, and/or X.400 fields. I'll
take a stab at the security part if anyone is interested.
BTW, is anyone shipping (or more importantly buying) X.435 yet? Will it
be required in GOSIP v3 (IGOSS)? There certainly doesn't seem to be a
plethora of vendors doing secure 1988 X.400 right now, much less X.435. I
have talked to a number of people at the OIW's X.400/EDI group, and it seems
like there are several (very sophisticated) users who want to use it for JIT
inventory and similar purposes (and will move everything to X.400 to get
there), while everyone else (and esp. the common carriers) still look at
X.400 as a pipe, like bisync or X.25, to get transactions from here to there
(in which case 84 X.400 is just fine).
This brings up a related point: interworking between secure messaging
systems might be simplified if the end-to-end security features were
encapsulated within the message content like PEM (or MSP), i.e., a "secure
content type", rather than being placed in the message envelope like 88 X400.
This would at least allow a gateway to pass the message thru (unmodified)
in some cases. The only mechanism to do this right now is the OIW PEM body
part, which just takes a PEM message content and stuffs it into a P2 body
part. Another possibility would be to put the security features inside the
EDI transaction; I believe there is a move afoot to do this for some of the
X.435 features in X12.
Finally, I am (obviously) rather familiar with the product Sven mentioned,
and I can assure you it has all of the functionality of X.435 and more; it
is not, however, compatible with it. It also allows users to bind
authorization (read monetary) limits and cosignature requirements into an
"authorization certificate" to automate the signoff and approval process,
among other things.
Regards,
Rich