Re: Nested ASN1 strings and OPENSSL_ALLOW_NESTED_ASN1_STRINGS

Luca Milanesio Tue, 03 Mar 2009 05:56:23 -0800

Dear Dr. Steve Henson,

here is the PEM keys (private key + cert), private key password is 12345678, and corresponding PKCS#7 EnvelopedData BER encoded (with 2 level nesting).


Thank you again for your help.

Cheers.

Luca.

Dr. Stephen Henson wrote:

On Mon, Mar 02, 2009, Luca Milanesio wrote:

Steve,

thank you for your valuable feedback !

... I still have another question about the PKCS#7 envelopedData ...
That structure is the encryptedContent field of PKCS#7 envelopedData
content
type.

>From PKCS#7...

EncryptedContentInfo ::= SEQUENCE {
      contentType ContentType,
      contentEncryptionAlgorithm
      ContentEncryptionAlgorithmIdentifier,
      encryptedContent [0] IMPLICIT EncryptedContent OPTIONAL }

      EncryptedContent ::= OCTET STRING
This is exactly the PKCS#7 specification we use in our ASN.1 grammar, as
mentioned in RFC2315-Chap.10.1
Note that encryptedContent has an IMPLICIT tag so the first
 350:d=4  hl=2 l=inf  cons:     cont [ 0 ]
   >
is actually the outer OCTET STRING type. The following:
If the outer implicit tag is considered as the outer OCTET STRING type
... what would it be a correct encoding IYHO for using a BER-encoded OCTET STRING with streaming output ?


The outer OCTET STRING header would the the above cont [ 0 ]. After that
content should be however many DER OCTET STRINGs are required followed by an
EOC.

If you check the OpenSSL 0.9.9-dev branch it includes streaming encode support
(for PKCS#7 and CMS) so you can examine the output it produces.

Is the OPENSSL_ALLOW_NESTED_ASN1_STRINGS enable the only choice ?
Do you think it would help raising the maximum level of nesting up to 2 without impacting the "stack overflow" risk protection ?


The reason it was done that ways was there didn't seem to be any reason to
nest deeper than one level and I'd never come across anything that ever used
that.

It would be possible to include a maximum depth setting instead of just not
allowing a level higher than 2.

Can you send me a sample PKCS#7 structure which is causing you issues so I can
test against it?

P.S. We do not have the same problem with PKCS#7 SignedData, that defines the explicit tag for its content:
 ContentInfo ::= SEQUENCE {
   contentType ContentType,
   content
     [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL }

and the resulting ASN.1 parsed data is:

 35:d=4  hl=2 l=   9 prim:     OBJECT            :pkcs7-data
 46:d=4  hl=2 l=inf  cons:     cont [ 0 ]
 48:d=5  hl=2 l=inf  cons:      OCTET STRING
 50:d=6  hl=2 l=   5 prim:       OCTET STRING      :ciao

 57:d=6  hl=2 l=   0 prim:       EOC
 59:d=5  hl=2 l=   0 prim:      EOC
 61:d=4  hl=2 l=   0 prim:     EOC
In this case, the first "cont[0]" is not considered by OpenSSL ASN.1 parser as a level of nesting ... everything is then correctly processed without errors.


The outer OCTET STRING header due to the EXPLICIT tag in that case is both
cont [0] and the OCTET STRING, so it is really one level.

Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majord...@openssl.org

out.p7m
Description: Binary data

token.pem
Description: application/x509-ca-cert

Re: Nested ASN1 strings and OPENSSL_ALLOW_NESTED_ASN1_STRINGS

Reply via email to