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

[Erwann Abalea]

Bonjour Stephan,


Le 9 févr. 2016 à 12:29, Stephan Mühlstrasser <stm at pdflib.com<mailto:stm at 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 <stm at pdflib.com<mailto:stm at pdflib.com>
<mailto:stm at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160209/835a6d31/attachment.html>