Jim,
As CER is a subset of BER I cannot see how the cost of adding support
for CER can be so significant.
I must ask a different question. DER was defined in 1988 and many folks
have implementations, and the specification must continue to support DER
for backward compatibility. Given these facts, what is the value of CER
over DER that makes it worth the additional development and testing? I
understand the desire for single pass processing, but I am not convinced
that the improvement in single pass processing is worth the hastles to
support two encoding formats.
Russ
I agree with Jim and Russ :-).
The cost of developing and adding CER capability to a DER-capable
encoder should be small enough as to be negligible. The actual coding
layer is a tiny proportion of the software required to process just
X.509 certificates, and an even tinier proportion of a full CMS package.
But the cost of specifying and supporting two encoding options within
S/MIME (assigning parallel OIDs for each, etc) is quite significant,
and the result is ugly. I wouldn't have a problem with picking CER
as the only valid encoding for the outer layers, and actually think this
would be desirable if S/MIME is expected to handle multi-megabyte
attachments. (I've emailed myself 50 MB tarfiles on occasion, and
MISSI has applications for signing very large files).
It's not impossible to do two passes over the content - a once-over
scan to establish the lengths and a second pass to do the encoding. But
it is a dog when the mail-handling process is I/O-bound rather than
CPU-bound.
I'm definitely opposed to having a choice of two valid encodings.
If we can't get agreement on always using CER for parts of CMS that
both a) require a distinguished encoding and b) have unbounded size,
then we should punt and always use DER despite the performance
implications.