Bonjour Erwann,
Am 09.02.16 um 11:53 schrieb Erwann Abalea:
Bonjour,
Le 9 févr. 2016 à 10:15, Stephan Mühlstrasser <s...@pdflib.com
<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
