Russ Housley <housley(_at_)spyrus(_dot_)com> writes:
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.
It's important to remember here that we already have one pass
processing for the common case: Data. [1] What Section 5.3
actually means (for the Data case) is 'digest the input data'.
Moreover, signing a CER encoding is problematic because
it breaks the (IMHO important) layering between the data
to which the cryptographic services are being applied
(I.e. the message) and the message wrapper. This is particularly
important for Data, where the data being transferred may
well not be (and in the case of S/MIME, isn't) BER encoded
at all. This strikes me as a very bad idea.
-Ekr
[1] In fact, as I understand the S/MIME spec, section 2.4.1 requires
that this is the only case when you're doing S/MIME.
--
[Eric Rescorla Terisa Systems, Inc.]
"Put it in the top slot."