Re: A brief comparison of email encryption protocols
Ned Freed (NED@INNOSOFT.COM)
Sun, 25 Feb 1996 08:49:02 -0800 (PST)
> > 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