In preparing to advance the PEM specs to Proposed Standard status, the
question arises how to address and document multiple suites of
algorithms. Although the RSA/DES suite is the main focus, alternate
suites are being pushed forward in various quarters. I don't think
there's any question that the RSA/DES suite should be the basis for
the PEM standard. At the same time, other suites will be used and
it's necessary to document these alternates. Let me review the suites
I see as part of the current scene, and then I'll return to question
of documenting them.
At present, the PEM-suite of algorithms is (K = key mgmt, S =
signature, H = message hash, C = certificate hash, D = message
encryption)
PEM-suite: (KS = RSA, H = MD5,MD2, C = MD2, D = DES)
We also know that other suites of algorithms are being explored. One
is driven by export considerations. The Software Publishers
Association and the U.S. government have worked out arrangements for
quick export licensing of software that uses RC4 (or RC2) with keys
limited to 40 bits and RSA used for key management with RSA keys
limited to 512 bits. This is extremely controversial because the RC4
key is so short, but there's also a lot of pressure to use it because
it will permit export of implementations of PEM that use this suite.
LEt's call this suite
Export-suite: (K = RSA/512, S = RSA, H = MD5,MD2, C = MD2, D = RC4/40)
Another suite is the one emerging from NIST. Only the Digital
Signature Algorithm (DSA) and the Secure Hash Algorithm (SHA) have
emerged so far. Let's call this the NIST-suite.
NIST-suite: (K = ???, S = DSA, HC = SHA, D = DES)
Despite the incomplete nature of this suite and the incompatibility
with the RSA-based PEM-suite, at least some parts of the U.S.
government will insist on using this suite instead of the PEM-suite.
These suite seem fairly certain to me. Additionally, one can consider
the U.S. government's Pre-MSP (PMSP) to be a version of PEM except for
the algorithms. So far as I can tell, the suite is similar to the
NIST suite except for using its own Key Exchange Algorithm and Message
Excryption Algorithm.
PMSP-suite: (K = KEA, S = DSA, HC = SHA, D = MEA)
Now, do we want these suites to be documented in the RFC series? It
seems to me we need to balance the need to have them documented with
the need to protect the standardization process. We do not want to
add our imprimatur to an inadequately vetted set of algorithms nor do
we want to encourage fragementation and incompatility.
One approach is to issue RFC1115bis with its documentation of the
PEM-suite, and have it set forth the skelton for documenting other
suites. The other suites can then be documented via Experimental or
Prototype RFCs whenever someone wants to document them, and if they're
properly vetted, they can advance through the standards process.
If this approach is acceptable to the PEM WG, I think it will also be
acceptable to the IESG and IAB. Adjustment in RFC1115bis is needed to
convey the notion of suites and anticipate the documentation of
additional suites, but I don't anticipate the need for anything else.
Comments?
Steve