Let me also suggest a possible compromise that might make your insistance on
having non-cert forms a little easier for me to take. At present, my
understanding is that all of the features included in an RFC are mandatory, so
that implementors who claim RFC-compliance cannot pick and choose what
portions
they would like to implement. Normally, that makes a great deal of sense, so
that there isn't an explosion of different subsets that would make
interoperability very difficult.
This is normally the case.
In this case, however, by insisting that the non-cert forms are mandatory, you
have put other implementors or potential implementors in the very awkward
position of having to do something that they are quite opposed to, or else not
building to that spec at all. In this case this seems unreasonable, in
particular if the user is not required to use those capabilities in any case.
Bob, this and a couple of previous messages make me think that you simply do
not understand at all what we're trying to do here.
There is no, repeat NO, requirement that you have to use or support any
non-cert-based forms. The only, repeat ONLY, requirement is that *implementors*
cannot produce something that they call a conforming MIME/PEM implementation
that is incapable of dealing with all of the various forms. You are free to
require whatever forms you want for your particular application. This has
ALWAYS been the case. In fact under classic PEM there were non-cert-based forms
that you could have selected (i.e. symmetric cryptography) had you wanted to.
Now, you might argue that someone might produce an implementation that doesn't
let you "turn off" the non-cert forms. I would say, however, that such an
implementation would be unworkable, since you have to be able to tell an
implementation about your local policies are as to what you trust and what you
do not trust. However, I have no problem with "requiring" that such an option
be included, since I think that in practice every implementation will have it
no matter what the specifications say.
This actually protects you a heck of a lot more than it does me. If such a
requirement were dropped you'd be sure to find implementations that don't
support any of the cert stuff. The current specs require that everyone
implement certs so that they will be there for you to use, to the exclusion of
everything else, should you so desire.
My question, therefore, is whether you would consider labelling those features
which are presently at issue as implementor-optional?
I don't want to do this because of the potential for interoperability problems.
The only acceptable interoperability problems are ones of incompatible policies
(e.g. we use CAs with incompatible policies, I refuse to use certs and you
insist on them, or I use PKCS#7 and you use PGP, etc. etc).
Ned