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
