On 1 Jan 1998, EKR wrote:
-> [snip, requoted]
-> If you desire to have a secure environment, you can't place trust
-> in entities which don't take similar security measures. So, true,
-> high security S/MIME users won't interoperate with low security
-> S/MIME users -- in the sense that the high security users (by policy)
-> don't trust the low security users. That doesn't mean that they're
-> not both speaking S/MIME any more than the fact that the NSA won't
-> tell me classified information means we don't both speak English.
->
If the high-security users decide not to depend on unsafe X.509 CRLs in
order to decide if a cert is valid (eg, supose they would use a type of
Kerberos tickets) or if the high-security users decide to use PGP and
X.509 then they would already be non-S/MIME for all practical purposes,
even though they could be both talking MIME.
Thus, what I was calling interoperability is not a MIME-interoperability,
but a S/MIME interoperability. In other words, high-security users will in
general differ from low-security users in more predicates than just
different policies or different root-keys for each user, but in the
protocols for each user. What you mentioned is not that, but a case in
which the protocol is still S/MIME for both users (thus, compatible) but
the reference frames are incompatible with each other. This case I would
consider not a case of lack of interoperation but simply to be out of
tune. Please note that what I had in mind was a true protocol difference
which cannot be solved by any possible change (or tuning) of parameters.
-> I'd observe that S/MIME already has the capability to produce
-> noninteroperability because of different security requirements,
-> simply because different users may choose to have different
-> lists of root keys.
Generally, this would not be called noninteroperability but
misconfiguration, the difference being:
(i) misconfiguration can be solved by a suitable change of parameters
while keeping the same protocols on each side,
(ii) noninteroperability cannot be solved by any change of parameters on
each side but requires at least one side to introduce a different
protocol.
Clearly, for S/MIME (as for any standard) the goal is to guarantee
interoperability irrespective of vendor choices, whereas a compatible
configuration would depend on the user choices (and thus, irrelevant to
the standard itself).
-> S/MIME is a messaging spec. In and of itself, however, it's not a
-> specification for a complete system. I don't consider this to be a
-> weakness. It's simply out of scope.
Agreed, this is exactly my central point. Indeed, what is out of scope for
S/MIME may be crucial and part of the scope when a higher-security level
is considered for e-mail messages. But this does not invalidate S/MIME for
the bulk of Internet e-mail messages and allows self-signed certs to be
used without qualms in S/MIME -- which was my original point.
Cheers,
Ed
______________________________________________________________________
Dr.rer.nat. E. Gerck
egerck(_at_)novaware(_dot_)cps(_dot_)softex(_dot_)br
http://novaware.cps.softex.br