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

mrex@sap.com (Martin Rex) Fri, 03 November 2017 16:04 UTC

Return-Path: <mrex@sap.com>
X-Original-To: smime@ietfa.amsl.com
Delivered-To: smime@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2539B13FECA for <smime@ietfa.amsl.com>; Fri, 3 Nov 2017 09:04:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id WSBi7ZhrKZOm for <smime@ietfa.amsl.com>; Fri, 3 Nov 2017 09:04:53 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C76713FEB5 for <smime@ietf.org>; Fri, 3 Nov 2017 09:04:53 -0700 (PDT)
Received: from mail07.wdf.sap.corp (mail04.sap.corp []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3yT6Gq5wF5z1Hht for <smime@ietf.org>; Fri, 3 Nov 2017 17:04:51 +0100 (CET)
X-purgate-ID: 152705::1509725091-000040CA-D290D0B2/0/0
X-purgate-size: 1829
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp []) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3yT6Gq5KQ7zGpYk for <smime@ietf.org>; Fri, 3 Nov 2017 17:04:51 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id AD0DB404B; Fri, 3 Nov 2017 17:04:51 +0100 (CET)
To: smime@ietf.org
Date: Fri, 3 Nov 2017 17:04:51 +0100 (CET)
Reply-To: mrex@sap.com
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20171103160451.AD0DB404B@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <https://mailarchive.ietf.org/arch/msg/smime/dxc7X_T1AgO5EmxFKgfZgPvv5Cs>
Subject: [smime] PKCS#7 v1.5 vs. CMS / ContentInfo vs. EncapsulatedContentInfo based on version
X-BeenThere: smime@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SMIME Working Group <smime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/smime>, <mailto:smime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/smime/>
List-Post: <mailto:smime@ietf.org>
List-Help: <mailto:smime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smime>, <mailto:smime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Nov 2017 16:04:57 -0000

There is a somewhat confusing ruleset around the "SignedData" PDU
version field in the CMS specification, and insufficient guidance
about the ramifications for the Encoder/Decoder for ContentInfo
when version 1 vs. 3 is chosen.

The organization responsible for certain legally mandated data exchanges
in Germany is rev'ving their requirements, intoducing RSA-PSS signatures
on certificates plus RSA-OAEP encryption for AppData.

Previously, they've been using PKCS#7 v1.5 PDUs with RSA PKCS#1 v1.5

The confusion I'm seeing is about the choice of the SignedData "version"
field, and the resulting consequences for the (ASN.1) PDU encoder/decoder
for the ContentInfo vs. EncapsulatedContentInfo in SignedData.

For the encoder/decoder, the reasonable interpretation would be,
that whenever version=1, then the PKCS#7 ContentInfo encoding will be
used, and only for version>=3, the CMS EncapsulatedContentInfo encoding
will be encoded or decoded.

However the current reading of the CMS standard by that organization is
that they want to specify version=1 in combination with EncapsulatedContentInfo
encoding -- something that looks extremely weird to me, and would require
significant contortions in the ASN.1 encoder and decoder.

For the encoder, it will require a laying violation from within the encoder,
looking at later elements and semantics of higher level PDUs.

For the decoder, it essentially will require heuristics (trial-and-error)
decoding if the PDU version will no longer matter, and the data determining
which encoding is appropriate, has not been decoded yet at this point
requiring a retroactive verification of whether the heuristically determined
encoding was actually a _valid_ encoding.

Any comments from folks more experienced with CMS ?