dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil (David P. Kemp) writes:
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.
This doesn't guarantee backwards compatibility.
PKCS-7 implies (nay, requires the following algorithm)
Extract the attributes encoding into a structure
Recompute the message digest.
Compare the computed message digest to the digest attribute.
Reencode the attributes.
Check the signature.
This is a safe procedure, but it will be broken by your change.
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.
But the computed value isn't used DIRECTLY in the signature computation.
It's used as a field in an ASN.1 structure which is itself
signed. That's what protects the rest of the authenticated
attributes. To check YOUR version, you have to do:
Imagine the following algorithm:
Extract the attributes encoding into a structure
Recompute the message digest.
*** Insert the computed message digest into the attributes structure
Reencode the attributes.
Check the signature.
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?
Yes. I object to both of these. This is of negligible security
value, and it creates a needless incompatibility.
Which proposal is preferred?
They're both equally objectionable.
If there are no objections
can we declare consensus and incorporate the changes into the next
draft?
There are objections.
-Ekr
--
[Eric Rescorla Terisa Systems, Inc.]
"Put it in the top slot."