If someone wants to write a document describing
the application of various security nestings and their implications,
I have no problem with that. But not in the protocol itself.
So long as the standard explicitly referenced that external
document describing why you might want to do certain things in a
certain order, I would have no problem with that. But for a
standard to talk exclusively about things like seperable signing
and encrypting without discussing (somehow) the various
interactions, would be a mistake from an
implementation/interoperability standpoint (IMHO).
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 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. And a reference to such a document would be a fine thing to have in, say,
the security multiparts specification. But I doubt very much that we could get
closure on such a thing as part of a standards-track specification, because
there are just too many interesting applications and anything seen as limiting
layering is sure to make some group or other upset.
Ned