2

I just had a discussion about integrity of S/MIME and PGP. I wonder if the different parts (eg attachments and body) are signed/hashed/fingerprinted separately or is this only applied to the resulting container? I checkd some RFC and websites and it looks like the hash/signature is only for the whole message, right?

For example: If one of several attachments is extracted from a smime.p7m file, is this particular file checked for integrity (eg hashcode) or does the signature and hashes only cover the complete message?

And is this different for S/MIME and PGP?

Finally, is there a good resource (except the long to read RFCs) which is showing this?

Thanks!

Volker
  • 428
  • 4
  • 15
  • In emails, which you are obviously speaking of, usually the message body (as a hole) is signed, not each attachment. Although technically possible, I've never come across another variant yet. However, it is of course possible to sign any files before they are attached to the message, but that is probably not what you were asking. – not2savvy Nov 29 '18 at 16:38
  • Yes, I'm talking about emails. Just to be sure, the standards do not foresee some individual signature or hash for each single part of the content? You are right, some manual singing before composing the message is not what I'm asking for. Is there any source I can prove that individual attachments or parts are not signed/hashed individually? And how about PGP? – Volker Nov 30 '18 at 07:52
  • There is [RFC 5751 for S/MIME 3.2](https://tools.ietf.org/html/rfc5751) and [RFC 4880 for the OpenPGP message format](https://tools.ietf.org/html/rfc4880), but these are RFCs which you did not want to read - which I can understand, they are a pain. RFC 5751 speaks of MIME entities that are signed and/or encrypted, so as I understand this, in theory, parts of a message may be signed separately, but I've never seen such an implementation. Maybe that's simply because it does not make much sense. What's the requirements you have in mind? – not2savvy Nov 30 '18 at 14:48
  • Thanks @not2savvy, this is what I did not find in the RFCs. Really hard to read. Your answer is already helping me. The point is that I implemented a similar container file which is finally hashed and signed. One customer mentioned as issue that the files inside are not hashed individually. From my point of view, this does not make sense speaking for integrity. It would only prevent you from bugs in your en/decryption or compression functions. But this is a QA job (automated in/out tests). I needed to find similar handling in well known standards like S/MIME or PGP. Also to prove my point. – Volker Nov 30 '18 at 15:02
  • If you sign the container, there's no need to sign individually. You're right, that wouldn't make sense to do. I'm pretty sure that's generally why S/MIME and PGP/MIME clients tend to sign the entire message rather than individual parts. For inline-PGP, they sign just the message text because they can't sign the entire message or it'd break MIME. – jstedfast Dec 03 '18 at 20:30

1 Answers1

2

The S/MIME and PGP (PGP/MIME as well as inline-PGP) specifications do not enforce what MIME parts you sign or don't sign or if you sign the top-level MIME part or individual parts.

That is all left up to the mail client to decide.

In general from what I've seen in the wild, S/MIME-capable mail clients tend to sign the top-level MIME part which means that all of the attachments along with the message body are all signed together.

PGP/MIME is very much used the same way.

For clients that use inline-PGP, they sign things individually and usually only the message body text itself and none of the attachments (although there are a few that do that as well - I think The Bat! comes to mind?)

jstedfast
  • 35,744
  • 5
  • 97
  • 110