Basic problem is me generating a signed document with "openssl smime" and being able to verify it, but my partner is not (using a different software). So I tried to dig into it and have a look if his and my message digest are identical. But - I cannot even find out what message digest is actually (and correctly) used in my document.
I have a file with name "cleartext.txt", containing arbitrary text. Then I do
$ openssl smime -sign -md sha256 -nocerts -inkey as2.key -signer as2.crt -outform PEM < cleartext.txt > signature.txt
$ openssl sha256 cleartext.txt
$ openssl asn1parse -in signature.txt
The second statement generates the hash value:
SHA256(cleartext.txt)= c64df2df82cc1dab9f9b06d41fab458de976de7e149fe0854fe125a96ef151dd
The last statement shows me the details of my certificate (so at least something must be working here) plus
251:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data
262:d=6 hl=2 l= 28 cons: SEQUENCE
264:d=7 hl=2 l= 9 prim: OBJECT :signingTime
275:d=7 hl=2 l= 15 cons: SET
277:d=8 hl=2 l= 13 prim: UTCTIME :200107145037Z
292:d=6 hl=2 l= 47 cons: SEQUENCE
294:d=7 hl=2 l= 9 prim: OBJECT :messageDigest
305:d=7 hl=2 l= 34 cons: SET
307:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:0E68D5CC9A859736EEE842355C1FD73F3FC9B274657A97F4CAF38AD3344ACBC8
341:d=6 hl=2 l= 121 cons: SEQUENCE
343:d=7 hl=2 l= 9 prim: OBJECT :S/MIME Capabilities
354:d=7 hl=2 l= 108 cons: SET
356:d=8 hl=2 l= 106 cons: SEQUENCE
358:d=9 hl=2 l= 11 cons: SEQUENCE
360:d=10 hl=2 l= 9 prim: OBJECT :aes-256-cbc
371:d=9 hl=2 l= 11 cons: SEQUENCE
373:d=10 hl=2 l= 9 prim: OBJECT :aes-192-cbc
384:d=9 hl=2 l= 11 cons: SEQUENCE
386:d=10 hl=2 l= 9 prim: OBJECT :aes-128-cbc
397:d=9 hl=2 l= 10 cons: SEQUENCE
399:d=10 hl=2 l= 8 prim: OBJECT :des-ede3-cbc
409:d=9 hl=2 l= 14 cons: SEQUENCE
411:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc
421:d=10 hl=2 l= 2 prim: INTEGER :80
425:d=9 hl=2 l= 13 cons: SEQUENCE
427:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc
437:d=10 hl=2 l= 1 prim: INTEGER :40
440:d=9 hl=2 l= 7 cons: SEQUENCE
442:d=10 hl=2 l= 5 prim: OBJECT :des-cbc
449:d=9 hl=2 l= 13 cons: SEQUENCE
451:d=10 hl=2 l= 8 prim: OBJECT :rc2-cbc
461:d=10 hl=2 l= 1 prim: INTEGER :28
464:d=5 hl=2 l= 13 cons: SEQUENCE
466:d=6 hl=2 l= 9 prim: OBJECT :rsaEncryption
477:d=6 hl=2 l= 0 prim: NULL
479:d=5 hl=4 l= 256 prim: OCTET STRING [HEX DUMP]:4CBEA622925F2CD899D2B5A0D26F831C0D63DE88FC5CC1E89F8F164E84526E49194AD537426378D6932DA066425A117B9FA96A70E2000F603449095AAF8E0B93D0D4EB26FC2B3D86726F94928882C37ACEF0537555DEB4AF3D63943A05A109D49B941C8131A9734C15BA7418F2D34E6B63B710E975EDE1EB9A71A40C251D6D72A5C802F3CDAE123E5E47413DC414DF8A2B0BB6E225145224C33E64245F6E4BD3EC3A60E0B0D6FAA8F9BE69BFA0B27E4A3326E819EF8A1C13738CA1A02D08F74D22C52ABA84D6FD26BE8EA6461251162CD751DC6DC2A30FB45211AC28B371F5FEDB57C3845DA04C4C0FFC40760C623C574471CECD4681E7755277B8BFD8F31730
Why do I get "c64df2..." with one of those commands and "0e68d5..." with the other one? How can I expect my partner to verify my signatures, if I am not even able to reproduce the hash value on my clear text?
Solution found after some reading plus trial&error: RFC2049 requires in chapter 4(2) that plain text is converted to a canonical form, i.e. using CRLF for line endings.
openssl smime -sign silently makes this conversion for its input files, but openssl sha256 does not.
As soon as I use CRLF myself, the result is identical, as expected.
Related
I found this excellent approach on shortening GUIDs here on stackowerflow: .NET Short Unique Identifier
I have some other strings that I wanted to treat the same way, but I found out that in most cases the Base64String is even longer than the original string.
My question is: why does [guid]::NewGuid().ToByteArray() return a significant smaller byte array than [System.Text.Encoding]::UTF8.GetBytes([guid]::NewGuid().Guid)?
For example, let's look at the following GUID:
$guid = [guid]::NewGuid()
$guid
Guid
----
34c2b21e-18c3-46e7-bc76-966ae6aa06bc
With $guid.GetBytes(), the following is returned:
30
178
194
52
195
24
231
70
188
118
150
106
230
170
6
188
And [System.Convert]::ToBase64String($guid.ToByteArray()) generates HrLCNMMY50a8dpZq5qoGvA==
[System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($guid.Guid)), however, returns MzRjMmIyMWUtMThjMy00NmU3LWJjNzYtOTY2YWU2YWEwNmJj, with [System.Text.Encoding]::UTF8.GetBytes($guid.Guid) being:
51
52
99
50
98
50
49
101
45
49
56
99
51
45
52
54
101
55
45
98
99
55
54
45
57
54
54
97
101
54
97
97
48
54
98
99
The GUID struct is an object storing a 16 byte array that contains its value.
These are the 16 bytes you see when you perform its method .ToByteArray() method.
The 'normal' string representation is a grouped series of these bytes in hexadecimal format. (4-2-2-2-6)
As for converting to Base64, this will always return a longer string because each Base64 digit represents exactly 6 bits of data.
Therefore, every three 8-bits bytes of the input (3×8 bits = 24 bits) can be represented by four 6-bit Base64 digits (4×6 = 24 bits).
The resulting string can even be extended with = padding characters at the end of the string to always be a multiple of 4.
The result is a string of [math]::Ceiling(<original size> / 3) * 4 length.
Using [System.Text.Encoding]::UTF8.GetBytes([guid]::NewGuid().Guid) is actually first performing the GUID's .ToString() method and from that string it will return the ascii values of each character in there.
(hexadecimal representation = 2 characters per byte = 32 values + the four dashes in it leaves a 36-byte array)
[guid]::NewGuid().ToByteArray()
In the scope of this question, a GUID can be seen as a 128-bit number (actually it is a structure, but that's not relevant to the question). When converting it into a byte array, you divide 128 by 8 (bits per byte) and get an array of 16 bytes.
[System.Text.Encoding]::UTF8.GetBytes([guid]::NewGuid().Guid)
This converts the GUID to a hexadecimal string representation first. Then this string gets encoded as UTF-8.
A hex string uses two characters per input byte (one hex digit for the lower and one for the upper 4 bits). So we need at least 32 characters (16 bytes of GUID multiplied by 2). When converted to UTF-8 each character relates to exactly one byte, because all hex digits as well as the dash are in the basic ASCII range which maps 1:1 to UTF-8. So including the dashes we end up with 32 + 4 = 36 bytes.
So this is what [System.Convert]::ToBase64String() has to work with - 16 bytes of input in the first case and 36 bytes in the second case.
Each Base64 output digit represents up to 6 input bits.
16 input bytes = 128 bits, divided by 6 = 22 Base64 characters
36 input bytes = 288 bits, divided by 6 = 48 Base64 characters
That's how you end up with more than twice the number of Base64 characters when converting a GUID to hex string first.
I have 64 two-byte (short) numbers in memory like this: 0 1 2 3 ... 63. I want to shuffle them so that they look like this in memory:
0 16 32 48 1 17 33 49 2 18 34 50 ... 15 31 47 63
What is the most effective way to do this using avx2 or avx512?
Suppose I create a x25519 key pair using openssl, it will output a 64 Bytes private key and the corresponding 44 Bytes Base64 encoded public key which would look like
-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VuBCIEIMBF8S7zUco4bRrMiIuyTcSYU/rAVlNtE8SMYWphUatw
-----END PRIVATE KEY-----
-----BEGIN PUBLIC KEY-----
MCowBQYDK2VuAyEAE0eiiP0PKjy9AVM/0z2ZIZn453WSJNemrQ58HAXDaX0=
-----END PUBLIC KEY-----
Swift CryptoKit is only accepting 32 Bytes for each, private and public key initialisation.
If I understood correctly, the 64 Bytes private key is the seed, where the first 32 Bytes are the actual private key.
Still, using the same principle for the the public key is not working (not very surprising tbh)
The question is now: How do I translate the public key to the 32 Bytes required by Swift CryptoKit?
Here is the non functioning example of using the first 32 Bytes of the base64 decoded public key
let base64PublicKey = Data(base64Encoded: "MCowBQYDK2VuAyEAE0eiiP0PKjy9AVM/0z2ZIZn453WSJNemrQ58HAXDaX0=")!.dropLast(12)
let publicKey = try! Curve25519.KeyAgreement.PublicKey(rawRepresentation: rawPublicKey)
-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VuBCIEIMBF8S7zUco4bRrMiIuyTcSYU/rAVlNtE8SMYWphUatw
-----END PRIVATE KEY-----
per rfc7468 is a PKCS8-unencrypted PrivateKeyInfo which is encoded in ASN.1 DER and contains data about the algorithm (and in general but not here parameters) as well as the actual key. Running this into openssl asn1parse -i (which automatically de-base64's) gives
0:d=0 hl=2 l= 46 cons: SEQUENCE
2:d=1 hl=2 l= 1 prim: INTEGER :00
5:d=1 hl=2 l= 5 cons: SEQUENCE
7:d=2 hl=2 l= 3 prim: OBJECT :X25519
12:d=1 hl=2 l= 34 prim: OCTET STRING [HEX DUMP]:0420C045F12EF351CA386D1ACC888BB24DC49853FAC056536D13C48C616A6151AB70
The algorithm-specific privatekey is the OCTETSTRING with value at offset 12+2 and length 34, but that actually contains a nested OCTETSTRING encoding whose first two octets are 04=tag and 20=length, so the true privatekey is at offset 16 with length 32 -- or more simply the last 32 bytes.
-----BEGIN PUBLIC KEY-----
MCowBQYDK2VuAyEAE0eiiP0PKjy9AVM/0z2ZIZn453WSJNemrQ58HAXDaX0=
-----END PUBLIC KEY-----
similarly is the SubjectPublicKeyInfo structure defined by X.509 and PKIX which similarly is DER and contains data in addition to the key. Parsing it (with -dump) gives:
0:d=0 hl=2 l= 42 cons: SEQUENCE
2:d=1 hl=2 l= 5 cons: SEQUENCE
4:d=2 hl=2 l= 3 prim: OBJECT :X25519
9:d=1 hl=2 l= 33 prim: BIT STRING
0000 - 00 13 47 a2 88 fd 0f 2a-3c bd 01 53 3f d3 3d 99 ..G....*<..S?.=.
0010 - 21 99 f8 e7 75 92 24 d7-a6 ad 0e 7c 1c 05 c3 69 !...u.$....|...i
0020 - 7d
The first octet of a BITSTRING value is used for the number of unused/pad bits, here 00, so the real publickey value is the 33-1=32 octets at offset 9+2+1=12, or again the last 32 bytes.
Ed25519 hashes the privatekey to produce both a 32-byte scalar sometimes called the seed plus a 32-byte value which determines the publickey. This seed can be stored with the privatekey to make signing more efficient, but OpenSSL does not do this for Ed25519, and it doesn't apply at all to X25519.
We searched for DER-encoded SEQUENCE's in an executable. After cherrpicking those, which looked like valid DER-encoded data, we wanted to analyse how they are used.
X.509 Certificates and CMS Objects were easy to recognize (since we are aware of them), but we also found valid encodings, from which we cant tell what they are used for.
E.g. Have a look at the following output of openssl asn1parse (...):
0:d=0 hl=4 l=1804 cons: SEQUENCE
4:d=1 hl=2 l= 1 prim: INTEGER :03
7:d=1 hl=4 l=1797 cons: SEQUENCE
11:d=2 hl=2 l= 20 cons: SEQUENCE
13:d=3 hl=2 l= 8 prim: OBJECT :des-ede3-cbc
23:d=3 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:0000000000000000
33:d=2 hl=2 l= 3 prim: PRINTABLESTRING :<OMITTED>
38:d=2 hl=2 l= 13 prim: UTCTIME :<OMITTED>
53:d=2 hl=2 l= 1 prim: INTEGER :01
56:d=2 hl=4 l=1748 cons: SET
60:d=3 hl=4 l= 830 cons: SEQUENCE
64:d=4 hl=2 l= 6 prim: PRINTABLESTRING :PKRoot
72:d=4 hl=2 l= 13 prim: UTCTIME :<OMITTED>
87:d=4 hl=2 l= 5 prim: OBJECT :1.3.36.2.5.1
94:d=4 hl=4 l= 796 cons: SEQUENCE
98:d=5 hl=2 l= 69 cons: SEQUENCE
100:d=6 hl=2 l= 11 cons: SET
102:d=7 hl=2 l= 9 cons: SEQUENCE
104:d=8 hl=2 l= 3 prim: OBJECT :countryName
109:d=8 hl=2 l= 2 prim: PRINTABLESTRING :<OMITTED>
113:d=6 hl=2 l= 31 cons: SET
115:d=7 hl=2 l= 29 cons: SEQUENCE
117:d=8 hl=2 l= 3 prim: OBJECT :organizationName
122:d=8 hl=2 l= 22 prim: PRINTABLESTRING :<OMITTED>
146:d=6 hl=2 l= 21 cons: SET
148:d=7 hl=2 l= 19 cons: SEQUENCE
150:d=8 hl=2 l= 3 prim: OBJECT :commonName
155:d=8 hl=2 l= 12 prim: PRINTABLESTRING :<OMITTED>
169:d=5 hl=4 l= 614 cons: SEQUENCE
173:d=6 hl=2 l= 3 cons: cont [ 0 ]
175:d=7 hl=2 l= 1 prim: INTEGER :02
178:d=6 hl=2 l= 1 prim: INTEGER :00
181:d=6 hl=4 l= 290 cons: SEQUENCE
185:d=7 hl=2 l= 13 cons: SEQUENCE
187:d=8 hl=2 l= 9 prim: OBJECT :rsaEncryption
198:d=8 hl=2 l= 0 prim: NULL
200:d=7 hl=4 l= 271 prim: BIT STRING
475:d=6 hl=2 l= 32 cons: cont [ 1 ]
477:d=7 hl=2 l= 30 cons: SEQUENCE
479:d=8 hl=2 l= 13 prim: UTCTIME :<OMITTED>
494:d=8 hl=2 l= 13 prim: UTCTIME :<OMITTED>
509:d=6 hl=2 l= 15 cons: cont [ 2 ]
511:d=7 hl=2 l= 13 cons: SEQUENCE
513:d=8 hl=2 l= 9 prim: OBJECT :sha256WithRSAEncryption
524:d=8 hl=2 l= 0 prim: NULL
526:d=6 hl=4 l= 257 prim: BIT STRING
787:d=5 hl=2 l= 105 cons: cont [ 0 ]
789:d=6 hl=2 l= 103 cons: SEQUENCE
791:d=7 hl=2 l= 15 cons: SEQUENCE
793:d=8 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints
798:d=8 hl=2 l= 1 prim: BOOLEAN :255
801:d=8 hl=2 l= 5 prim: OCTET STRING [HEX DUMP]:<OMITTED>
808:d=7 hl=2 l= 37 cons: SEQUENCE
810:d=8 hl=2 l= 3 prim: OBJECT :X509v3 Subject Alternative Name
815:d=8 hl=2 l= 30 prim: OCTET STRING [HEX DUMP]:<OMITTED>
847:d=7 hl=2 l= 14 cons: SEQUENCE
849:d=8 hl=2 l= 3 prim: OBJECT :X509v3 Key Usage
854:d=8 hl=2 l= 1 prim: BOOLEAN :255
857:d=8 hl=2 l= 4 prim: OCTET STRING [HEX DUMP]:<OMITTED>
863:d=7 hl=2 l= 29 cons: SEQUENCE
865:d=8 hl=2 l= 3 prim: OBJECT :X509v3 Subject Key Identifier
870:d=8 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:<OMITTED>
894:d=3 hl=4 l= 910 cons: SEQUENCE
898:d=4 hl=2 l= 4 prim: PRINTABLESTRING :Cert
904:d=4 hl=2 l= 13 prim: UTCTIME :<OMITTED>
919:d=4 hl=2 l= 5 prim: OBJECT :1.3.36.2.1.3
926:d=4 hl=4 l= 878 cons: SEQUENCE
930:d=5 hl=4 l= 598 cons: SEQUENCE
934:d=6 hl=2 l= 3 cons: cont [ 0 ]
936:d=7 hl=2 l= 1 prim: INTEGER :02
939:d=6 hl=2 l= 1 prim: INTEGER :00
942:d=6 hl=2 l= 13 cons: SEQUENCE
944:d=7 hl=2 l= 9 prim: OBJECT :sha256WithRSAEncryption
955:d=7 hl=2 l= 0 prim: NULL
957:d=6 hl=2 l= 69 cons: SEQUENCE
959:d=7 hl=2 l= 11 cons: SET
961:d=8 hl=2 l= 9 cons: SEQUENCE
963:d=9 hl=2 l= 3 prim: OBJECT :countryName
968:d=9 hl=2 l= 2 prim: PRINTABLESTRING :<OMITTED>
972:d=7 hl=2 l= 31 cons: SET
974:d=8 hl=2 l= 29 cons: SEQUENCE
976:d=9 hl=2 l= 3 prim: OBJECT :organizationName
981:d=9 hl=2 l= 22 prim: PRINTABLESTRING :<OMITTED>
1005:d=7 hl=2 l= 21 cons: SET
1007:d=8 hl=2 l= 19 cons: SEQUENCE
1009:d=9 hl=2 l= 3 prim: OBJECT :commonName
1014:d=9 hl=2 l= 12 prim: PRINTABLESTRING :<OMITTED>
1028:d=6 hl=2 l= 30 cons: SEQUENCE
1030:d=7 hl=2 l= 13 prim: UTCTIME :<OMITTED>
1045:d=7 hl=2 l= 13 prim: UTCTIME :<OMITTED>
1060:d=6 hl=2 l= 69 cons: SEQUENCE
1062:d=7 hl=2 l= 11 cons: SET
1064:d=8 hl=2 l= 9 cons: SEQUENCE
1066:d=9 hl=2 l= 3 prim: OBJECT :countryName
1071:d=9 hl=2 l= 2 prim: PRINTABLESTRING :<OMITTED>
1075:d=7 hl=2 l= 31 cons: SET
1077:d=8 hl=2 l= 29 cons: SEQUENCE
1079:d=9 hl=2 l= 3 prim: OBJECT :organizationName
1084:d=9 hl=2 l= 22 prim: PRINTABLESTRING :<OMITTED>
1108:d=7 hl=2 l= 21 cons: SET
1110:d=8 hl=2 l= 19 cons: SEQUENCE
1112:d=9 hl=2 l= 3 prim: OBJECT :commonName
1117:d=9 hl=2 l= 12 prim: PRINTABLESTRING :<OMITTED>
1131:d=6 hl=4 l= 290 cons: SEQUENCE
1135:d=7 hl=2 l= 13 cons: SEQUENCE
1137:d=8 hl=2 l= 9 prim: OBJECT :rsaEncryption
1148:d=8 hl=2 l= 0 prim: NULL
1150:d=7 hl=4 l= 271 prim: BIT STRING
1425:d=6 hl=2 l= 105 cons: cont [ 3 ]
1427:d=7 hl=2 l= 103 cons: SEQUENCE
1429:d=8 hl=2 l= 15 cons: SEQUENCE
1431:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints
1436:d=9 hl=2 l= 1 prim: BOOLEAN :255
1439:d=9 hl=2 l= 5 prim: OCTET STRING [HEX DUMP]:<OMITTED>
1446:d=8 hl=2 l= 37 cons: SEQUENCE
1448:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subject Alternative Name
1453:d=9 hl=2 l= 30 prim: OCTET STRING [HEX DUMP]:<OMITTED>
1485:d=8 hl=2 l= 14 cons: SEQUENCE
1487:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Key Usage
1492:d=9 hl=2 l= 1 prim: BOOLEAN :255
1495:d=9 hl=2 l= 4 prim: OCTET STRING [HEX DUMP]:<OMITTED>
1501:d=8 hl=2 l= 29 cons: SEQUENCE
1503:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subject Key Identifier
1508:d=9 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:<OMITTED>
1532:d=5 hl=2 l= 13 cons: SEQUENCE
1534:d=6 hl=2 l= 9 prim: OBJECT :sha256WithRSAEncryption
1545:d=6 hl=2 l= 0 prim: NULL
1547:d=5 hl=4 l= 257 prim: BIT STRING
Does anybody recognize, which ASN.1 type maps to this?
Of course, there are some patterns (e.g. at offset 98 or 930) which are easy to recognize, but is there any "clever" way of identifying unknown ASN.1 structures?
Special Google search-patterns, websites, software, etc.?
We tried Google searches like * ::= SEQUENCE { * INTEGER } etc., with no success.
Look at this: http://www.oid-info.com/get/1.3.36.2.1
oid-info.com currently has over 950.000 OID's, but it has your OID in question up to the level 1.3.36.
Therefore, by querying this service starting from 1.3.36 will give you the that this OID is registered by
TeleTrusT - IT Security Association Germany
and querying with 1.3.36.2 will tell you that it is a
Security information object
and with 1.3.36.2.1 will tell you that this is a
Certificate
However, there is no information on 1.3.36.2.5.1 or 1.3.36.2.1.3, this is because it doesn't have to, because once 1.3.36 is registered by TeleTrust, they have overall ownership on the sub nodes.
I don't know if the registration office has a service to let you query among all registered OID's, but for now, odi-info has some 1 million OID's queryable.
To me, this dump looks like a sort of PKCS#7 message (but it is not PKCS#7). There is no universal way to bind raw data to arbitrary ASN object without ASN module. You may need to create your own tables, map raw data to them and see which table succeed. It is not that easy without knowing each message semantic (which is defined in the ASN module). If you are on Windows, you can try the following command:
certutil -dump path\fileWithUnknownAsn.ext
Certutil has several built-in tables to represent common X509 objects and, maybe, it shows you what is that.
Enrypted email encrypted using certificate provider Entrust is unable to be decrypted by MS Outlook client.
The error outlook throws is:
This message cannot be decoded. An error occured while unprotecting the message. It could not be decrypted because an error occured decrypting the symmetric encryption key. The original data may be corrupt
I have found a solution to this issue. After decoding the encrypted email I see from the pkcs7-envelopedData that OID ":rsaEncryption" is missing.
Here is how a good envelope using RSA for Key Encryption and AES256 for data encryption looks like
0:d=0 hl=5 l=393952 cons: SEQUENCE
5:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-envelopedData
16:d=1 hl=5 l=393936 cons: cont [ 0 ]
21:d=2 hl=5 l=393931 cons: SEQUENCE
26:d=3 hl=2 l= 1 prim: INTEGER :02
29:d=3 hl=4 l= 304 cons: SET
33:d=4 hl=4 l= 300 cons: SEQUENCE
37:d=5 hl=2 l= 1 prim: INTEGER :02
40:d=5 hl=2 l= 20 prim: cont [ 0 ]
62:d=5 hl=2 l= 13 cons: SEQUENCE
64:d=6 hl=2 l= 9 prim: OBJECT :rsaEncryption
75:d=6 hl=2 l= 0 prim: NULL
77:d=5 hl=4 l= 256 prim: OCTET STRING [HEX DUMP]:A2F5A9F82CCE74FE71554032235FAB5560AC1F2AEB7C25462D80CFF84658DD4D3823FBCB602B992BF3F74D385F64582459AE7DFF5AADDCA296D57D85F49B0BADE2868FC8EDC0E8CD8EDFC6831DCDCA7B7B951EFBB77E19A6BFE74F14D6DA3DD83743014A6007A2A7040F7C15BB2179767D54F849257D14E4C1229B3EB8C29552A15ACDC163FB5799E3B75D0B10D47147F97B95E663C8EB28729847DECD2A0806F710F4186C991277D5F3C1123B8A6907A6795B7C849C1D263721C78E72E5642353D8B9A2B68FB2F9552868CC1F4E4B9785D2E8314D6438490A9AF8EA60EC1EB41A082CA121B2E102EF30C03F4D26F55931B76EFBF75F057F3F2A668FEF3D2527
337:d=3 hl=5 l=393615 cons: SEQUENCE
342:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data
353:d=4 hl=2 l= 29 cons: SEQUENCE
355:d=5 hl=2 l= 9 prim: OBJECT :aes-256-cbc
366:d=5 hl=2 l= 16 prim: OCTET STRING [HEX DUMP]:1A4BB3CAB2F425A2456C5B8700219FC0
384:d=4 hl=5 l=393568 prim: cont [ 0 ]
And here is what I would get while using .Net 4.5 SMTP client
0:d=0 hl=5 l=394986 cons: SEQUENCE
5:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-envelopedData
16:d=1 hl=5 l=394970 cons: cont [ 0 ]
21:d=2 hl=5 l=394965 cons: SEQUENCE
26:d=3 hl=2 l= 1 prim: INTEGER :00
29:d=3 hl=4 l= 554 cons: SET
33:d=4 hl=4 l= 550 cons: SEQUENCE
37:d=5 hl=2 l= 1 prim: INTEGER :00
40:d=5 hl=4 l= 268 cons: SEQUENCE
44:d=6 hl=3 l= 247 cons: SEQUENCE
47:d=7 hl=2 l= 11 cons: SET
49:d=8 hl=2 l= 9 cons: SEQUENCE
51:d=9 hl=2 l= 3 prim: OBJECT :countryName
56:d=9 hl=2 l= 2 prim: PRINTABLESTRING :US
60:d=7 hl=2 l= 32 cons: SET
62:d=8 hl=2 l= 30 cons: SEQUENCE
64:d=9 hl=2 l= 3 prim: OBJECT :organizationName
69:d=9 hl=2 l= 23 prim: PRINTABLESTRING :Hewlett-Packard Company
94:d=7 hl=2 l= 31 cons: SET
96:d=8 hl=2 l= 29 cons: SEQUENCE
98:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName
103:d=9 hl=2 l= 22 prim: PRINTABLESTRING :VeriSign Trust Network
127:d=7 hl=2 l= 59 cons: SET
129:d=8 hl=2 l= 57 cons: SEQUENCE
131:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName
136:d=9 hl=2 l= 50 prim: PRINTABLESTRING :Terms of use at https://www.verisign.com/rpa (c)09
188:d=7 hl=2 l= 53 cons: SET
190:d=8 hl=2 l= 51 cons: SEQUENCE
192:d=9 hl=2 l= 3 prim: OBJECT :organizationalUnitName
197:d=9 hl=2 l= 44 prim: PRINTABLESTRING :Class 2 Managed PKI Individual Subscriber CA
243:d=7 hl=2 l= 49 cons: SET
245:d=8 hl=2 l= 47 cons: SEQUENCE
247:d=9 hl=2 l= 3 prim: OBJECT :commonName
252:d=9 hl=2 l= 40 prim: PRINTABLESTRING :Collaboration Certification Authority G2
294:d=6 hl=2 l= 16 prim: INTEGER :4C1DCC56F939DF3671B26A50DF810C16
312:d=5 hl=2 l= 13 cons: SEQUENCE
314:d=6 hl=2 l= 9 prim: OBJECT :1.2.840.113549.1.1.7
325:d=6 hl=2 l= 0 cons: SEQUENCE
327:d=5 hl=4 l= 256 prim: OCTET STRING [HEX DUMP]:766ECBA847C51B3F8BDFD7D2CC2036B1161DA0BAD757A628E4EBB0A15F46586DDBB848F918D78072542F9E618D69ADDE5D863689CEB79A1B7D84D69AB3A8BAE0BF0E1A968485CB04F04A6D4FDB6946147EF95A9C472E2B02AAF664745E8C6BEFD0F078D469DA5B227EE0C4EB95E5D6D909A09301444D3D961EF66BB24D153F4778E128B50E5B382BA46CD849C723C6ED1B1C845BDCA8441F03B554E6513BF16E65A7F1F7DAEA66B3081C1A5C7B4B4C46D1395011139694332D6F400D8DDD0522AD128ADFFCE1249FF8465026EABDB907A0ACF01E2825D4C6E1F90ABE6D74E2FE389325C2B9152078B3119685E0F06954F13349ABA46E7F2DFD99DF458C5C703F
587:d=3 hl=5 l=394399 cons: SEQUENCE
592:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data
603:d=4 hl=2 l= 29 cons: SEQUENCE
605:d=5 hl=2 l= 9 prim: OBJECT :aes-256-cbc
616:d=5 hl=2 l= 16 prim: OCTET STRING [HEX DUMP]:9B746E27201198B82A599C3E9FD13498
634:d=4 hl=5 l=394352 prim: cont [ 0 ]
So it is noticeable that the ":rsaEncryption" is missing from the pkcs7-envelopedData
To solve this I had to specify SubjectIdentifierType as SubjectIdentifierType.SubjectKeyIdentifier while adding CmsRecipient to the recipient collection. As following code snippet shows
recipientCollection.Add(new CmsRecipient(SubjectIdentifierType.SubjectKeyIdentifier, EncryptCert));
This ensured that RSA Key endryption OID "rsaEncryption (1 2 840 113549 1 1 1)" is not missed out of the Envelope.
Please note that I found this issue only while dealing with Entrust provided Certificates(for encryption). I do not see this issue otherwise.