Re: [Ejbca-develop] PKCS7 indefinite encoding with embedded 00 00 octets breaks pyasn1 parser

[Tomas G. <to...@pr...>]

Also are you sure it's the indefinite-length vs definite length, and not
something else pyasn1 doesn't like?
It could for instance be content encapsulation that can be done in a
couple of ways.

It's not possible to test this on a command line? (i.e. for me without
having to write a python program).

Cheers,
Tomas

On 2015-12-17 10:34, Anthony Alba wrote:
> When using WSDL certificateRequest () with PKCS7WITHCHAIN, the
> returned structure use indefinite length encoding:
> 
>    0:d=0  hl=2 l=inf  cons: SEQUENCE
>     2:d=1  hl=2 l=   9 prim: OBJECT            :pkcs7-signedData
>    13:d=1  hl=2 l=inf  cons: cont [ 0 ]
>    15:d=2  hl=2 l=inf  cons: SEQUENCE
>    17:d=3  hl=2 l=   1 prim: INTEGER           :01
>    20:d=3  hl=2 l=  11 cons: SET
>    22:d=4  hl=2 l=   9 cons: SEQUENCE
>    24:d=5  hl=2 l=   5 prim: OBJECT            :sha1
> 
> however the contents of the data structure, "d=1 cont[0]"  contains 00
> 00 so that some ASN.1 parsers terminate , they treat 00 00 as
> end-of-content and drop bytes. Is the ASN.1 stream malformed?
> 
> For example pyasn1 will strip out all 00 00 in stream and throw the
> following error:
> 
> pkcs7_asn1  = decoder.decode(<PKCS7_DER_FROM_EJBCA>, asn1Spec =
> rfc2315.ContentInfo())
> 
> pyasn1.error.SubstrateUnderrunError: No EOO seen before substrate ends
> 
> Could you consider using definite length encoding?
> 
> However, OpenSSL utility pkcs7 handles these PKCS7 streams fine: maybe
> it assumes the 2nd component continues to the end of file.
> 
> Anthony
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>