Explicit tag on AuthEnvelopedData encryptedContent

[stevemit]

BouncyCastle 1.83 produces an AuthEnvelopedData structure with an explicitly tagged authEncryptedContentInfo/encryptedContent, whereas RFC 5652 calls for it to be implicitly tagged.

I am using CMSAuthEnvelopedDataStreamGenerator with JceCMSContentEncryptorBuilder.

OpenSSL produces an implicit tag. Both BouncyCastle and OpenSSL process the AuthEnvelopedData structure with the explicit tag.
However, the issue can complicate diagnosing other interoperability problems.

[peterdettman]

From what I can see, we correctly use implicit tagging for the encryptedContent field of EncryptedContentInfo, so I suppose you will need to show example generator code and perhaps a dump of the ASN.1 highlighting where you think the error is.

[stevemit]

Now I can't say whether the BER encoding is valid. If so, the encoding contains three, not two, nested layers of OCTET STRING. I don't know whether that's conformant or expected by implementations, but it seems to work with BC and OpenSSL.

Attached are test code and output (BouncyCastle 1.83).

At hex offset 0xD5 is the encryptedContent with BER encoding

A0 80 24 80 04 2D ...skip 0x2D bytes... 00 00 00 00

The grammar says this is

• an implicitly tagged constructed indefinite length OCTET STRING containing
• a second constructed indefinite length OCTET STRING containing
• a primitive definite length OCTET STRING.

Initially I interpreted the encoding as an explicit tag and two nested layers of OCTET STRING.

BCTest.java

test.zip

[stevemit]

According to X.690 sec. 8.7.3.2, three layers of nested OCTET STRING is unusual but valid. Closing.

As a consequence of this recursion, each encoding in the contents octets may itself be primitive or constructed.
However, such encodings will usually be primitive.

[peterdettman]

Upon review, your initial assessment was correct: encryptedContent (on this code path) was being generated with an explicit tag. The vagaries of ASN.1 constructed encodings mean that the resulting encoding can still be parsed as an IMPLICIT OCTET STRING, albeit the extra level (unusual rather than illegal) suggests the "error".

The tagging has now been fixed to be implicit, thanks for the report.