I would like to suggest a more flexible and tolerant approach
be adopted for binding the authenticated attributes to the
content in the SignedData content type. The current procedure
requires (among other things) that if the authenticatedAttributes
are present then the MessageDigest attribute also be present.
When this occurs the unsigned hash value is present in the
attribute set, making an intermediate value available to the
recipient system and possibly in the transmission channel. I
have two concerns with this status quo.
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.
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.
What I would propose is simple. We modify the CMS spec to
allow a variation in the processing of the
authenticatedAttributes in the SignedData such that:
1. It allows originating implementations to OPTIONALLY
delete this attribute
from the attribute set AFTER the calculation of the
signature value is complete.
2. If the authenticatedAttributes are present but the
MessageDigest attribute
is absent on reception, the recipient implementation
will recreate the
attribute using it's local calculation of the hash
value. The signature
validation can then proceed normally.
3. The procedure should remain as it is now if the
attribute is present.
4. Add a note that to achieve backward compatibility with
an existing
implementation this attribute should be present.
This would allow the originating implementation to weigh how must
risk and benefit is entailed in retaining the hash value in the
attributes and decide accordingly; an ideal condition in my
view. The modified procedures should place little additional
burden on the receiving implementation since it is supposed to
repeat the hash calculation anyway according to
clause 5.
I look forward to hearing your opinions 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/"; |
---------------------------------------------------------------