ietf-smime
[Top] [All Lists]

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

2017-11-03 13:25:35
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(_at_)ietf(_dot_)org] On Behalf Of Martin Rex
Sent: Friday, November 3, 2017 9:05 AM
To: smime(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime

_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime