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

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:[email protected]] On Behalf Of Martin Rex
> Sent: Friday, November 3, 2017 9:05 AM
> To: [email protected]
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/smime

_______________________________________________
smime mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/smime