P7M File Documentation

Summary

A file with the .p7m extension is a PKCS#7 / CMS message: a cryptographic container that wraps an original document together with a digital signature, or with encryption, or both. The real file (often a PDF or an XML e-invoice) sits inside, so the .p7m must be unwrapped, not just renamed. It is the standard for legally valid e-signatures in Italy and the EU. Its MIME type is application/pkcs7-mime and the binary form is DER-encoded ASN.1 starting with 30 82.

Technical details

FeatureValue
Full namePKCS#7 / S/MIME Message (digitally signed or encrypted)
File extension.p7m
MIME typeapplication/pkcs7-mime
Format typeBinary PKCS#7/CMS container (DER-encoded ASN.1); sometimes Base64 text
DeveloperRSA Security (PKCS#7); IETF (S/MIME, CMS)
IntroducedPKCS#7 in the 1990s; CMS standardised in RFC 5652
Standard / specRFC 5652 (Cryptographic Message Syntax); PKCS#7 v1.5 (RFC 2315)
Open standardYes
EncodingASN.1, normally DER (binary); Base64-armored variant is text
Byte orderN/A — ASN.1 TLV, big-endian length fields
Magic number30 82 (ASN.1 SEQUENCE tag + 2-byte length); Base64 form starts MII
SignedData OID1.2.840.113549.1.7.2
EnvelopedData OID1.2.840.113549.1.7.3
Inner contentThe original file (PDF, XML, etc.), often with its name preserved
CategorySecurity / Certificate Files
Related extensions.p7s, .p7c, .p7b, .pem, .cer, .smime
Specification URLhttps://www.rfc-editor.org/rfc/rfc5652
File signature (magic bytes)
30 82 xx xx

Offset 0. A DER-encoded .p7m begins with the ASN.1 SEQUENCE tag 0x30, followed by a long-form length: 0x82 means “the next 2 bytes give the length”, so a typical file opens 30 82 LL LL. That outer SEQUENCE is a CMS ContentInfo, whose first element is an OID naming the content type (1.2.840.113549.1.7.2 for signed-data, .7.3 for enveloped-data). A Base64-armored .p7m is text instead and begins with the ASCII string MII (the Base64 of 30 82).

What is a .p7m file?

A .p7m file is a message in the PKCS#7 / Cryptographic Message Syntax (CMS) format: a cryptographic envelope that wraps an original document together with a digital signature, or with encryption, or both. PKCS#7 was defined by RSA Security in the 1990s and later standardised by the IETF as CMS in RFC 5652. The same syntax underpins S/MIME secure email and, most visibly for end users, the legally binding electronic signatures used in Italy and across the EU under the CAdES standard.

The crucial point is that the real file lives inside the .p7m. A signed invoice usually arrives named invoice.pdf.p7m: the .pdf is the inner document and the .p7m is the cryptographic wrapper around it. You cannot read the document by renaming the file to .pdf or opening it in a text editor; it has to be verified and extracted by software that understands the syntax. Despite the site’s “encrypted message” label, in practice most .p7m files people receive are signed, not encrypted: the wrapper proves who signed the document and that it has not changed, and the content inside is fully readable once unwrapped.

ASN.1 and DER: how the bytes are laid out

A .p7m is not free-form binary. It is an ASN.1 structure, almost always serialised with the Distinguished Encoding Rules (DER), which encode every value as a Tag–Length–Value (TLV) triple. That is why a DER .p7m begins with the byte 0x30: that tag is UNIVERSAL, constructed, type SEQUENCE. The next byte is a length. Because CMS structures are larger than 127 bytes, the length uses the long form: 0x82 announces “two length bytes follow”, so a real file opens with 30 82 LL LL.

30 82 0A 3F        SEQUENCE, length 0x0A3F (2623) bytes   -- ContentInfo
   06 09 2A 86 48 86 F7 0D 01 07 02   OID 1.2.840.113549.1.7.2  -- signedData
   A0 82 0A 30 ...  [0] EXPLICIT  -- the SignedData content follows

Some senders Base64-armor the file so it can travel as text. In that case the bytes 30 82 are Base64-encoded and the file starts with the ASCII characters MII. Tools detect the two forms by their first bytes and read either -inform DER or -inform PEM accordingly.

ContentInfo: the outer wrapper and its content type

Every CMS message is a ContentInfo, a SEQUENCE of two fields: a contentType OID that names what kind of message this is, and a [0]-tagged content holding the body. The object identifier is the single most important field in the file, because it tells a parser whether it is looking at a signature, an encryption envelope, or plain data. The values under the PKCS#7 arc 1.2.840.113549.1.7 are:

Content typeOIDMeaning
data...1.7.1Raw content with no protection
signedData...1.7.2The document plus one or more signatures (the common .p7m case)
envelopedData...1.7.3The document encrypted for one or more recipients
signedAndEnvelopedData...1.7.4Both, in one structure
digestedData...1.7.5Content plus a hash
encryptedData...1.7.6Symmetrically encrypted, key managed out of band

The signedData structure, field by field

When the content type is signedData, the body is a SEQUENCE (RFC 5652 §5.1) with these fields in order:

SignedData ::= SEQUENCE {
    version           CMSVersion,          -- 1 or 3 depending on features used
    digestAlgorithms  SET OF AlgorithmIdentifier,   -- e.g. SHA-256
    encapContentInfo  EncapsulatedContentInfo,      -- the actual document
    certificates  [0] IMPLICIT CertificateSet OPTIONAL,  -- signer chain
    crls          [1] IMPLICIT RevocationInfoChoices OPTIONAL,
    signerInfos       SET OF SignerInfo }

encapContentInfo is where the wrapped file lives: for an attached (“opaque”) signature its eContent field carries the original document bytes verbatim, which is why extracting the PDF is a matter of pulling out this octet string. The certificates field carries the signer’s X.509 certificate and usually the chain up to a trusted CA, so a verifier can establish who signed. Each SignerInfo holds the digest algorithm, optional signed attributes (including the message digest and signing time), the signature algorithm, and the signature value itself. Verification recomputes the digest over eContent, checks it against the signed attributes, then verifies the signature with the certificate’s public key.

A close relative, the detached signature, uses the extension .p7s instead: there the eContent is absent and the signature sits alongside a separate, unwrapped file. A .p7m normally embeds the document; a .p7s normally does not. The same tools handle both.

The envelopedData structure and hybrid encryption

When the content type is envelopedData, the .p7m is encrypted rather than signed, and it uses hybrid encryption: a fresh symmetric content-encryption key protects the document, and that key is itself encrypted once per recipient.

EnvelopedData ::= SEQUENCE {
    version              CMSVersion,
    originatorInfo   [0] IMPLICIT OriginatorInfo OPTIONAL,
    recipientInfos       SET OF RecipientInfo,     -- one per recipient
    encryptedContentInfo EncryptedContentInfo,     -- the ciphertext + algo
    unprotectedAttrs [1] IMPLICIT ... OPTIONAL }

Each RecipientInfo holds the content-encryption key wrapped with that recipient’s public key (RSA key transport, or a Diffie-Hellman key agreement). encryptedContentInfo names the bulk cipher (for example AES-CBC) and carries the ciphertext. To open such a file, a recipient uses their private key to unwrap the symmetric key from their RecipientInfo entry, then decrypts encryptedContent. This is why an encrypted .p7m can only be read by the intended holder of the matching private key, and why there is no way to “open” it without that key.

Verification and extraction with OpenSSL

Because the format is standardised, general-purpose tooling can read it. OpenSSL exposes both the legacy smime and the modern cms commands. To pull the inner document out of a signed .p7m, the verify operation writes the recovered eContent:

openssl cms -verify -in file.p7m -inform DER -noverify -out document.pdf

The -noverify flag extracts the payload without checking trust, which is useful when you only want the document; adding -CAfile chain.pem makes OpenSSL actually validate the signer’s certificate chain. In Italy and the EU the usual desktop tools are the free DiKe (InfoCert) and Aruba Sign, which perform the same verify-and-extract while also displaying the signer identity and signature validity in a GUI.

FAQ

Why is my file named something.pdf.p7m? Because the .pdf is the original document and the .p7m is the CMS wrapper around it. The PDF bytes sit in the eContent field of the signed-data structure; verify or extract the .p7m to recover them. Renaming to .pdf fails because the file is still an ASN.1 envelope, not a PDF.

Is a .p7m signed or encrypted? Read the content-type OID in the outer ContentInfo: 1.2.840.113549.1.7.2 is signed-data (readable once extracted), 1.2.840.113549.1.7.3 is enveloped-data (needs your private key). Most .p7m files in circulation are signed. A signature tool or OpenSSL reports which one it is.

What is the difference between .p7m and .p7s? Both are PKCS#7 signatures. A .p7m embeds the document inside the structure (attached signature); a .p7s is a detached signature that accompanies a separate file. The cryptography is the same; only whether eContent is present differs.

References