File name "extensions" are immaterial. There is no real standard for these few letters, only loosely maintained traditions. The PKCS#7 standard (now called CMS) describes how to encode and decode signed and/or encrypted and/or authenticated "messages" into sequences of bytes. How these sequences of bytes are stored or exchanged is completely out of scope; in particular, CMS has no concept of "file", let alone "file name".
These name extensions matter only for user interaction; namely, what happens when you double-click on the file. Operating systems derived from MS-Dos (e.g. Windows) will try to infer a reasonable behaviour by looking at the end of the file name; but that's the end of it. In any case, a CMS object has the following overall structure:
ContentInfo ::= SEQUENCE {
contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType }
ContentType ::= OBJECT IDENTIFIER
which means that the file contents begin with an explicit header which unambiguously identifies the type of data (e.g. 1.2.840.113549.1.7.2
, which means "signed data, following the SignedData
syntax from CMS section 5.1).
Since the contents are unambiguous, all you need to do is use as file name whatever triggers the right interface behaviour for what you want to use the CMS file for. There are several usages. For instance, since a CMS SignedData
has a field for embedding certificates, it has often been (ab)used as a kind of archive format for certificates "with a chain" (but without a private key). I have seen the file extension ".p7b" used for this role.