Support of PKCS#7 ? Chapter 5.2.1 RFC5652

[pcece]

Hi,

First, many thanks for your valuable code and work.

I'm trying to create some CMS structure where the SignedData is made of EnvelopedData, and it seems that I'm facing a compatibility issue with PKCS#7.

I get the following error :

pyasn1.error.PyAsn1Error: <TagSet object, tags 0:32:16-128:32:0> not in asn1Spec
: <TagMap object, present {<TagSet object, tags 0:0:4-128:32:0>: <OctetString sc
hema object, tagSet <TagSet object, tags 0:0:4-128:32:0>, encoding iso-8859-1>}>

And according to trace, I understand that we are assuming an OctetString in eContent (as defined by CMS RFC5652)

candidate ASN.1 spec is a map of:  <TagSet object, tags 0:0:4-128:32:0> -> OctetString
new candidate ASN.1 spec is <none>, chosen by <TagSet object, tags 128:32:0>codec <none> chosen by ASN.1 spec, decoding as explicit tagcodec ExplicitTagDecoder chosen, decoding valuedecoder called at scope SignedData.EncapsulatedContentInfo.? with state 0, working with up to 1035 octets of substrate: 
00000: 30 82 04 07 02 01 00 31 82 02 9F 30 82 02 9B 02 
00016: 01 00 30 54 30 3C 31 0B 30 09 06 03 55 04 06 13 

But if I have correctly understood the RFC, since the contentType is 1.2.840.113549.1.7.3 envelopedData (PKCS #7), the DER sequence is valid.
And according to the chapter 5.2.1 of the RFC5652, the parser may try OctetString and then try to decode with an ANY syntax.

Many thanks in advance for your answer.

Best regards.

[russhousley]

https://github.com/etingof/pyasn1-modules/blob/master/tests/test_rfc4357.py

There is an example in this test that uses EnvelopedData. Hope that helps.

[pcece]

Hi @russhousley ,

Many thanks for your answer. I think i need to clarify my first comment.
When I talked about the ContentType, it was not the first ContentType of the Cms structure, but the the ContentType of the SignedData. So in this case the first ContentType is signedData.

For instance, regarding your link, it would be your first example with ContentType = EnvelopedData rather than PlainData.

Kind regards.

[russhousley]

In practice, you are unlikely to run into a situation where the content is something other than an OCTET STRING. With PKCS#7, most of the contents were associated with the id_data, which has a content of OCTET STRING. Also, if the decode with OCTET STRING does not work, the you need to look at the content type to determine the type to use. ANY is really a kind of placeholder.

[pcece]

Hi @russhousley ,

Not so unlikely, if you want to work with X9-TR34 solutions. I agree with your comment, but the aim of my ticket is to stress that the module is only supporting an OCTET STRING decoding as far as I have understood. So it will be nice to have also this ELSE with the ANY.

Kind regards.

[russhousley]

Have you tried using the rfc2315 module instead of the rfc5652 module? The rfc2315 module has the ANY in the definition of the SignedData.