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

The version is structure in this manner so that an implementation that checks the version number and then does a decode will never get a decode error on a properly constructed message.

If the only changes are (migrate from PKCS#1 v1.5 to RSA-PSS) and (migrate from PKCS#1 v1.5 to PRS-OAEP), then the change should be very straightforward.

If you are not using any version 1 attribute certificates, identifying the signer with the subject public key identifier, or using a content type other than id-data, then the version for Signed-Data should not change.

I am assuming that you are not mixing RSA-OAEP with other key management algorithms.  If you are not using unprotect attributes or identifying the signer with the subject public key identifier, then the version number for Enveloped-Data should not change.

Russ



> On Nov 3, 2017, at 12:04 PM, Martin Rex <[email protected]> wrote:
> 
> 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