Ned> Specifically, I have now been informed that the "new" proposal will not
eliminate the ability to do things without certs. As long as certs are not
required I'm happy. I doubt that you are as happy as I am about this, however.
Obviously I welcome any opportunity for you to rethink your position, And
equally obviously my attempts to put words in your mouth to explain your
previous position may become "non-operative" if that position was based on a
misunderstanding somewhere.
The misunderstanding was that the "new" proposal would remove the other
forms of identifiers. Apparently there was never any intention of doing that
--
other people find the cert requirements every bit as onerous as I do.
It sounds like we're putting in lots of options so we can pick and choose
which we utilize in our applications, but Jim Galvin says:
Jeff> > The question is, what does it mean to be compliant with
MIME/PEM? Do you get to pick and choose like this, and if so,
what will it mean if a vendor touts MIME/PEM compatibility if
they only implement what they feel like? They won't
interoperate with someone else who has picked and chosen a
different part.
Jim> You don't get to pick and choose anything. As in typical with IETF
standards, unless otherwise explicitly stated you implement everything
in the specification.
Even though you (Ned) have as much trouble with X.509 certs and
distinguished names as you have recently explained, you have to
implement them anyway. (I assume that's why we're still discussing
things: everyone doesn't want to implement everything that someone
else thought would be neat to see in the standard, so we're trying to
settle it down.) How are you planning to implement distinguished
names and X.509, although you don't want to, given that you must
"implement everything in the specification"?
- Jeff