Jim,
I am terribly behind on my email, about 1K messages. However,
in reading your note about why the MIME-PEM document supports
communication without "exposure" of certificates I feel compelled to
reply.
It is true that 1421 allows for a sender to be identified
without sending his public key. That is an efficiency measure, and
the RFC (4.6.2.2) recommends transmission of the originator's
certificate. This hardly suggests that the RFC is attempting to
support communication without disclosure of certificates. In fact the
RFC (4.6.3.1) recommends sending a full certification path.
As for what the "common practice" may be in the PEM message
you have observed, I'd suggest that if the TIS-PEM implementation
defaults to a behavior other than that explicitly recommended in the
both RFCs, it may not be surprizing to see certificate transmission
surpressed in most messages.
Finally, I think that all the models for certificate use that
have been widely described tend to emphasize widespread access to
certificates, typically by means of some form of directory, whether
DNS or otherwise. Thus I must interpret your comment about
certificates not being widely availabe as applying to the current
state of affiars, not a long-term, target situation.
Still, this does not address the question of whether the
design of a system that facilitates communication without transmission
of certificates should be a goal of PEM. Rhys gave some examples of
why he thought that might be a goal. I'm not convinced that trying to
keep public keys secret is at all an appropriate access control model,
but the WG should decide that. A more likely rationale is an attempt
at prevent traffic analysis, but TA was explicitly reuled out as a
security service for PEM in 1421, so this motivation would represent a
definate change of direction.
Steve