Bob> So PEM can talk to PKCS, but not AOCE. And PGP and PEM can't
intercommunicate, because they use different algorithms, as does PEM and
DMS/MOSAIC/SKIPJACK/TESSURA. And God knows what the implications would
be of trying to tie the constructs of secure X.400 to the PEM public key
infrastructure, including PCA policies and the IPRA. And tying all this
to the EDI community will be even worse.
X12.58 (version 2) handles encryption, authentication and digital
signature for EDI just fine, thank you very much. It is the application
process, not some "PERSON" that needs to be assured that an EDI (or EFT)
transaction is trustworthy. The whole point to EDI is to eliminate the
people, quite the opposite goal from PEM and it's requirement to
"display" error messages. If the applications are this different, how
do you imagine that the standard can be the same? In particular, how
can RFC1422 be used with an application where there is no "PERSON"
involved unless an error occurs.
If you look in on the EDI discussion on byu.edu you will see that MIME
itself if reduced to a mere transport service for EDI. If PEM were
applied under MIME, even between cooperating session level servers, it
would be in violation of RFC1422. In any case, the logical point where
trust is needed should be pushed as far as possible toward the end point
where the decision to accept the risk is made. This is usually not at
the transport layer. In fact, there may be additional routing performed
after the MIME envelope is stripped from the EDI object.
Peace ..Tom