3
$\begingroup$

I am using a vendor library that signs a text producing a PKCS#7 message. I'm not sure of the content of this message.

Does a pkcs#7 message have to contain the signed message, the certificate, the payload? Does it have to start with ----BEGIN PKCS7---- and end with ----END PKCS7----?

$\endgroup$
1
  • $\begingroup$ If you want to take a look at the message then you can paste the base 64 (anything between the BEGIN and END lines into the text area presented by this page. $\endgroup$
    – Maarten Bodewes
    Sep 29, 2015 at 22:42

2 Answers 2

5
$\begingroup$

First, PKCS#7 -- almost always considered to include its successor CMS in the same way "SSL" usually means TLS -- supports several cryptographic functions; you appear to be asking only about signing, so I will ignore the other parts. If you want more, read the RFC and/or add to your question.

PKCS#7/CMS has two options for signed data, one where the data is contained within the SignedData message, usually called embedded, and one where the data is not in the message but must be available to the recipient, usually called separate, external, or detached.

PKCS#7/CMS messages including SignedData (but not necessarily external data) are first encoded in ASN.1 BER or DER which can then be transmitted and/or stored in binary or in PEM format using the dashed BEGIN,END PKCS7|CMS lines around a base64 encoding. (CMS messages can also be used in S/MIME messages with a slightly different formatting, but those are usually called S/MIME not PKCS#7 or CMS. In particular, a "clearsigned" S/MIME message contains a detached encoded signature plus a more-readable direct encoding of the data as parts of one email message.)

A PKCS#7/CMS SignedData can carry one or more signatures, but more is rare; it can carry certificate(s) and/or CRL(s) that the signer believes the recipient(s) will or may need to verify the signature, but this is not required if the sender knows or believes the recipient(s) have or can get the certificate(s) and revocation info by other means.

In fact, PKCS#7/CMS SignedData can be used with no signatures and no data solely to carry some related certs (and possibly CRLs); this is commonly indicated as "p7b" or "p7c" format. This doesn't apply to your case, but could be confused with it.

You can determine which elements are present in a given message by parsing it; if particular, if you have or get OpenSSL openssl asn1parse will by default decode a PEM file (ignoring the type stated in the BEGIN,END lines, which can even be omitted) or with -inform der a binary DER file.

$\endgroup$
2
  • $\begingroup$ OK, a question that is open for 13 hours and we still post within 5 minutes of each other. Good for my Sportsmanship badge progress I suppose :) $\endgroup$
    – Maarten Bodewes
    Sep 29, 2015 at 22:44
  • $\begingroup$ Thanks for these clarifications. I also found this site : certlogik.com/decoder which gives another detailed vision of the content of my file. $\endgroup$
    – jBravo
    Sep 30, 2015 at 8:01
1
$\begingroup$

A PKCS#7 message is a message structured by the rules for the Cryptographic Message Syntax or CMS. CMS is/was specified by the PKCS#7 cryptographic standard, but it is now governed by an RFC. CMS is a container format which means that it may contain encrypted data, authenticated data or signed data. The structure is self descriptive and may also contain certificates.


A PKCS#7 message does not have to contain the signed message as it may be a so called detached or external signature. The CMS RFC contains the following:

The optional omission of the eContent within the EncapsulatedContentInfo field makes it possible to construct "external signatures". In the case of external signatures, the content being signed is absent from the EncapsulatedContentInfo value included in the signed-data content type. If the eContent value within EncapsulatedContentInfo is absent, then the signatureValue is calculated and the eContentType is assigned as though the eContent value was present.


CMS is specified using ASN.1, which is a data description language. It is encoded using binary encoding: BER in general and DER in case canonicalization is required. So CMS itself is binary encoded.

However, CMS is sometimes used by applications that require text instead of binary. So CMS can then be "ASCII armored" by using the PEM format: a descriptive header, some optional parameter fields and a footer. The binary CMS message is simply base 64 encoded and sandwitched between the header (+ params) and footer.

$\endgroup$
2
  • $\begingroup$ Quite a coincidence! One nitpick: PEM converts to base64 and adds -----BEGIN,END lines; SMIME can use any MIME encoding although base64 is most common, and adds MIME headers like Content-type: and Content-Encoding: with no footer as such, although if embedded in multipart the part boundary follows the body. Oh, and OpenSSL commandline defaults to PEM for most things, but SMIME for both(!) cms and smime. $\endgroup$ Sep 30, 2015 at 6:34
  • $\begingroup$ @dave_thompson_085 Hmm, I'll play around with it some more, I am getting too used to simply code it in bouncy I guess (if at all). Thanks for the nitpicks. $\endgroup$
    – Maarten Bodewes
    Sep 30, 2015 at 7:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.