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