Re: Signature forgery in RFC 5652

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 <[email protected]> On Behalf Of Damian Poddebniak
> Sent: Monday, November 5, 2018 11:12 PM
> To: [email protected]
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/smime

_______________________________________________
smime mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/smime