It appears that the concensus is to build from the bottom up
where the "bottom" is a syntax that allows for encrypting
and signing messages. I am unhappy with this but am willing
to see movement. Even DOS users eventually move onto
better systems, even if it is Windows. ( :-) )
I believe that the intent of PEM is to supply
security services to messaging. It started with the question
of what services could and should be applied to messaging.
The authors recognized from the beginning that anyone can
encrypt and digitally sign the body of a message and apply
the appropriate syntactic handles to make it easy to code.
I make a strong distinction between security services and
security techniques. I often hear services mentioned
where only techniques are actually being discussed.
The most frequent case is non-repudiation.
I am afraid that most folks, certainly most casual users,
do and will confuse the digital signature technique with the service
of non-repudiation. This is also a danger when considering
encryption as a technique to supply confidentiality. The techniques
may be necessary within the context, but may not be sufficient
to supply the service.
I note that in classic PEM (PEM classic ?) as opposed to
PGP (PEM-lite ?), data-origin authentication and non-repudiation
are supported by the presence of a certificate infrastructure. This was
not proposed and adopted because of any hidden agenda but because
it provided necessary elements in support of the _services_ the authors
wished to provide. I cannot find a substitute mechanism or architecture
for PGP. Using PGP is so similar to the old technique of encrypting files
using shared DES keys, uuencoding the output, and mailing the result to
the recipient that I cannot seriously consider it a significant architectural
or technical accomplishment. The fact that it is wrapped neatly doesn't
make it more attractive because it doesn't supply the services I believe
are needed; it only exposes the techniques.
Please be sure to inform your customers who use self-signed certificates
and other substitutes for the PEM certificate hierarchy that they are not
enjoying non-repudiation or data-origin authentication.
JL