I don't believe we ever reached closure on Chris Bonnatti's suggestion
from January 15. To recap:
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.
I agree with Chris' proposal, but in the interest of guaranteeing
backward compatibility with S/MIME v2, here is another somewhat less
elegant suggestion:
1. AFTER the originator computes the signature value, the value
of the Message Digest attribute is deleted. The Message Digest
attribute, with the empty value, is transmitted on the wire.
This has the disadvantage of including a few unnecessary bytes on
the wire, but it ensures that S/MIME v2 implementations which expect
to receive that attribute will get it.
Date: Tue, 27 Jan 1998 12:18:32 -0500
From: Russ Housley <housley(_at_)spyrus(_dot_)com>
Dave & Eric:
I understand the security issue. The recipient must recompute the message
digest. However, vendors have been very clear that they want CMS to be
backward compatible with PKCS#7v1.5. So, in the last version of CMS, I
included text requiring the recipinet to recompute the message digest.
Russ
Since the recipient is incorrect and cryptographically vulnerable if it
does not recompute the message digest, all correct S/MIME v2 / PKCS#7
v1.5 implementations will compute the digest from the content, and will
not be adversely affected if the digest value is not included in the
transmitted messageDigest attribute. In other words, if receiving an
empty messageDigest causes an application to fail to verify signatures,
then that is an indication that the application may have the very
implementation bug we are trying to protect against.
I propose modifying CMS as follows:
1) add the following after the second paragraph of section 5.3:
"After the signature has been generated, the value of the
messageDigest authenticatedAttribute is deleted, i.e. the
transmitted value of the messageDigest attribute is always
a zero-length OCTET STRING."
2) delete the last sentence of section 5.5:
"For the signature to be valid, the message digest value calculated
by the recipient must be the same as the value of the messageDigest
attribute included in the authenticatedAttributes of the signedData
signerInfo."
Even if no changes are made in messageDigest handling in CMS, this
requirement to check the received and computed values is unnecessary.
The computed value is used in signature validation; the received value
should be ignored.
3) just for redundancy's sake, add the following after the first
paragraph of section 11.2:
"Although the complete message-digest attribute is included in the
signature generation and validation computations, the transmitted
value of this attribute is always a zero-length OCTET STRING.
Non-empty values of this attribute received from earlier versions
of this specification are accepted and must be ignored."
Eric and everyone else: are there any objections to including either
Chris' original proposal or my more-backwards-compatible version
into CMS? Which proposal is preferred? If there are no objections
can we declare consensus and incorporate the changes into the next
draft?
Regards,
Dave Kemp