I would not say that this is a forgery of a message that the user did not
sign. What was signed was exactly the signedAttrs value, the eContent is
only indirectly included and is part of the processing of the message.
Yes what you noticed is real. I have always pushed that one should always
have the attributes so that more information about what is going on in the
process.
Not something that I personally would worry about, but there might be some
interesting attack that could be done.
Jim
-----Original Message-----
From: smime <smime-bounces(_at_)ietf(_dot_)org> On Behalf Of Damian Poddebniak
Sent: Monday, November 5, 2018 11:12 PM
To: smime(_at_)ietf(_dot_)org
Subject: [smime] Signature forgery in RFC 5652
Hello,
I have noticed something interesting about signing in the CMS
specification
and don't really know what to do with it.
The RFC says that if SignerInfo::signedAttrs are present, the signature
covers
the signedAttrs (with the message digest being in them). If there are no
signedAttrs, the signature covers the message directly.
Said that, it is possible to just cut and paste the
SignerInfo::signedAttrs to
become the new EncapsulatedContentInfo::eContent without breaking the
signature.
1) cut the signedAttrs (possible, because they are optional)
2) remove the eContent value
3) paste the signedAttrs into eContent
Given that the signedAttrs are DER-encoded, they obviously didn't look
good
when interpreted as an ASCII message
However, as the signature is still correct, this is basically a forgery of
a
message the sender didn't signed.
What do you think? I could also provide an example if needed.
Nice regards,
Damian Poddebniak
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime