Peter,
I strongly share your (implied) concern regarding our current
direction.
Although I am sympathetic to the concerns that have been
eloquently expressed by Rhys Weatherley and Steve Crocker
regarding the need to be able to bind certificates to e-mail
names, I believe that these concerns primarily represent
start-up pains being suffered as a result of a perhaps
less-than adroit implementation of the reference model, in
particular the user interface.
Recent discussions with a very large software company
that I won't name at this time indicates that they have
on the order of 750,000 users that are already using an
older form of public key cryptography. They are preparing
their next release, currently plan to make it PEM compatible
(although they are also looking carefully at the Apple AOCE
varient), and expect that as many as 1.5 million users might
be on this system within a year. This system includes a
proprietary directory, and they are also planning to interface
that directory to X.500.
Other intergrated mail programs that seem about ready to be
born include support from the COST consortium, and from
MIT. A commercial PKC package I have heard good things
about is the forms package from Shana Corporation out of
Edmonton, Alberta. I have to believe that a number of
such packages will be developed based on the Apple AOCE
capability.
If vendors are beginning to develop such capabilities and
mass-market them, it would almost be disastrous to
suddenly change our direction. On the other hand, if these
packages are begin developed under PKCS or other standards,
rather than PEM, then we should give very careful thought
to trying to align the different approaches.
Although I can certainly feel as frustrated as anyone with
certain less-than-perfect aspects of the current RFCs,
I think that to suddently adandon our previous goals
and go chasing after another model based on a small sample
of academic users who are involved in developing their own
implementations would not be wise. That is not to say that
that we shouldn't begin developing the specifications for
PEM 2.0.
I want to carefully read the new PEM-MIME proposal, in order
to understand exactly what they are proposing regarding the
public key certificate infrastructure. It appears that they are
adjusting/removing some of the mechanisms that were
proposed to be used for certificate request and CRL services.
If that's all they are doing, that may be perfectly OK, so
long as we understand what the replacements would be.
I would suggest that if further refinements are in order for PEM,
that we should develop work items for the following:
1. A careful re-examination of the current X.509 certificate,
giving consideration to expanding it along the lines of additional
(non-distinguished) attributes, and perhaps to more carefully
deliniating the roles of naming vs. certification chaining.
2. Alignment/convergence between PEM and PKCS,
particularly in the area of the signature block itself, so that
creation and validation of signatures would be interoperable
between the two types.
3. Some consideration should probably be given to what
the ANSI X9F1 people are coming up with, in order to
better understand what we should do with authorization
certificates.
4. I don't believe that we need to change our direction, but
it might be helpful to reaffirm our committment to X.500, and
to better understand waht needs to be done to more that along.
Bob