[openssl-users] Is the structure of this CMS object correct?

[Erwann Abalea]

Bonjour,

Le 9 févr. 2016 à 10:15, Stephan Mühlstrasser <stm at pdflib.com<mailto:stm at pdflib.com>> a écrit :

Hi,

I'm trying to decrypt a DER-encoded CMS object (created by Adobe Acrobat) with OpenSSL 1.0.2d:

$ openssl cms -decrypt -in recipient.bin  -inform DER -inkey atssecp521r1.key -recip atssecp521r1.pem
Error reading S/MIME message
140735227593552:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1198:
140735227593552:error:0D06C03A:asn1 encoding routines:ASN1_D2I_EX_PRIMITIVE:nested asn1 error:tasn_dec.c:762:
140735227593552:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:694:Field=version, Type=CMS_KeyAgreeRecipientInfo
140735227593552:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:685:
140735227593552:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:336:Field=d.kari, Type=CMS_RecipientInfo
140735227593552:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:666:Field=recipientInfos, Type=CMS_EnvelopedData
140735227593552:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:694:
140735227593552:error:0D08403A:asn1 encoding routines:ASN1_TEMPLATE_EX_D2I:nested asn1 error:tasn_dec.c:557:Field=d.envelopedData, Type=CMS_ContentInfo

The full dumpasn1 output of the file "recipient.bin" is below at the end of the message. Is this a correct CMS object?

If I compare this to the structure of a CMS object that was generated by OpenSSL itself, there's a difference in the structure of the RecipientInfos object. If I understand it correctly, this is the start of the RecipientInfos object (starting at line 6 of the dumpasn1 output):

      SET {
        [1] {
          SEQUENCE {
            INTEGER 3
            …

This is the expression of an EXPLICIT tag.

I can match this to the following rules in RFC 5652:

RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo

RecipientInfo ::= CHOICE {
       ktri KeyTransRecipientInfo,
       kari [1] KeyAgreeRecipientInfo,
       kekri [2] KEKRecipientInfo,
       pwri [3] PasswordRecipientinfo,
       ori [4] OtherRecipientInfo }

KeyAgreeRecipientInfo ::= SEQUENCE {
       version CMSVersion,  -- always set to 3
       originator [0] EXPLICIT OriginatorIdentifierOrKey,
       ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
       keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
       recipientEncryptedKeys RecipientEncryptedKeys }

See RFC5652 section 12.1.
These data types are defined in a module with IMPLICIT TAGS (it was changed between PKCS#7v1.5 and RFC2630), so kari, kekri, pwri, and ori elements are associated to an IMPLICIT tag.

Additional definition to read the dump.

OriginatorIdentifierOrKey ::= CHOICE {
     issuerAndSerialNumber IssuerAndSerialNumber,
     subjectKeyIdentifier [0] SubjectKeyIdentifier,
     originatorKey [1] OriginatorPublicKey }

OriginatorPublicKey ::= SEQUENCE {
     algorithm AlgorithmIdentifier,
     publicKey BIT STRING }


If I dump a CMS object that was created with OpenSSL's CMS tool with the same certificate as the problematic one, the structure of the RecipientInfos object looks like this:

      SET {
        [1] {
          INTEGER 3
          …

So the "SEQUENCE" element of the KeyAgreeRecipientInfo is not present here.

This is the correct behavior of an IMPLICIT tag.

Another issue in the Acrobat-generated CMS object is the top-level CMSVersion in the EnvelopedData object being 0. I believe this is wrong and should be 2, but apparently OpenSSL doesn't care.

Full output of dumpasn1 for "recipient.bin" file:

SEQUENCE {
  OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
  [0] {
    SEQUENCE {
      INTEGER 0
      SET {
        [1] {
          SEQUENCE {

This is wrong, the SEQUENCE is to be hidden by the [1] tag.

            INTEGER 3
            [0] {

The [0] introduces the originator element, of type OriginatorIdentifierOrKey, it’s EXPLICIT.

              [1] {
                SEQUENCE {

Also wrong, the [1] here should be IMPLICIT and hide the SEQUENCE tag of the OriginatorPublicKey structure.

                  SEQUENCE {
                    OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
                    OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)
                    }
                  BIT STRING
                  04 01 91 BE 01 63 00 79 C2 D2 95 0F 9D 03 A4 34
                  5A 9C 2F 98 4A 13 D4 59 C6 EA 6C 4B 6D 7D 2B DC
                  1C 08 16 86 EF F0 C2 3D AE A4 AF A3 7C 7E 15 80
                  55 18 06 2C E9 09 19 3A 3A 78 DD 93 F1 33 B1 1E
                  9A 76 7C 01 1E 8B B6 B0 FE 5E BA FD 04 EE F3 84
                  3D 47 61 22 D2 A3 AC 1C D4 B8 66 57 94 B1 74 83
                  B1 4E 7F 2F 64 7F 4F 64 40 6A 1D 02 38 5F FE DF
                  93 7B 14 6D 5A BF 75 AC 77 CB 47 2B 16 F0 9D C7
                          [ Another 5 bytes skipped ]
                  }
                }
              }

I haven’t checked the rest.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160209/4408c59e/attachment-0001.html>