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

Jim Schaad <ietf@augustcellars.com> Fri, 03 November 2017 18:25 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: smime@ietfa.amsl.com
Delivered-To: smime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACC413FF19 for <smime@ietfa.amsl.com>; Fri, 3 Nov 2017 11:25:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oknLBR3LgdiK for <smime@ietfa.amsl.com>; Fri, 3 Nov 2017 11:25:29 -0700 (PDT)
Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 539EF13FD49 for <smime@ietf.org>; Fri, 3 Nov 2017 11:25:28 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1509733526; h=from:subject:to:date:message-id; bh=rTh8cGf5OZ/GqInR0Nz4j0tj3kvqqiSz2lct+PwoMXw=; b=BS/CksscIaLKBrJ6lf4QO7BzFm6nconzuoVWMRJlQfkPl9OpJHLoliFjFWlLNwZH+uugysxStbL zVymdZaDdlWlo/34VsQ7w/xRT/gMmaoqwLSEJYvf2ykrgsLCsGocBTNeyxGpA8Sjbv345MTY4Fq7d jc+K3VbH3TILPVcDWa28mHuds6KyVV+ECbUp6Puosi4aOT5fRNDZcMEV9OWyLVj2rYWRTNBOHCIhw 3riGsLoWYhSdrQNOhB0ZqGe7cH9ESwXskQ2RYL7x+HD8jvkJo81A6gjTuER+i/7FM9X5PzV9gJk5q SF8sz76T3wslWj9B9VAdSuVSGluRoTNNhkyQ==
Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 3 Nov 2017 11:25:26 -0700
Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 3 Nov 2017 11:24:22 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: <mrex@sap.com>, <smime@ietf.org>
References: <20171103160451.AD0DB404B@ld9781.wdf.sap.corp>
In-Reply-To: <20171103160451.AD0DB404B@ld9781.wdf.sap.corp>
Date: Fri, 3 Nov 2017 11:25:20 -0700
Message-ID: <001101d354d1$1cfdced0$56f96c70$@augustcellars.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKF3Wi9cvbMmmnh/4p3vrg5y3Oj2aGd5PeQ
X-Originating-IP: [192.168.1.162]
Archived-At: <https://mailarchive.ietf.org/arch/msg/smime/l6x7nh-wNlIQlWC-bXhVxRG2fxQ>
Subject: Re: [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 18:25:31 -0000

There was never any intent that a version number of one would indicate that
this was PKCS#7 rather than CMS.

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.

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 about what you are doing.
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.  

Jim


> -----Original Message-----
> From: smime [mailto:smime-bounces@ietf.org] On Behalf Of Martin Rex
> Sent: Friday, November 3, 2017 9:05 AM
> To: smime@ietf.org
> Subject: [smime] PKCS#7 v1.5 vs. CMS / ContentInfo vs.
> EncapsulatedContentInfo based on version
> 
> 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
> transforms.
> 
> 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 ?
> 
> -Martin
> 
> _______________________________________________
> smime mailing list
> smime@ietf.org
> https://www.ietf.org/mailman/listinfo/smime