> From: Michael Sweet
> ... This whole discussion should be proof enough that one
> person's "secure" solution can be seen as inadequate or unsecure by
> another.
It is also a good demonstration of the fact that arguing over whether or not
something is 'secure' is difficult at best, because the term encompasses too
many things that have little to do with one another. Discussing the
specific service features: authentication, integrity protection,
confidentiality, non-repudiation is easier and more productive.
> Let the implementers decide what options are necessary and
> appropriate, and if stronger language is requested by the IETF add it
> as a recommendation and not a requirement.
The implementors (and thier product managers) always have that option, as do
the customers. What they don't have and shouldn't is control over what it
means to be an IETF standard. Making tradeoffs between _product_ features
like whether or not the customer can leverage existing authentication
databases and whether or not you can run with an existing HTTP server add
value to products. What the IAB and IESG are (properly, IMHO) trying to do
is add value to what it means to be an IETF standard - if other
considerations outweigh that in your product, then they do...