At 9:12 PM 2/24/96, Ned Freed wrote:
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 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.
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.
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.
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. ;-)
-Brad