My point exactly. Maybe we should label some of these thngs as implementation
options and get on with it. At least if my company doesn't buy one of the
implementations that contain the features that I think are harmful, some of
our
more adventuresome users won't have quite as much latitude to screw things up.
(No, I'm not an MIS administrator. I just sound like one.)
This confuses implementation with policy. Since we do not set policy, we do not
require that your site accept non-cert-based PEM services. You can choose to
accept and provide only cert-based services under the current specifications,
and that's fine.
I would have no problem with an explicit requirement that all implementations
be able to support this particualr mode of operation. This turns out to be a
null statement in practice -- they all will in any case since any useful
implementation has to let you specify what you trust and what you don't trust.
However, implementations are required to implement all the options, both
cert-based and non-cert-based. As such, you get exactly what you want out of
this. And so do I -- I want the ability to support customers who don't give a
tiny damn about certs and never will, and for that matter I can also support
customers who demand certs for all uses of PEM.
Your suggestion that all these things be made optional is actually pretty
funny, in that it would almost certainly guarantee that some implementations
would never support the services you require. Our current proposal is that
implementations be required to give you the services you want! I'm actually
opposed to dropping the requirement that all forms be supported, since I think
it will cause big interoperability problems.
Let me put this another way. I see my position as giving you exactly the
services you want in exactly the form you want them. However, I see your
position as being unwilling to let me have the services I know I need, despite
the fact that you are under absolutely no obligation to support or use them.
Ned