The PGP community represent a set of users who want to be able to
prevent the disclosure of their public key.
What I'm asking is this: You accepted the "PGP community's"
requirement to hide the public key. However, someone from the PGP
community recently said we DER is too complex and we should encode the
public key with the PGP method. But you did *not* accept *this*
requirement. Do you see what I'm asking? What criteria were used to
determine that hiding the public key is a reasonable requirement,
whereas using something simpler than DER is not reasonable?
Just saying "They wanted it" is not an answer.
Isn't it totally obvious what the difference is here? The particular encoding
is used is really nothing but an implementation detail -- it could have been
BER, DER, CER, LER, PER, PGP's scheme, the OSF's RPC scheme, or Sun's XDR, and
the resulting service characteristics would not change in any way.
The only argument in terms of services in favor of some particular encoding is
that there's some advantage in using BER and/or DER to achieve some level of
interoperability, as in using BER/DER for certs so they interoperate with
X.500. But this is not a particularly strong argument either way.
The situation is quite different when it comes to hiding the public key. A
service can either require it, allow it as an option, or not allow it at all.
MIME/PEM allows it as an option. If it wasn't offered as an option there would
be something MIME/PEM cannot do that other service offerings clearly can do.
Mind you, I'm not arguing for or against the ability to hide a public key here.
All I'm saying is that choosing an encoding is an entirely different sort of
decision than choosing the characteristics of the services you provide -- they
are not comparable, and as such any attempt to contrast the selection of one
with the other is pretty much without meaning.
Ned
P.S. It is also far that the ability to hide the public key makes things
either simpler or more difficult from an implementation standpoint.