I think this is an essential point. I believe that the goal of a specification like rfc2459 should be to maximize generality and interoperability, *not* to make it as easy as possible for every application developer to claim standards compliance in their marketing materials. Making RSA signatures MUST for CAs and both RSA and DSA MUST for user-agents guarantees both general interoperability and backwards compatibility. If a given vendor does not wish to support DSA, then his software will probably work in most cases. The decision to risk interoperability failure in some circumstances is his choice, and standards bodies should not be in the business of making him feel better about that choice. The idea of being able to (proudly?) claim standards compliance is the implication that this is some guarantee of completeness/robustness/ineroperability. If we relax the standards to make everything I'm-OK-you're-OK, then standards compliance becomes more a marketing tool than a yardstick of good implementations.There's the rub. PKIX can't choose a (set of) algorithm(s) because PKIX is so broadly applicable that any choice would shut out a particular community. It looks like algorithm choice is really up to the application.
I don't accept that. There does not need to be any essential difference between an S/MIME cert and an SSL cert. If we make standards that encode the expectation that every application will need to use its own certificate, then we encourage unnecessary fragmentation of functionality and proliferation of keypairs. If an SSL certificate (what does that mean, BTW?) can be used to verify signatures on an S/MIME message, that means that an S/MIME application should be able to process it. If we say "well, if you wanted to sign S/MIME you should've made sure your integrated application had separate keypairs for each function" then we destroy the generality of the X.509 certificate design.> If PKIX decides to specify MUSTs or SHOULDs, they should be designed to > support broad interoperability. Yes, but what kind of interoperability? Does an S/MIME cert have to be interoperable with an SSL cert? Put another way, will an S/MIME application ever need to use or process an SSL or IPSec cert? I say no. If you accept that, then interoperability across all protocols becomes meaningless.
Yes, protocols -- but not individual implementers. For example, the CRFM spec (rfc2511) defines the PasswordBasedMac algorithm to be able to use any appropriate OWF and MAC algorithms, but mandates the use of SHA-1 and HMAC-SHA1 for CMP/CRMF. This means that somebody who would rather use MD5 in his CMP implementation is free to do so, but is not free to claim compliance with rfc2511.So it makes sense for the algorithm decision to be in the hands of the protocols that adopt PKIX. In fact, the "users" of PKIX are really other IETF protocols. Therefore, I suggest that PKIX have only one MUST with respect to algorithms: