draft-ietf-pem-algorithms-01 (the current 1115bis) states the following about
extensibility to other algorithms than those presently used in PEM:
Some parts of this material are cited by other documents and it is
anticipated that some of the material herein may be changed, added,
or replaced without affecting the citing documents. Therefore,
algorithm-specific material has been placed into this separate
document. Use of other algorithms and/or modes will require case-
by-case study to determine applicability and constraints. Additional
algorithms and modes approved for use in PEM in this context will be
specified in successors to this document.
I believe that this statement is wholly sufficient to foreshadow and allow
future extension to accomodate alternative suites as they emerge. A prime
original purpose for splitting 1115 off from 1113 was to modularize algorithm
descriptions to be separate from the base message processing procedures,
thereby allowing the possibility of extending the algorithm choices in future
without reissuing the 1113 descendant.
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.
I agree that the RSA/DES suite should remain the basis for the PEM standard, at
least for the present time.
At the same time, other suites will be used and
it's necessary to document these alternates.
Now I'm confused. Given that the RSA/DES suite is, as agreed, the basis of the
PEM standard, why is it the responsibility of the PEM standard's specification
to document conflicting alternatives?
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)
I'm not familiar with PMSP; do proponents exist for use of this suite in
conjunction with PEM, and are documents available which would allow
determination of whether or not its KEA and MEA are compatible with PEM
processing requirements?
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.
Based on the experience gained with PEM prototyping, I believe that PEM RFCs
should document only those algorithm choices which are sufficiently mature and
vetted in not one, but two senses: (1) in terms of accepted cryptographic
quality of the algorithms themselves, and (2) in terms of available detailed
specification (e.g., with regard to padding, bit layout, usage mode, etc.) so
as to avoid ambiguity, interoperability problems, and potential security
vulnerabilities introduced above the bare algorithm level. At this point, I
believe that these criteria have been satisfied for the RSA/DES suite but not
for any of the other prospective suites cited in Steve's message.
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.
I'm not convinced that 1115 needs to define the concept of suites in order to
make future extensions possible; it was, after all, always intended to act as
the repository within which additional alternatives would be documented. Any
future 1115 successor would, as the present 1115 does, define the sets of
algorithms which are to be used in conjunction with one another. For now, I
believe that draft-ietf-pem-algorithms-01 as it stands is ready for advancement
along with the other PEM specifications, as discussed at the last PEM WG
meeting at the Cambridge IETF.
--jl