...
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.
PEM mandates X.509 certificates, the use of a single, trusted root (the IPRA), and provides an ad-hoc method for transmission of certificates and CRLS in the absence of X.500 servers. Bootstrapping trust in the IPRA's certificate is the only step that requires out of band verification. PEM is quite clear about what constitutes a trusted certificate. This was apparently too much standardization for many who wanted a more flexible trust mechanism. The delay in getting the IPRA up and running did not help. MIME supports the PEM certification hierarchy, as well as other trust models, including the use of certificate-free, bare public keys with trust a direct burden on the user. Much of what is mandatory in PEM is optional in MOSS. Use will dictate the method of trust used. ...
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.
This was discussed before. You're emphasizing an erroneous point. The following is a more complete excerpt from ftp.rsa.com:/pub/S-MIME/smimeqa.txt which I just downloaded: MOSS is designed to overcome the limitations of PEM by handling MIME messages and being more liberal in the hierarchy requirements. But MOSS has so many implementation options that it is possible for two independent developers to come up with two MOSS mailers that will actually not "talk" to each other. MOSS can be thought of as a framework rather than a specification, and considerable work in implementation profiling has yet to be done. The overriding goal of S/MIME is interoperability, with a focus on e-mail. The concensus on this list, at least, is that the above is incorrect. MOSS is a specification and two independent developers who follow the specification will have interoperability. MOSS does make use of a framework, RFC1847: Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted, which S/MIME ignores. MOSS itself, which uses RFC1847, is described in RFC1848. Even if the authors of S/MIME felt that their solution was superior to MOSS, they could have used RFC1847 and made integration much easier. If RFC1847 is used as a common security framework, then mail user agents need not understand anything but RFC1847 -- layered security services like MOSS, S/MIME, and even PGP can be handled by "helper" applications.
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.
The bigger problem is that there are more folks interested in academic discussions than there are interested in implementing something that works. Until software is out there and people are using it, everything we say is so much conjecture. 56-bit DES not enough for privacy? There is no privacy now. MOSS is modular and it will evolve with newer, stronger algorithms. Any MOSS implementation that supports DES could support tripple-DES with minimal (trivial, even) changes and the protocol supports such additions. PEM had its share of problems and its lack of success in the market has undoubtedly made many think twice about implementing MOSS. A shame, since implementing MOSS is not difficult for someone who has implemented PEM.
It's happened before too many times, and has the potential to bring down an encrypted email standard.
The standard has not been brought up (no one willing to implement), so there's nothing to bring down. Sad, really.
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.
No, the risk is that we will spend all our time worrying about the future when we have a good, modular protocol in our hands. I believe that MOSS is the better protocol, but no one appears to be willing to do aything substantial with it. RSA has the market presence to push S/MIME and that may be what's needed to get secure email out on people's desks. Mark
bin76nQj8z8B8.bin
Description: application/moss-signature