Re: [smime] PKCS#7 v1.5 vs. CMS / ContentInfo vs. EncapsulatedContentInfo based on version

Jim Schaad <> Sat, 04 November 2017 05:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B8A7813FB42 for <>; Fri, 3 Nov 2017 22:13:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dotYwQUoz5YC for <>; Fri, 3 Nov 2017 22:13:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD77913FB37 for <>; Fri, 3 Nov 2017 22:13:20 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256;; s=winery; c=simple/simple; t=1509772397; h=from:subject:to:date:message-id; bh=dov93CLIldTAnt99RnNzEUBBb0tNttxwhrUNXEcTSR8=; b=fvpQXpU4afl1xtPXv5HYD/Ahl++vKtAfgVvbXcX6InNtzgA2W+3p/Z9Tabm3VmN4iUFsPw+VdLZ 57ZGYJ736IXeWUXiHXdAJh1z2+fsNJVXQ/OLfpMPPz9xyA63Yar2xc8Q+9ZeUA3wxO3mELACNROSA PmjISVTgD57wQ9HFBHHSqwaGU7TqZDKj9omOF2KWR6PlT0hP9sOitEWf7xlSQ4DXFlyJ0THoMYpZX MnmP+beEtsocrrOUl/WOHFUGzxmkHtWZvmjTnk9LpQX2UXqZeQPWMC7euVAUOoVz8jX9dLOxaEOUd eSnzqzd3EN9kxJy2+m1M4uK33UVWo0AfTOuw==
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 3 Nov 2017 22:13:16 -0700
Received: from Hebrews ( by ( with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 3 Nov 2017 22:12:14 -0700
From: Jim Schaad <>
To: <>
CC: <>
References: <> <001101d354d1$1cfdced0$56f96c70$> <>
In-Reply-To: <>
Date: Fri, 3 Nov 2017 22:13:11 -0700
Message-ID: <002a01d3552b$9e1ea700$da5bf500$>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKF3Wi9cvbMmmnh/4p3vrg5y3Oj2QJVgjNfAdAjTyqhfW3NoA==
X-Originating-IP: []
Archived-At: <>
Subject: Re: [smime] PKCS#7 v1.5 vs. CMS / ContentInfo vs. EncapsulatedContentInfo based on version
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SMIME Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 04 Nov 2017 05:13:23 -0000

> -----Original Message-----
> From: Martin Rex []
> Sent: Friday, November 3, 2017 2:43 PM
> To: Jim Schaad <>;
> Cc:;
> Subject: Re: [smime] PKCS#7 v1.5 vs. CMS / ContentInfo vs.
> EncapsulatedContentInfo based on version
> Hi Jim,
> Thanks for the reply, but this leaves me even more confused now.
> Admittedly my personal implementors experience is tiny.  I once patched
> support for processing rfc3161 TimeStamps into an existing PKCS#7 v1.5
> implementation, and I needed a few tweaks for the ASN.1 encoder & decoder
> -- but rfc3161 uses id-ct-TSTInfo content type and version 3 rather than
> and version 1, so I needed tweaks for processing of
> Jim Schaad <>; wrote:
> >
> > To begin with, this is only a problem if you are looking at wrapping
> > contents other than id-data, for id-data there is no difference.  In
> > both cases there is an OCTET wrapper.
> This statement looks like a self-contradiction.  Either there is _no_
> between PKCS#7 v1.5 SignedData for id-data, then there is no wrapper.  Or
> there is a difference, and EncapsulatedContentInfo is used.

There is zero difference in the bytes outputted by the encoder.  

For PKCS#7 v1.5 - id-data is defined to be an OCTET STRING - thus the
emitted content is an OCTET wrapped data string
For CMS - id-data is defined to not have an ASN.1 type - instead the data is
directly wrapped by the OCTET wrapper that present in all SignedData objects

> >
> > For things which are not id-data, there is going to be a difference
> > between the two encodings in that for one an octet wrapper is there
> > and for the other case it is not.  I would say that you need to look
> > at the content type and the type of the field and then make a decision
> what you are doing.
> Do you mean that while the PDU encoding for SignedData with id-data
> ContentInfo is the same for PKCS#7 v1.5 and CMS, the actual signature (or
> more precisely the hash over that id-data) is computed _differently_ for
> PKCS#7 v1.5 and CMS (covering the 0x04 plus ASN.1 length field for CMS,
> omitting this for PKCS#7 v1.5) ?

For PKCS #7 v1.5 - the outer ASN.1 length and tag are not included in the
signature computation.  This means that the exact same set of bytes are
going to be hashed for an id-data object.

For a non-id-data object, the bytes that would be hashed ARE different.  For
PKCS #7 v1.5 the tag and length are not included in the signature
computation.  For CMS the OCTET wrapper is not included, but all of the
contents are included.  This means that for CMS the tag and length of the
data are included in the hash computation. 

Does this answer your questions?

> I wouldn't like a heuristic on decoding because it results in needlessly
> code and seems to have an ambituity for certain id-data that
> matches the beginning of an ASN.1 DER OctetString.
> But requiring a heuristic on SignedData would be magnitudes worse, because
> of significantly higher CPU cycles impact for computing and verifying two
> different hashes.
> > I will note that there is a security problem with the PKCS#7 encoding
> > where the content and length bytes are not correctly protected.  This
> > is one of the reasons that CMS added the OCTET wrapper in all cases
> > rather than just in the case of id-data.
> But "in all cases rather than just in the case of id-data" is a
contradiction to the
> above (with respect to the encoding).  Or is this comment _not_ about the
> encoding, but rather about the data which gets signed (hashed) ?
> >
> > There was never any intent that a version number of one would indicate
> > that this was PKCS#7 rather than CMS.
> That sounds wrong to me.  At least my copy of PKCS#7 v1.5
> (rfc2315) is _explicit_ that this version indicates PDU/protocol, and
> version==1 therefore implies PKCS#7 (rfc2315) syntax/encoding
> **AND** processing rules (semantics).
>    The fields of type SignedData have the following meanings:
>         o    version is the syntax version number. It shall be
>              1 for this version of the document.
> The PKCS#7 v1.5 PDU was *ALWAYS* supposed to be self-describing, and later
> revisions of it to identify different syntax as well as different
processing rules by
> using a different version in the PDU.
> For the particular (governmentally mandated) data exchange scenario in
> Germany, they're currently using PKCS#7 v1.5 with RSA PKCS#1 v1.5, and
> want to transition to using RSA-PSS (signatures on certs and PKCS#7/CMS
> SignedData) and RSA-OAEP (EvelopedData), with EndEntity certs that carry
> rsaEncryption keys (so that the keys can be used for both, signature and
> encryption).
> -Martin