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.
Tom>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.
I agree. But is it hopless to think that a common public key and certificate
infrastructure could be evolved to support even such disparate applications
as PEM (as at least most people tend to construe it) and EDI?
After all, there is only one X.500. Or is there? If it is going to be as hard
as people seem to believe to add or change attributes, we may end up
with a jillion X.500 suppliers, each one focused on only one particular
industry and core application, and implementing only those attributes necessary
to support that business.
We have met the enemy, and he is us!
Pogo