Really? Why? You either have the services available or you don't. If you do
your implementation will handle whatever layering is presented or desired,
if
you don't you won't. The particular layering you happen to use is irrelevant
in this context.
The issue comes up in "optimization" that implementors end
up applying in interpretiung the standards. If they can't think
of a way that someone would use something, they tend to
eliminate it, which tends to reduce interoperability.
Exactly. And this is why the protocol specification should not talk about
preferred orders of doing things: The minute it does so people will
tend to assume that the described orders are the only orders.
I think we have clearly proven why separable signing and
encryption is obviously desirable, and why someone might
specifically want to sign after encryption. In this particular
case, I think we need to make it an explicit part of the
standard that separable signing and encryption is desirable and
that this is the reason why. If we don't, then someone who
doesn't understand this application would likely do the S/MIME
thing and allow only signing before encryption, if they allow
signing without encryption at all.
I see. In other words, you're asking for the specification to state that
implementations must support different orders.
This is a different kettle of fish. I would have no problem with such a
statement appearing in the security multiparts specification.
Thus my desire to have this issue explictly dealt with
somewhere -- we'll never completely understand every nuance of
the standards in the same fashion, unless we not only have a
standards document that describes what is desired, but also
specify how it might be used and why it might be desired to be
implemented in a particular fashion. Now, this can be done as
one document or two. If written as a pair, one of would
presumably be a standards-track document, while the other is
more of a "thoughts on implementation" informational-only
document.
Right.
I think it is very important that these details be made
explicit somewhere, although not necessarily in the same
document.
The only substantive issue that arises from the multiplicity of layering
options is whether or not a given application is using the optimal layering
of
the various service elements. And this can be addressed by an informational
document that describes various layering combinations and what they are
useful
for.
I think we might be in violent agreement here. ;-)
Agreed.
Ned