"Bonatti, Chris" <bonattic(_at_)ieca(_dot_)com> writes:
One concern I have is that the presence of the clear hash
value may lead some vendors to inappropriately reuse it in their
recipient side calculations rather than independently calculate
it. Clause 5 of the CMS spec says that we're not supposed to do
this. However, criminologists will tell you that motive and
opportunity identify possible suspects in a crime. I will leave
motive to your imagination. Leaving the message digest value
available is an opportunity that I think should be denied.
There are lots of ways to go wrong in writing a CMS verifier,
many of them simpler than this. I don't see the virtue in going
out of our way to prevent this particular one constitutes much
of an improvement.
My other concern relates to the overall strength of the
protocol in terms of INFOSEC practices. It is a *bad* idea to
expose intermediate values from end system security processes on
the communications channel. Okay, so maybe there isn't an
obvious problem if we're assuming RSA algorithms, but it's still
violating a design premise for no tangible benefit. Suppose some
creative soul works out a way to exploit the hash value on
signed-only messages. Again, removing it doesn't buy you much
with reversible algorithms, but we're now supposed to be
designing for a multi-algorithm environment. I would hate to see
something like this be a barrier to acceptance of S/MIME products
for use in high-security cryptographic applications.
Since the digest can be independently computed from the
message data, it's hard to understand why removing it from the
authenticatedAttributes on the wire adds any security.
-Ekr
--
[Eric Rescorla Terisa Systems, Inc.]
"Put it in the top slot."