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

2016-02-29 Thread 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

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

2016-02-25 Thread 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

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

2016-02-23 Thread 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

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

2016-02-23 Thread Dr. Stephen Henson 
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

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

2016-02-23 Thread 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


cms-DC-AES256.der
Description: application/x509-ca-cert
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

2016-02-23 Thread 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

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

2016-02-23 Thread Stephan Mühlstrasser 

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

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

2016-02-09 Thread 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

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

2016-02-09 Thread Erwann Abalea 
Bonjour Stephan,


Le 9 févr. 2016 à 12:29, Stephan Mühlstrasser 
mailto:s...@pdflib.com>> a écrit :

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

Le 9 févr. 2016 à 10:15, Stephan Mühlstrasser 
mailto:s...@pdflib.com>
> 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

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

2016-02-09 Thread 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 mailto:s...@pdflib.com>> 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

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

2016-02-09 Thread Erwann Abalea 
Bonjour,

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

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

2016-02-09 Thread 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'
 }
   }