On Mon, 19 Feb 1996, Stephen Kent wrote:
Raph,
I agree with your characterization of the sort of "automated"
public key acquisition (local cache building) feature that is important to
make secure email systems workable. ...
[description of BBN's MSP demo elided]
However, I must point out that these features are not one of the
secure email protocol, but rather of an implementation. I don't think that
any of the protocols being discussed here specify the sort of user
interface features we are discussing. It is reasonable to evaluate secure
email protocols on two levels: what the protocol provides and what are the
features and limitations of extant implementations. It is useful, though,
not to confuse these two aspects since better implementations may be
waiting in the wings, whereas protocol design deficiencies require more
substantial efforts to fix and then to deploy the fixed version.
To some extent you are right. There certainly is a distinction between
protocol and implementation. However, some aspects of the "how to get a
public key you trust" problem require cooperation between more than one
person, and thus fall within the scope of a standardization effort.
I will try to illustrate my argument with the example of Netscape
Navigator 2.0's untrusted cert mechanism. As I've posted before, whenever
Netscape receives a cert it hasn't seen before, it pops up a dialog asking
whether to accept it. This dialog is quite similar to the one you
described for the MSP demo, but with one significant addition: the MD5
hash of the certificate.
The existence of this hash allows me to determine the validity of the
certificate through alternate channels, for example calling the issuer of
the certificate on the phone. By verifying 32 hex digits, it is possible
to verify with cryptographic assurance that the certificate has not been
tampered with. One would also expect that certificate issuers would make
the hashes known through public channels such as magazine ads. This type
of mechanism would make man-in-the-middle attacks quite a bit more
difficult and also easily detectable.
Is this hash a standard or an implementation detail of Netscape
Navigator 2.0? I submit that it is clearly a standard. For one, there are
several different ways of computing an MD5 hash over a certificate (do
you do it over the binary DER encoding or a base64 encoding?). If the
client and the certificate issuer do not agree on this method, then the
hash verification will fail.
Equally as clearly, it is a de facto standard. Nonetheless, given the
popularity of Netscape, I would expect it to catch on and be accepted as
a real standard. Perhaps the X.509 v4 spec will include it, which would
consititue de jure acceptance of the original de facto standard.
That said, I'd like to emphasize a point made by the S/MIME FAQ. It says
that "MOSS can be thought of as a framework rather than a specification,"
because it fails to specify certain details such as the cryptographic
algorithms. I see this tendency as one of the most common failings of the
email encryption standards. I understand the desire to make a
specification modular, and to include a certain degree of abstraction. In
many cases the designers go further and specifiy only a part of the entire
bits-on-the-wire protocol, presumably hoping that the fairy godmother will
come along and standardize the rest. It's happened before too many times,
and has the potential to bring down an encrypted email standard. If we're
lucky, any remaining unspecifed bits will get filled in by the de facto
standard implementation. However, given the problems with implementations
so far, I don't think it would be wise to count on it.
Thus, I believe that the RISK of underestimating the domain of
"implementation details" that need to be standardized remains a real one.
Raph