Is the structure of this CMS object correct?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Is the structure of this CMS object correct?

Stephan Mühlstrasser
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
              ...

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 }

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.

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 {
              INTEGER 3
              [0] {
                [1] {
                  SEQUENCE {
                    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 ]
                    }
                  }
                }
              [1] {
                OCTET STRING E5 38 52 B1 13 7C 44 40
                }
              SEQUENCE {
                OBJECT IDENTIFIER '1 3 132 1 11 3'
                SEQUENCE {
                  OBJECT IDENTIFIER
                    aes256-wrap (2 16 840 1 101 3 4 1 45)
                  }
                }
              SEQUENCE {
                SEQUENCE {
                  SEQUENCE {
                    SEQUENCE {
                      SET {
                        SEQUENCE {
                          OBJECT IDENTIFIER countryName (2 5 4 6)
                          PrintableString 'DE'
                          }
                        }
                      SET {
                        SEQUENCE {
                          OBJECT IDENTIFIER localityName (2 5 4 7)
                          UTF8String 'Munich'
                          }
                        }
                      SET {
                        SEQUENCE {
                          OBJECT IDENTIFIER organizationName (2 5 4 10)
                          UTF8String 'PDFlib GmbH'
                          }
                        }
                      SET {
                        SEQUENCE {
                          OBJECT IDENTIFIER commonName (2 5 4 3)
                          UTF8String 'PDFlib GmbH ATS Demo Intermediate CA'
                          }
                        }
                      }
                    INTEGER 27
                    }
                  OCTET STRING
                    3E 41 09 AD 71 B5 E3 26 5F 5A D8 97 01 0D D1 72
                    2F 37 3C AA 47 4F B6 67
                  }
                }
              }
            }
          }
        SEQUENCE {
          OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
          SEQUENCE {
            OBJECT IDENTIFIER aes128-CBC (2 16 840 1 101 3 4 1 2)
            OCTET STRING
              97 40 83 5E 1D 25 48 49 95 56 CE 75 61 1B 49 12
            }
          [0]
            EF 24 A2 94 42 A4 5F C1 F5 6C B4 26 DA BA 6A 1C
            F5 01 21 91 B9 0B 3E 69 29 2E 5C F1 AD EC F0 63
          }
        }
      }
    }

--
  Stephan
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Is the structure of this CMS object correct?

Erwann Abalea-4
Bonjour,

Le 9 févr. 2016 à 10:15, Stephan Mühlstrasser <[hidden email]> 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.



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Is the structure of this CMS object correct?

Stephan Mühlstrasser
Bonjour Erwann,

Am 09.02.16 um 11:53 schrieb Erwann Abalea:

> Bonjour,
>
>> Le 9 févr. 2016 à 10:15, Stephan Mühlstrasser <[hidden email]
>> <mailto:[hidden email]>> a écrit :
>> ...
>>
>>       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.

many thanks for the analysis! One follow-up question:

I can also not decrypt the recipient.bin file with the "openssl smime"
command. Do I understand it correctly then that the input file is
neither a correct PKCS#7 file nor a correct CMS file?

--
Stephan

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Is the structure of this CMS object correct?

Erwann Abalea-4
Bonjour Stephan,


Le 9 févr. 2016 à 12:29, Stephan Mühlstrasser <[hidden email]> a écrit :

Am 09.02.16 um 11:53 schrieb Erwann Abalea:
Bonjour,

Le 9 févr. 2016 à 10:15, Stephan Mühlstrasser <[hidden email]
<[hidden email]>> a écrit :
...

     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.

many thanks for the analysis! One follow-up question:

I can also not decrypt the recipient.bin file with the "openssl smime" command. Do I understand it correctly then that the input file is neither a correct PKCS#7 file nor a correct CMS file?

PKCS#7 and CMS are pretty much interchangeable.
Here, your file is strictly not a PKCS#7v1.5, because in this version, RecipientInfo wasn’t a CHOICE (see RFC2315 to see PKCS#7v1.5 definitions).

How did you generate this structure? Adobe Acrobat?

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Is the structure of this CMS object correct?

Stephan Mühlstrasser
Am 09.02.2016 um 16:39 schrieb Erwann Abalea:
> Bonjour Stephan,
> ...

>> I can also not decrypt the recipient.bin file with the "openssl smime"
>> command. Do I understand it correctly then that the input file is
>> neither a correct PKCS#7 file nor a correct CMS file?
>
> PKCS#7 and CMS are pretty much interchangeable.
> Here, your file is strictly not a PKCS#7v1.5, because in this version,
> RecipientInfo wasn’t a CHOICE (see RFC2315 to see PKCS#7v1.5 definitions).
>
> How did you generate this structure? Adobe Acrobat?

Yes, this structure was generated with Adobe Acrobat XI (document
encrypted with "certificate security").

--
Stephan
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Is the structure of this CMS object correct?

Stephan Mühlstrasser
In reply to this post by Erwann Abalea-4
Am 09.02.16 um 16:39 schrieb Erwann Abalea:
> Bonjour Stephan,
>
> ...
>
> PKCS#7 and CMS are pretty much interchangeable.
> Here, your file is strictly not a PKCS#7v1.5, because in this version,
> RecipientInfo wasn’t a CHOICE (see RFC2315 to see PKCS#7v1.5 definitions).
>
> How did you generate this structure? Adobe Acrobat?

The previous structure was generated with Adobe Acrobat XI.

I repeated the experiment with Adobe Acrobat DC, and something was
changed in the structure of the CMS object, but it still does not look
correct to me (full dumpasn1 output below).

It is clear to me that there is no problem with OpenSSL here, but I
would appreciate it if someone with more authority on CMS and ASN.1 than
me could confirm that the CMS structure is broken and that OpenSSL is
correct to reject it, thanks.

OpenSSL 1.0.2d produces the following error message when trying to
decrypt the CMS message:

$ openssl cms -decrypt -in cms-DC-AES256.der -inform DER -out /dev/null
-inkey atssecp521r1.key -recip atssecp521r1.pem
Error reading S/MIME message
140735215203152:error:0D0680A8:asn1 encoding
routines:ASN1_CHECK_TLEN:wrong tag:tasn_dec.c:1198:
140735215203152:error:0D07803A:asn1 encoding
routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:372:Type=X509_ALGOR
140735215203152:error:0D08303A:asn1 encoding
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1
error:tasn_dec.c:694:Field=keyEncryptionAlgorithm,
Type=CMS_KeyTransRecipientInfo
140735215203152:error:0D08303A:asn1 encoding
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:694:
140735215203152:error:0D07803A:asn1 encoding
routines:ASN1_ITEM_EX_D2I:nested asn1 error:tasn_dec.c:336:Field=d.ktri,
Type=CMS_RecipientInfo
140735215203152:error:0D08303A:asn1 encoding
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1
error:tasn_dec.c:666:Field=recipientInfos, Type=CMS_EnvelopedData
140735215203152:error:0D08303A:asn1 encoding
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:694:
140735215203152:error:0D08403A:asn1 encoding
routines:ASN1_TEMPLATE_EX_D2I:nested asn1
error:tasn_dec.c:557:Field=d.envelopedData, Type=CMS_ContentInfo

I tried again to map the structure of the CMS object to the definitions
in RFC 5652 (comments added with a '%'):

1: SEQUENCE {
2:   OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
                                                    % ContentType
3:   [0] {  % eContent
4:     SEQUENCE {
5:       INTEGER 0 % CMSVersion
           % no OriginatorInfo
6:       SET { % RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
7:         SEQUENCE {
        % SEQUENCE tag should not be present because of implicit tagging?
8:           INTEGER 3
          % version 3 only applicable to KeyAgreeRecipientInfo
9:           [0] {
10:             SEQUENCE {
11:               SEQUENCE {
12:                 OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
13:                 OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)
14:                 }

In line 7 I can't find a mapping anymore to RFC 5652. The OpenSSL error
message indicates that it wants to parse a KeyTransRecipientInfo. In
line 8 the CMSVersion is "3", but that is not applicable to a
KeyTransRecipientInfo, only to a KeyAgreeRecipientInfo.

------------- dumpasn1 output for CMS message ---------------
  SEQUENCE {
    OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
    [0] {
      SEQUENCE {
        INTEGER 0
        SET {
          SEQUENCE {
            INTEGER 3
            [0] {
              SEQUENCE {
                SEQUENCE {
                  OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
                  OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)
                  }
                BIT STRING
                  04 00 69 68 2B EA A2 DD 50 48 52 D2 D7 FF 40 9A
                  9F 86 8E 43 33 42 D5 A4 DE 4A 41 5A 73 F3 99 19
                  A4 C5 19 DF 4D 4E EF 4E 47 54 A1 5A 74 41 F3 50
                  43 94 92 35 2B 37 28 49 53 A8 1D 6E BA 21 C2 E0
                  B0 A1 F0 01 E0 61 B6 91 29 23 52 BA 39 D5 1D FE
                  DA 08 DF C8 7C 11 76 56 73 13 51 B7 8D 69 45 CC
                  A1 D4 57 50 45 2A 63 93 5C A8 FB D4 F3 8F 46 68
                  38 BC 57 81 FD C6 06 86 43 C3 3B 53 90 28 C8 B1
                          [ Another 5 bytes skipped ]
                }
              }
            [1] {
              OCTET STRING C8 71 12 9C B5 64 24 52
              }
            SEQUENCE {
              OBJECT IDENTIFIER '1 3 132 1 11 3'
              SEQUENCE {
                OBJECT IDENTIFIER aes256-wrap (2 16 840 1 101 3 4 1 45)
                }
              }
            SEQUENCE {
              SEQUENCE {
                SEQUENCE {
                  SEQUENCE {
                    SET {
                      SEQUENCE {
                        OBJECT IDENTIFIER countryName (2 5 4 6)
                        PrintableString 'DE'
                        }
                      }
                    SET {
                      SEQUENCE {
                        OBJECT IDENTIFIER localityName (2 5 4 7)
                        UTF8String 'Munich'
                        }
                      }
                    SET {
                      SEQUENCE {
                        OBJECT IDENTIFIER organizationName (2 5 4 10)
                        UTF8String 'PDFlib GmbH'
                        }
                      }
                    SET {
                      SEQUENCE {
                        OBJECT IDENTIFIER commonName (2 5 4 3)
                        UTF8String 'PDFlib GmbH ATS Demo Intermediate CA'
                        }
                      }
                    }
                  INTEGER 27
                  }
                OCTET STRING
                  63 CE 50 C7 31 8A B9 C8 A3 6A 7B 7C 9D 14 50 33
                  09 7C 5D 3D 7B 34 1B 30
                }
              }
            }
          }
        SEQUENCE {
          OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
          SEQUENCE {
            OBJECT IDENTIFIER aes128-CBC (2 16 840 1 101 3 4 1 2)
            OCTET STRING
              88 9B F1 E8 96 0B A8 4D 9C F1 6F FC E3 7D B8 AC
            }
          [0]
            AB 19 35 70 7F CE 88 17 A0 AD FA A2 55 33 68 FD
            48 9D 26 2E DC 7B A7 96 95 19 FA 1F B8 0C DE E0
          }
        }
      }
    }
------------- dumpasn1 output for CMS message ---------------

--
Stephan

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Is the structure of this CMS object correct?

Dr. Stephen Henson
On Tue, Feb 23, 2016, Stephan M?hlstrasser wrote:

> Am 09.02.16 um 16:39 schrieb Erwann Abalea:
> >Bonjour Stephan,
> >
> >...
> >
> >PKCS#7 and CMS are pretty much interchangeable.
> >Here, your file is strictly not a PKCS#7v1.5, because in this version,
> >RecipientInfo wasn?t a CHOICE (see RFC2315 to see PKCS#7v1.5 definitions).
> >
> >How did you generate this structure? Adobe Acrobat?
>
> The previous structure was generated with Adobe Acrobat XI.
>
> I repeated the experiment with Adobe Acrobat DC, and something was
> changed in the structure of the CMS object, but it still does not
> look correct to me (full dumpasn1 output below).
>
> It is clear to me that there is no problem with OpenSSL here, but I
> would appreciate it if someone with more authority on CMS and ASN.1
> than me could confirm that the CMS structure is broken and that
> OpenSSL is correct to reject it, thanks.
>

To properly analyse the structure it would help if you included the file you
are trying to parse.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Is the structure of this CMS object correct?

Stephan Mühlstrasser
Am 23.02.16 um 14:04 schrieb Dr. Stephen Henson:

> On Tue, Feb 23, 2016, Stephan M?hlstrasser wrote:
>
>> Am 09.02.16 um 16:39 schrieb Erwann Abalea:
>>> Bonjour Stephan,
>>>
>>> ...
>>>
>>> PKCS#7 and CMS are pretty much interchangeable.
>>> Here, your file is strictly not a PKCS#7v1.5, because in this version,
>>> RecipientInfo wasn?t a CHOICE (see RFC2315 to see PKCS#7v1.5 definitions).
>>>
>>> How did you generate this structure? Adobe Acrobat?
>>
>> The previous structure was generated with Adobe Acrobat XI.
>>
>> I repeated the experiment with Adobe Acrobat DC, and something was
>> changed in the structure of the CMS object, but it still does not
>> look correct to me (full dumpasn1 output below).
>>
>> It is clear to me that there is no problem with OpenSSL here, but I
>> would appreciate it if someone with more authority on CMS and ASN.1
>> than me could confirm that the CMS structure is broken and that
>> OpenSSL is correct to reject it, thanks.
>>
>
> To properly analyse the structure it would help if you included the file you
> are trying to parse.
>
Sure, here it is. I had thought that ASN.1 dump would be sufficient.

--
Stephan

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

cms-DC-AES256.der (616 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Is the structure of this CMS object correct?

Dr. Stephen Henson
In reply to this post by Stephan Mühlstrasser
On Tue, Feb 23, 2016, Stephan M?hlstrasser wrote:

> I tried again to map the structure of the CMS object to the
> definitions in RFC 5652 (comments added with a '%'):
>
> 1: SEQUENCE {
> 2:   OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
>                                                    % ContentType
> 3:   [0] {  % eContent
> 4:     SEQUENCE {
> 5:       INTEGER 0 % CMSVersion
>           % no OriginatorInfo
> 6:       SET { % RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
> 7:         SEQUENCE {
>        % SEQUENCE tag should not be present because of implicit tagging?

Yes, because it is using the key agreement choice type it should be
tagged [1] IMPLICIT but it is not which is why OpenSSL thinks it is key
transport.

> 8:           INTEGER 3
>          % version 3 only applicable to KeyAgreeRecipientInfo
> 9:           [0] {

Assume this is KeyAgreeRecipientInfo.. the above tag would indicate the
"originator" field.

> 10:             SEQUENCE {

Here it is wrong again. The untagged form is "IssuerAndSerialNumber" which
the fields below certainly aren't. It looks like originatorKey which should be
tagged [1] IMPLICIT.

> 11:               SEQUENCE {
> 12:                 OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
> 13:                 OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)
> 14:                 }
>

So yes it's pretty broken.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Is the structure of this CMS object correct?

Stephan Mühlstrasser
Am 23.02.16 um 18:26 schrieb Dr. Stephen Henson:
> On Tue, Feb 23, 2016, Stephan M?hlstrasser wrote:
>
> ...
>
> So yes it's pretty broken.
>
> Steve.

Thank you for taking the time to analyse this, Steve.

--
Stephan
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Is the structure of this CMS object correct?

Dr. Stephen Henson
In reply to this post by Dr. Stephen Henson
On Tue, Feb 23, 2016, Dr. Stephen Henson wrote:

> On Tue, Feb 23, 2016, Stephan M?hlstrasser wrote:
>
> > I tried again to map the structure of the CMS object to the
> > definitions in RFC 5652 (comments added with a '%'):
> >
> > 1: SEQUENCE {
> > 2:   OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
> >                                                    % ContentType
> > 3:   [0] {  % eContent
> > 4:     SEQUENCE {
> > 5:       INTEGER 0 % CMSVersion
> >           % no OriginatorInfo
> > 6:       SET { % RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo
> > 7:         SEQUENCE {
> >        % SEQUENCE tag should not be present because of implicit tagging?
>
> Yes, because it is using the key agreement choice type it should be
> tagged [1] IMPLICIT but it is not which is why OpenSSL thinks it is key
> transport.
>
> > 8:           INTEGER 3
> >          % version 3 only applicable to KeyAgreeRecipientInfo
> > 9:           [0] {
>
> Assume this is KeyAgreeRecipientInfo.. the above tag would indicate the
> "originator" field.
>
> > 10:             SEQUENCE {
>
> Here it is wrong again. The untagged form is "IssuerAndSerialNumber" which
> the fields below certainly aren't. It looks like originatorKey which should be
> tagged [1] IMPLICIT.
>
> > 11:               SEQUENCE {
> > 12:                 OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
> > 13:                 OBJECT IDENTIFIER secp521r1 (1 3 132 0 35)
> > 14:                 }
> >
>
> So yes it's pretty broken.
>

Just as a quick followup. If you change the two tags I mentioned above the
result does then parse. However I've no idea if it will actually decrypt: the
key derivation might be broken too.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Is the structure of this CMS object correct?

Stephan Mühlstrasser
Am 25.02.16 um 13:16 schrieb Dr. Stephen Henson:

>> So yes it's pretty broken.
>>
>
> Just as a quick followup. If you change the two tags I mentioned above the
> result does then parse. However I've no idea if it will actually decrypt: the
> key derivation might be broken too.

Thanks for the follow-up. As this is a problem in Adobe Acrobat, we
can't do anything about it. The problem was now reported to Adobe, and
hopefully they will fix it.

--
Stephan
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users