CMSCompressing and CMSSigning not RFC conform?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

CMSCompressing and CMSSigning not RFC conform?

Pat0675
Hi,

I recognized, that in case of signing or compressing the encapsulated content in the resulting CMS file is not encoded like specified in the RFCs. 
RFC 5652 for CMS and signing and also the RFC 3274 for compression, defining, that the EncapsulatedContentInfo including the content must be DER encoded. 

If I look into the result file I see a constructed BER encoding for the encapsulated Data.
Like this:

39:d=4  hl=2 l=   9 prim: OBJECT            :pkcs7-data
   50:d=4  hl=2 l=inf  cons: cont [ 0 ]        
   52:d=5  hl=2 l=inf  cons: OCTET STRING      
   54:d=6  hl=4 l=10000 prim: OCTET STRING      [HEX DUMP]:789CECC..........

Is this a bug or am I wrong?

Regards
Pat
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CMSCompressing and CMSSigning not RFC conform?

David Hook-3

Section 2, RFC 5652:

"Signed attributes and authenticated attributes are the only data types
used in the CMS that require DER encoding."

It would be almost impossible to handle large (and I mean large)
documents without using BER encoding.

Regards,

David

On 31/03/17 23:06, Patrick Schlosser wrote:

> Hi,
>
> I recognized, that in case of signing or compressing the encapsulated
> content in the resulting CMS file is not encoded like specified in the
> RFCs.
> RFC 5652 for CMS and signing and also the RFC 3274 for compression,
> defining, that the EncapsulatedContentInfo including the content must
> be DER encoded.
>
> If I look into the result file I see a constructed BER encoding for
> the encapsulated Data.
> Like this:
>
> 39:d=4  hl=2 l=   9 prim: OBJECT            :pkcs7-data
>    50:d=4  hl=2 l=inf  cons: cont [ 0 ]        
>    52:d=5  hl=2 l=inf  cons: OCTET STRING      
>    54:d=6  hl=4 l=10000 prim: OCTET STRING      [HEX
> DUMP]:789CECC..........
>
> Is this a bug or am I wrong?
>
> Regards
> Pat



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CMSCompressing and CMSSigning not RFC conform?

Pat0675
Hi David,

thanks for your response.
Yes, that is exactly my problem. I got a third party software component which expects (like documented in the RFC) a DER encoded file.
So, I can encode it within a few lines of code to DER, but this happens completely in memory, because the whole ASN1 stuff must be read before the lenght attributes can be calculated. And with files of size up to 3 GB I got massive Problems to do this.

How do others handle this? Is there any memory friendly method to things like this?

Regards
Patrick
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CMSCompressing and CMSSigning not RFC conform?

David Hook-3

I think you mis-interpreted my response. The data is meant to BER
encoded. The way people deal with giant files is to encode them properly
using BER and then stream them in some fashion, as the RFCs describe.

Regards,

David

On 03/04/17 17:01, Pat0675 wrote:

> Hi David,
>
> thanks for your response.
> Yes, that is exactly my problem. I got a third party software component
> which expects (like documented in the RFC) a DER encoded file.
> So, I can encode it within a few lines of code to DER, but this happens
> completely in memory, because the whole ASN1 stuff must be read before the
> lenght attributes can be calculated. And with files of size up to 3 GB I got
> massive Problems to do this.
>
> How do others handle this? Is there any memory friendly method to things
> like this?
>
> Regards
> Patrick
>
>
>
> --
> View this message in context: http://bouncy-castle.1462172.n4.nabble.com/CMSCompressing-and-CMSSigning-not-RFC-conform-tp4658607p4658622.html
> Sent from the Bouncy Castle - Dev mailing list archive at Nabble.com.
>
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CMSCompressing and CMSSigning not RFC conform?

Pat0675
Hi,

no, I have read section 2 also. But like described in 5.2 encapsulated content must be DER encoded. And unfortunately I have to encapsulate the content. Or do I misunderstand this?

Regards
Patrick
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CMSCompressing and CMSSigning not RFC conform?

David Hook-3

Yes. 5.2.1 says only specific content types must be DER encoded. If the
Data type is used the content is BER encoded (of course DER is actually
a subset of BER, however in the context of large files not terribly useful).

5.2 actually says:

    "eContent is the content itself, carried as an octet string.  The
      eContent need not be DER encoded."

Regards,

David

On 03/04/17 17:19, Pat0675 wrote:

> Hi,
>
> no, I have read section 2 also. But like described in 5.2 encapsulated
> content must be DER encoded. And unfortunately I have to encapsulate the
> content. Or do I misunderstand this?
>
> Regards
> Patrick
>
>
>
> --
> View this message in context: http://bouncy-castle.1462172.n4.nabble.com/CMSCompressing-and-CMSSigning-not-RFC-conform-tp4658607p4658624.html
> Sent from the Bouncy Castle - Dev mailing list archive at Nabble.com.
>
>



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: CMSCompressing and CMSSigning not RFC conform?

Pat0675
Hello David,

I'm so stupid.....you are right....
I overlooked that 'not'! That changes some things!

Thank you!

Regards,
Patrick
Loading...