"Bonatti, Chris" <bonattic(_at_)ieca(_dot_)com> writes:
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.
Provided that the hash algorithm is ALSO unknown. (Or private).
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.
But it is going out of our way, since it introduces a gratuitous
incompatibility.
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.
I'm not sure what it is you're worried about here. Any hash for
which you can learn very much merely from analysis of plaintext/digest
pairs isn't much of a hash. This seems like a particularly weak
rationale considering that this hypothetical attacker has
available to him plaintext/ciphertext pairs for the cryptosystem
and the signature/digest system considered as a whole. (Incidentally,
if you DO think that this constitutes a problem, you should insist
that signedData always be encrypted, in which case this problem goes
away.)
-Ekr
--
[Eric Rescorla Terisa Systems, Inc.]
"Put it in the top slot."