Can't get bouncycastle to correctly tag constructed octet string in der encoding

I have the following requirements. I have an asn1 type that needs to be encapsulated in a constructed octet string (octet string tagged as 0x24). This structure is then signed in a CMS signed block and the whole CMS block needs to be DER encoded.

My problem is every time I DER encode the CMS block the constructed octet string becomes a (nonconstructed?) octet string. I mean its tag switches from 0x24 (what I need) to 0x04.

Is this a Bouncycastle bug or am I doing something I shouldn't? Ignoring the CMS block, it appears that anytime I try to der encode a 'BerConstructedOctetString' it no longer is a constructed octetstring:

BERConstructedOctetString constructed = new BERConstructedOctetString(new DERInteger(3));
ASN1Object nonConstructed= new DEROctetString(new DERInteger(3));

System.out.println(Util.toHex(constructed.getDEREncoded()));
System.out.println(Util.toHex(nonConstructed.getDEREncoded()));
System.out.println(Util.toHex(constructed.getEncoded()));
System.out.println(Util.toHex(nonConstructed.getEncoded()));

With the following output:

04:03:02:01:03
04:03:02:01:03
24:80:04:03:02:01:03:00:00
04:03:02:01:03

Edit: Is this even possible? Is there a reason both bouncycastle and not-yet-commons-ssl contain 'BerConstructedOctetString' that enc开发者_StackOverflowode and tag as 0x04 when encoded to DER? Are my two requirements incompatible?

I always go to this reference from the old RSA Laboratories to answer questions about BER/DER encoding. In this case, look at rule #3 in section 4 (DER encoding rules):

3. For simple string types and implicitly tagged types derived from
simple string types, the primitive, definite-length method must be
employed.

If I read this correctly, this forces the primitive encoding with 0x04 if you ask for DER encoding.