On 98-01-15, EKR wrote:
"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.
Eric,
Your thinking presupposes a value judgement with which I don't
agree. With non-reversible signature algorithms, the hash is not
available in transit. With the run of the mill hash algorithms, this
is no big deal. However, if a privately defined algorithm is selected
(selected by the originator and supported by all recipients) then the
presence of the messageDigest attribute can subject the algorithm to
attack by parties that do not have the hash algorithm.
I also don't see this as "going out of our way". It's just
relaxing a constraint that isn't necessary in the first place.
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.
As I stated above, if a private set of algorithms are used then
your statement is not correct. That is the case I am concerned about.
High-security applications are unlikely to use the run of the mill
algorithms for signature and/or hash. However, there is no reason that
we shouldn't be able to build them based on our existing S/MIME
products.
-Ekr
--
[Eric Rescorla Terisa Systems, Inc.]
"Put it in the top slot."
Does anybody else have any views on this?
Chris
---------------------------------------------------------------
| International Electronic Communication Analysts, Inc. |
| Christopher D. Bonatti 9010 Edgepark Road |
| Vice-president Vienna, Virginia 22182 |
| bonattic(_at_)ieca(_dot_)com Tel: 301-212-9428 Fax: 703-506-8377 |
| PGP public key available from "http://www.ieca.com/"; |
---------------------------------------------------------------